linux-kernel - Re: request_irq() usage in wm8350_register

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: <aXDUi1ci/YzOuEIR@opensource.cirrus.com>
Date: Wed, 21 Jan 2026 13:28:43 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        patches@...nsource.cirrus.com, linux-kernel@...r.kernel.org,
        Lee Jones <lee@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: request_irq() usage in wm8350_register_irq().

On Wed, Jan 21, 2026 at 12:49:11PM +0000, Richard Fitzgerald wrote:
> On 21/01/2026 11:57 am, Sebastian Andrzej Siewior wrote:
> > On 2026-01-21 11:53:28 [+0000], Richard Fitzgerald wrote:
> > > Ah. I didn't notice that. Confusing error message. It says
> > > "handler=NULL" but handler != NULL. More like "handler=default".
> > 
> > The supplied argument was NULL.
> > Anyway. Do you happen to have an answer to my original question.
> > 
> > Sebastian
> 
> Afraid I'm not familiar with the WM8350.
> 
> But I note that call is not registering against a real interrupt pin.
> It's registering against a virtual irqchip that is itself a threaded
> IRQ handler. Maybe that makes a difference. That top-level virtual IRQ
> handler is ONESHOT.

Yeah I suspect there is some trickery like this which means this
doesn't actually cause a problem in practice, since these are
internal IRQs to the chip, and the IRQ coming out of the chip is
marked as one shot. So the alluded to IRQ storm probably can't
happen as the chip level IRQ is still masked.

I also note the driver predates the check by a good few years, so
it wouldn't have generated any errors whilst being developed. To
be fair it has also never been the most heavily used driver, so
quite plausible no one has noticed the error message since. I
would wager the correct thing to do here is just to add the
ONESHOT flag in.

Thanks,
Charles