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: <0aae5643-9276-4280-8b1e-27b8fe73fe99@nvidia.com>
Date: Wed, 29 Oct 2025 09:20:17 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Esben Haabendal <esben@...nix.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: linux-rtc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,
 "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2 4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq
 balance

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@...nix.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ