linux-kernel - Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver

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]

Message-ID: <568F8D7E.10500@nvidia.com>
Date:	Fri, 8 Jan 2016 15:50:46 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	<rtc-linux@...glegroups.com>
CC:	<robh+dt@...nel.org>, <pawel.moll@....com>, <mark.rutland@....com>,
	<ijc+devicetree@...lion.org.uk>, <galak@...eaurora.org>,
	<linus.walleij@...aro.org>, <gnurou@...il.com>,
	<lee.jones@...aro.org>, <broonie@...nel.org>,
	<a.zummo@...ertech.it>, <alexandre.belloni@...e-electrons.com>,
	<lgirdwood@...il.com>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
	<swarren@...dia.com>, <treding@...dia.com>,
	Chaitanya Bandi <bandik@...dia.com>
Subject: Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024
 RTC driver

Hi Krzysztof,
Thanks for review.

Accepted most of review comment and will update in next patch.

Answer to query:

On Friday 08 January 2016 07:33 AM, Krzysztof Kozlowski wrote:
> 2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@...dia.com>:
> ---
>   drivers/rtc/Kconfig        |   9 +
>   drivers/rtc/Makefile       |   1 +
>   drivers/rtc/rtc-max77620.c | 574 +++++++++++++++++++++++++++++++++++++++++++++
> The driver (as most of Maxim's) looks quite similar to existing RTC
> driver, like max77802. It is difficult to spot the exact differences
> (I don't have 77620's datasheet) but I would suggest not duplicating
> the work. Maybe the biggest difference is the way you configure the
> regmap... but still sometimes the regmap config can be shared.
Yaah, that is the issue on IP based PMIC system and it happen with the 
Maxim and TI.
The MFD and its sub module drivers are too much couped  and hence 
dificult to use the IP driver across PMIC. For almost all Maxim PMIC, we 
end up of same type of RTC driver.

Probably, we need to enhance the mfd sub system to allow sub module 
driver to decoupe from its APIs.

+
+       rtc->irq = platform_get_irq(pdev, 0);
+       ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
+                       max77620_rtc_irq, IRQF_ONESHOT | IRQF_EARLY_RESUME,

> Why early resume?

When we go on suspend, the interrupts are masked by framework. For 
regmap-irq, it is stored on local reg value but not written into the 
PMIC register.
In Nvidia Tegra system, ARM GIC controller registered before the other 
interrupt controller like GPIO, PMIC etc.
When wakeup happened through RTC alarm, we get the interrupt from PMIC 
and on resume path, the PMIC isr handler get called after PMIC interrupt 
to the GIC is unmasked. But at this time, PMIC RTC alarm is still in 
masked state by regmap-irq which causes the interrupt to RTC ignore in 
the PMIC ISR handler and so RTC Isr did not get called and not cleared 
interrupt. This causes PMIC ISr handler to stuck on loop.

The need is to unmask the RTC alarm interrupt on PMIC interrupt driver 
before PMIC interrupt served so that we can have proper interrupt status 
in handler and rtc isr can get called.

For this, RTC alarm interrupt need to be EARLY_RESUME.