[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a5b6c607-9b8c-4fa6-98c5-6ba848f7f2e2@sirena.org.uk>
Date: Fri, 16 Jan 2026 15:37:23 +0000
From: Mark Brown <broonie@...nel.org>
To: Shawn Lin <shawn.lin@...k-chips.com>
Cc: Aishwarya TCV <Aishwarya.TCV@....com>, linux-spi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
Heiko Stuebner <heiko@...ech.de>
Subject: Re: [PATCH] spi: rockchip: Use plain request_irq()
On Fri, Jan 16, 2026 at 11:19:39PM +0800, Shawn Lin wrote:
> 在 2026/01/16 星期五 21:23, Mark Brown 写道:
> > The Rockchip driver has since interrupt support was added used
> > request_threaded_irq() but not actually supplied a threaded handler,
> > handling everything in the primary handler. This is equivalent to just
> > using a plain request_irq(), and since aef30c8d569c (genirq: Warn about
> > using IRQF_ONESHOT without a threaded handler) the current behaviour has
> > triggered a WARN_ON(). Convert to use request_irq().
> Is it preferred to use threaded version if latency is not a critical
> concern ? I guess the original intention was to use
> ret = devm_request_threaded_irq(&pdev->dev, ret, NULL, rockchip_spi_isr,
> IRQF_ONESHOT, dev_name(&pdev->dev), ctlr); ?
TBH it looked to me more like there'd been some deferral of more complex
work at some point but that didn't make it into the final code. In
general it's better to handle things in hardirq context if they are
appropriate for that, and for a SPI controller the end requirements are
coming from the device so you have to assume they're going to need
things to complete promptly. There's overhead from scheduling a task so
no point in incurring it if it doesn't buy you anything.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists