[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260121134508.aS-h9DpX@linutronix.de>
Date: Wed, 21 Jan 2026 14:45:08 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Mark Brown <broonie@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Richard Fitzgerald <rf@...nsource.cirrus.com>,
patches@...nsource.cirrus.com, linux-kernel@...r.kernel.org,
Lee Jones <lee@...nel.org>
Subject: Re: request_irq() usage in wm8350_register_irq().
On 2026-01-21 13:37:09 [+0000], Mark Brown wrote:
> On Wed, Jan 21, 2026 at 02:18:11PM +0100, Sebastian Andrzej Siewior wrote:
>
> > I've been staring wm8350_register_irq(). It does
>
> > | request_threaded_irq(irq + wm8350->irq_base, NULL,
> > | handler, flags, name, data);
>
> > and every single user passes 0 as flags. This means it asks for a
> > threaded IRQ and does not pass IRQF_ONESHOT.
>
> > So either this is not working because it triggers the warnings
> > Threaded irq requested with handler=NULL and !ONESHOT
>
> > followed by -EINVAL _or_ every single user of this driver sits in
> > system where the irqchip is IRQCHIP_ONESHOT_SAFE marked.
> > Which is it?
>
> The chip is only accessable via I2C or SPI so the primary interrupt
> handler is itself always running and reporting child interrupts in
> threaded context. They can't really deliver a hardirq context
> interrupt.
In that case it lacks the needed IRQF_ONEHOST flag and nobody noticed
that request_irq() fails for a few years now. I add a patch to my
stackā¦
Thanks Mark.
Sebastian
Powered by blists - more mailing lists