drivers/thermal/qcom/lmh.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
The lmh driver triggers a WARN_ON() due to requesting an interrupt with
IRQF_ONESHOT without a threaded handler:
[ 17.414825] WARNING: kernel/irq/manage.c:1502 at __setup_irq+0xd0/0x7a0, CPU#7: (udev-worker)/154
...
2361 18:49:55.941384 <4>[ 17.415074] __setup_irq+0xd0/0x7a0 (P)
2362 18:49:55.981820 <4>[ 17.415085] request_threaded_irq+0xec/0x1a4
2363 18:49:55.982122 <4>[ 17.415095] devm_request_threaded_irq+0x80/0x134
2364 18:49:55.982365 <4>[ 17.415103] lmh_probe+0x31c/0x4c8 [lmh]
2365 18:49:55.982594 <4>[ 17.415118] platform_probe+0x5c/0x98
This warning is there because IRQF_ONESHOT is only meaningful when there is
a threaded interrupt handler and this driver does not register one. Just
remove IRQF_ONESHOT, it wasn't doing anything.
Reported-by: Aishwarya TCV <Aiswarya.TCV@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/thermal/qcom/lmh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
index ddadcfada513..b6b7f1193c44 100644
--- a/drivers/thermal/qcom/lmh.c
+++ b/drivers/thermal/qcom/lmh.c
@@ -220,8 +220,7 @@ static int lmh_probe(struct platform_device *pdev)
/* Disable the irq and let cpufreq enable it when ready to handle the interrupt */
irq_set_status_flags(lmh_data->irq, IRQ_NOAUTOEN);
ret = devm_request_irq(dev, lmh_data->irq, lmh_handle_irq,
- IRQF_ONESHOT | IRQF_NO_SUSPEND,
- "lmh-irq", lmh_data);
+ IRQF_NO_SUSPEND, "lmh-irq", lmh_data);
if (ret) {
dev_err(dev, "Error %d registering irq %x\n", ret, lmh_data->irq);
irq_domain_remove(lmh_data->domain);
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260130-thermal-lmh-oneshot-5ce7022bbf26
Best regards,
--
Mark Brown <broonie@kernel.org>
On Fri, Jan 30, 2026 at 04:54:45PM +0000, Mark Brown wrote: > The lmh driver triggers a WARN_ON() due to requesting an interrupt with > IRQF_ONESHOT without a threaded handler: > > [ 17.414825] WARNING: kernel/irq/manage.c:1502 at __setup_irq+0xd0/0x7a0, CPU#7: (udev-worker)/154 > > ... > > 2361 18:49:55.941384 <4>[ 17.415074] __setup_irq+0xd0/0x7a0 (P) > 2362 18:49:55.981820 <4>[ 17.415085] request_threaded_irq+0xec/0x1a4 > 2363 18:49:55.982122 <4>[ 17.415095] devm_request_threaded_irq+0x80/0x134 > 2364 18:49:55.982365 <4>[ 17.415103] lmh_probe+0x31c/0x4c8 [lmh] > 2365 18:49:55.982594 <4>[ 17.415118] platform_probe+0x5c/0x98 > > This warning is there because IRQF_ONESHOT is only meaningful when there is > a threaded interrupt handler and this driver does not register one. Just > remove IRQF_ONESHOT, it wasn't doing anything. I think it might be not that easy. The IRQ is level-triggered, with the IRQ source (if I'm not mistaken) cointinuing to be high level while CPU is overheated. By removing this IRQF_ONESHOT we might get an IRQ storm. At least it needs to be validated on SDM845 and SM8150 before merging. I will try doing that once I have time. > > Reported-by: Aishwarya TCV <Aiswarya.TCV@arm.com> > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > drivers/thermal/qcom/lmh.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) -- With best wishes Dmitry
On Sat, Jan 31, 2026 at 08:59:03AM +0200, Dmitry Baryshkov wrote:
> On Fri, Jan 30, 2026 at 04:54:45PM +0000, Mark Brown wrote:
> > This warning is there because IRQF_ONESHOT is only meaningful when there is
> > a threaded interrupt handler and this driver does not register one. Just
> > remove IRQF_ONESHOT, it wasn't doing anything.
> I think it might be not that easy. The IRQ is level-triggered, with the
> IRQ source (if I'm not mistaken) cointinuing to be high level while CPU
> is overheated. By removing this IRQF_ONESHOT we might get an IRQ storm.
See the commit log for aef30c8d569c ("genirq: Warn about using
IRQF_ONESHOT without a threaded handler"), and note that a oneshot
interrupt will be unmasked if the main handler directly handles it and
returns IRQ_HANDLED instead of waking the thread with IRQ_WAKE_THREAD.
The handler in this driver unconditionally returns IRQ_HANDLED.
The above sounds like the interrupt needs to be edge triggered?
On Sat, Jan 31, 2026 at 03:07:04PM +0000, Mark Brown wrote:
> On Sat, Jan 31, 2026 at 08:59:03AM +0200, Dmitry Baryshkov wrote:
> > On Fri, Jan 30, 2026 at 04:54:45PM +0000, Mark Brown wrote:
>
> > > This warning is there because IRQF_ONESHOT is only meaningful when there is
> > > a threaded interrupt handler and this driver does not register one. Just
> > > remove IRQF_ONESHOT, it wasn't doing anything.
>
> > I think it might be not that easy. The IRQ is level-triggered, with the
> > IRQ source (if I'm not mistaken) cointinuing to be high level while CPU
> > is overheated. By removing this IRQF_ONESHOT we might get an IRQ storm.
>
> See the commit log for aef30c8d569c ("genirq: Warn about using
> IRQF_ONESHOT without a threaded handler"), and note that a oneshot
> interrupt will be unmasked if the main handler directly handles it and
> returns IRQ_HANDLED instead of waking the thread with IRQ_WAKE_THREAD.
> The handler in this driver unconditionally returns IRQ_HANDLED.
And looking how it all works, it looks like qcom-cpufreq-hw disables the
IRQ generated by the LMH driver, which in turn disables the LMH IRQ.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> The above sounds like the interrupt needs to be edge triggered?
Well, it is a level IRQ, it signals that thermal mitigation is required.
--
With best wishes
Dmitry
On Sat, Jan 31, 2026 at 6:16 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Sat, Jan 31, 2026 at 03:07:04PM +0000, Mark Brown wrote:
> > On Sat, Jan 31, 2026 at 08:59:03AM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Jan 30, 2026 at 04:54:45PM +0000, Mark Brown wrote:
> >
> > > > This warning is there because IRQF_ONESHOT is only meaningful when there is
> > > > a threaded interrupt handler and this driver does not register one. Just
> > > > remove IRQF_ONESHOT, it wasn't doing anything.
> >
> > > I think it might be not that easy. The IRQ is level-triggered, with the
> > > IRQ source (if I'm not mistaken) cointinuing to be high level while CPU
> > > is overheated. By removing this IRQF_ONESHOT we might get an IRQ storm.
> >
> > See the commit log for aef30c8d569c ("genirq: Warn about using
> > IRQF_ONESHOT without a threaded handler"), and note that a oneshot
> > interrupt will be unmasked if the main handler directly handles it and
> > returns IRQ_HANDLED instead of waking the thread with IRQ_WAKE_THREAD.
> > The handler in this driver unconditionally returns IRQ_HANDLED.
>
> And looking how it all works, it looks like qcom-cpufreq-hw disables the
> IRQ generated by the LMH driver, which in turn disables the LMH IRQ.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
I've applied the patch as 6.20/7.0 material, thanks!
On Fri, Jan 30, 2026 at 5:55 PM Mark Brown <broonie@kernel.org> wrote:
>
> The lmh driver triggers a WARN_ON() due to requesting an interrupt with
> IRQF_ONESHOT without a threaded handler:
>
> [ 17.414825] WARNING: kernel/irq/manage.c:1502 at __setup_irq+0xd0/0x7a0, CPU#7: (udev-worker)/154
>
> ...
>
> 2361 18:49:55.941384 <4>[ 17.415074] __setup_irq+0xd0/0x7a0 (P)
> 2362 18:49:55.981820 <4>[ 17.415085] request_threaded_irq+0xec/0x1a4
> 2363 18:49:55.982122 <4>[ 17.415095] devm_request_threaded_irq+0x80/0x134
> 2364 18:49:55.982365 <4>[ 17.415103] lmh_probe+0x31c/0x4c8 [lmh]
> 2365 18:49:55.982594 <4>[ 17.415118] platform_probe+0x5c/0x98
>
> This warning is there because IRQF_ONESHOT is only meaningful when there is
> a threaded interrupt handler and this driver does not register one. Just
> remove IRQF_ONESHOT, it wasn't doing anything.
>
> Reported-by: Aishwarya TCV <Aiswarya.TCV@arm.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>
Daniel, do you want me to pick up this one? I can still push it for
6.19 as a fix.
> ---
> drivers/thermal/qcom/lmh.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/lmh.c b/drivers/thermal/qcom/lmh.c
> index ddadcfada513..b6b7f1193c44 100644
> --- a/drivers/thermal/qcom/lmh.c
> +++ b/drivers/thermal/qcom/lmh.c
> @@ -220,8 +220,7 @@ static int lmh_probe(struct platform_device *pdev)
> /* Disable the irq and let cpufreq enable it when ready to handle the interrupt */
> irq_set_status_flags(lmh_data->irq, IRQ_NOAUTOEN);
> ret = devm_request_irq(dev, lmh_data->irq, lmh_handle_irq,
> - IRQF_ONESHOT | IRQF_NO_SUSPEND,
> - "lmh-irq", lmh_data);
> + IRQF_NO_SUSPEND, "lmh-irq", lmh_data);
> if (ret) {
> dev_err(dev, "Error %d registering irq %x\n", ret, lmh_data->irq);
> irq_domain_remove(lmh_data->domain);
>
> ---
On Fri, Jan 30, 2026 at 07:06:06PM +0100, Rafael J. Wysocki wrote: > On Fri, Jan 30, 2026 at 5:55 PM Mark Brown <broonie@kernel.org> wrote: > > This warning is there because IRQF_ONESHOT is only meaningful when there is > > a threaded interrupt handler and this driver does not register one. Just > > remove IRQF_ONESHOT, it wasn't doing anything. > Daniel, do you want me to pick up this one? I can still push it for > 6.19 as a fix. FWIW the WARN_ON() is introduced in -next so won't be seen in v6.19 (though the issue has been there since forever).
On Fri, Jan 30, 2026 at 7:09 PM Mark Brown <broonie@kernel.org> wrote: > > On Fri, Jan 30, 2026 at 07:06:06PM +0100, Rafael J. Wysocki wrote: > > On Fri, Jan 30, 2026 at 5:55 PM Mark Brown <broonie@kernel.org> wrote: > > > > This warning is there because IRQF_ONESHOT is only meaningful when there is > > > a threaded interrupt handler and this driver does not register one. Just > > > remove IRQF_ONESHOT, it wasn't doing anything. > > > Daniel, do you want me to pick up this one? I can still push it for > > 6.19 as a fix. > > FWIW the WARN_ON() is introduced in -next so won't be seen in v6.19 > (though the issue has been there since forever). OK, so it need not go into 6.19, but it would be good to have in 6.20/7.0.
© 2016 - 2026 Red Hat, Inc.