lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 4 Feb 2016 14:35:24 -0300
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	Laxman Dewangan <ldewangan@...dia.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	lee.jones@...aro.org, alexandre.belloni@...e-electrons.com
Cc:	cw00.choi@...sung.com, linux-kernel@...r.kernel.org,
	rtc-linux@...glegroups.com
Subject: Re: [PATCH V3 5/5] rtc: max77686: move initialisation of rtc regmap,
 irq chip locally

Hello Laxman,

On 02/04/2016 07:13 AM, Laxman Dewangan wrote:
>
> On Thursday 04 February 2016 02:38 PM, Krzysztof Kozlowski wrote:
>> On 04.02.2016 15:58, Krzysztof Kozlowski wrote:
>>> On 04.02.2016 11:03, Laxman Dewangan wrote:
>>>> 3. Can you try locally to not use devm_regmap_init_i2c() and just use
>>>> the regmap_init_i2c() and proper removal of this from error path and
>>>> remove callback?
>>> I'll try to find some time for that. Maybe tomorrow.
>> regmap_init_i2c does not help. However helps commenting out the:
>>     regmap_del_irq_chip(info->rtc_irq, info->rtc_irq_data);
>> from remove() callback.
>>
>>
>
> Thanks for debugging.  I do not see anything on regmap_del_irq_chip() which can be suspected. Is this because of sharing interrupt between mfd and rtc driver?

I don't think so, as long as all the callers pass the IRQF_SHARED flag,
there shouldn't be issues if different drivers call request / free irq.

AFAIK the only thing to take into account is that all callers should
pass a non-NULL cookie (the void * parameter in request and free irq)
so the kernel has a way to differentiate at request / free time.

And this is the case for regmap irq since the regmap_irq_chip_data *
that is passed to regmap_{add,del}_irq_chip() is used as the cookie.

>
> What is your suggestion here?  Should we avoid this inside RTC driver (creating this in mfd) and pass this information to the rtc driver using customized platform driver?
>

That wouldn't be the right approach IMHO, that would just mask the real
issue by making the call to regmap_del_irq_chip() to never happen since
the MFD device is not usually unbound due regulators being too critical.

I think we should find the real cause why this is happening and fix it.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ