[PATCH v2 4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq balance
Jon Hunter
jonathanh at nvidia.com
Wed Oct 29 02:20:17 PDT 2025
Hi Esben,
On 16/05/2025 08:23, Esben Haabendal wrote:
> Interrupts are automatically enabled when requested, so we need to
> initialize irq_en accordingly to avoid causing an unbalanced enable
> warning.
>
> Signed-off-by: Esben Haabendal <esben at geanix.com>
> ---
> drivers/rtc/rtc-tps6586x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/rtc-tps6586x.c b/drivers/rtc/rtc-tps6586x.c
> index 54c8429b16bfcc692b1f4d5404f0c42f720e93b4..76ecf7b798f0de22aa89a552a263b473ab3065ef 100644
> --- a/drivers/rtc/rtc-tps6586x.c
> +++ b/drivers/rtc/rtc-tps6586x.c
> @@ -258,6 +258,7 @@ static int tps6586x_rtc_probe(struct platform_device *pdev)
>
> irq_set_status_flags(rtc->irq, IRQ_NOAUTOEN);
>
> + rtc->irq_en = true;
> ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> tps6586x_rtc_irq,
> IRQF_ONESHOT,
>
I have bisected a suspend regression on one of our Tegra20 boards (that
uses this driver) and bisect is pointing to this commit. Reverting this
commit fixes the problem.
Looking at the above I see that the flag IRQ_NOAUTOEN is being set and
so now with your change we never enable the interrupt. Hence, the
wake-ups are now broken and suspend testing fails. So it would seem best
to revert this.
BTW, I looked at the change to the CPCAP driver and that driver actively
disables the IRQ after requesting it and so I am wondering if that will
also have alarm issues? I don't have a board with CPCAP to test.
Thanks
Jon
--
nvpublic
More information about the linux-arm-kernel
mailing list