linux-kernel - Re: [PATCH] genirq/PM: Fix IRQCHIP_ENABLE_WAKEUP_ON

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: <86plgdeyrx.wl-maz@kernel.org>
Date: Tue, 13 May 2025 08:49:06 +0100
From: Marc Zyngier <maz@...nel.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	chintanpandya@...gle.com,
	Maulik Shah <quic_mkshah@...cinc.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] genirq/PM: Fix IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND if depth > 1

Hey Doug,

On Tue, 13 May 2025 01:32:52 +0100,
Douglas Anderson <dianders@...omium.org> wrote:
> 
> The IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag doesn't work properly if the
> IRQ disable depth is not 0 or 1 at suspend time. In this case, the
> IRQ's depth will be decremented but the IRQ won't be enabled to wake
> the system up. Add a special case for when we're suspending and always
> enable the IRQ in that case.

For my own edification, can you explain why you end-up in this
situation? Because I think I can see a use case for the current
behaviour, where a driver controls whether it wants to use this
interrupt as a wake-up source or not dynamically, irrespective of the
underlying chip's capabilities (which I suspect is pinctrl-msm).

This is also consistent with the way disable_irq() nests, making
IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND the equivalent of an enable_irq()
call.

I have the feeling this outlines an issue in the endpoint driver, more
than a core code deficiency.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.