[v2] iio: buffer: fix warning in requesting threaded irq

[PATCH v2] iio: buffer: fix warning in requesting threaded irq

Posted by Junxiao Chang 1 month, 4 weeks ago

IRQF_ONESHOT is for threaded IRQ. If there is no threaded IRQ
handler, this flag should not be set.

This change fixes a warning during booting with kernel v7.0-rc3:

WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x1639/0x2510, CPU#3: iio-sensor-prox/974
RIP: 0010:__setup_irq+0x1639/0x2510
Call Trace:
request_threaded_irq+0x2c7/0x490
iio_trigger_attach_poll_func+0x353/0x6b0
__iio_update_buffers+0x2420/0x2c70
enable_store+0x183/0x270
dev_attr_store+0x5e/0x90
sysfs_kf_write+0x1e8/0x290
kernfs_fop_write_iter+0x406/0x5f0
vfs_write+0x71c/0xea0

v2: using ternary and drop temp variable

Fixes: 23f2d735a932 ("iio: Add helper function for initializing triggered buffers")
Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
---
 drivers/iio/buffer/industrialio-triggered-buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c b/drivers/iio/buffer/industrialio-triggered-buffer.c
index 9bf75dee7ff86..40eea3a447246 100644
--- a/drivers/iio/buffer/industrialio-triggered-buffer.c
+++ b/drivers/iio/buffer/industrialio-triggered-buffer.c
@@ -64,7 +64,7 @@ int iio_triggered_buffer_setup_ext(struct iio_dev *indio_dev,
 
 	indio_dev->pollfunc = iio_alloc_pollfunc(h,
 						 thread,
-						 IRQF_ONESHOT,
+						 thread ? IRQF_ONESHOT : 0,
 						 indio_dev,
 						 "%s_consumer%d",
 						 indio_dev->name,
-- 
2.43.0

Re: [PATCH v2] iio: buffer: fix warning in requesting threaded irq

Posted by Andy Shevchenko 1 month, 4 weeks ago

On Sat, Apr 18, 2026 at 04:51:56PM +0800, Junxiao Chang wrote:
> IRQF_ONESHOT is for threaded IRQ. If there is no threaded IRQ
> handler, this flag should not be set.
> 
> This change fixes a warning during booting with kernel v7.0-rc3:
> 
> WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x1639/0x2510, CPU#3: iio-sensor-prox/974

> RIP: 0010:__setup_irq+0x1639/0x2510

Unneeded line (it dups the previous one).

> Call Trace:
> request_threaded_irq+0x2c7/0x490
> iio_trigger_attach_poll_func+0x353/0x6b0
> __iio_update_buffers+0x2420/0x2c70
> enable_store+0x183/0x270
> dev_attr_store+0x5e/0x90

> sysfs_kf_write+0x1e8/0x290
> kernfs_fop_write_iter+0x406/0x5f0
> vfs_write+0x71c/0xea0

These 3 lines are also redundant.

> v2: using ternary and drop temp variable

Changelog should go...

> Fixes: 23f2d735a932 ("iio: Add helper function for initializing triggered buffers")
> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
> ---

...here, when it doesn't go to the commit message. One may find this in the
lore archive.

...

Code wise now it looks good.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] iio: buffer: fix warning in requesting threaded irq

Posted by Jonathan Cameron 1 month, 4 weeks ago

On Fri, 17 Apr 2026 14:30:11 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Sat, Apr 18, 2026 at 04:51:56PM +0800, Junxiao Chang wrote:
> > IRQF_ONESHOT is for threaded IRQ. If there is no threaded IRQ
> > handler, this flag should not be set.
> > 
> > This change fixes a warning during booting with kernel v7.0-rc3:
> > 
> > WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x1639/0x2510, CPU#3: iio-sensor-prox/974  
Please provide details on which driver is in use to hit this corner case.

That may help people identify if the bug applies to what they are seeing
and also provide some background on how urgent this is to get upstream + backported.

Jonathan

> 
> > RIP: 0010:__setup_irq+0x1639/0x2510  
> 
> Unneeded line (it dups the previous one).
> 
> > Call Trace:
> > request_threaded_irq+0x2c7/0x490
> > iio_trigger_attach_poll_func+0x353/0x6b0
> > __iio_update_buffers+0x2420/0x2c70
> > enable_store+0x183/0x270
> > dev_attr_store+0x5e/0x90  
> 
> > sysfs_kf_write+0x1e8/0x290
> > kernfs_fop_write_iter+0x406/0x5f0
> > vfs_write+0x71c/0xea0  
> 
> These 3 lines are also redundant.
> 
> > v2: using ternary and drop temp variable  
> 
> Changelog should go...
> 
> > Fixes: 23f2d735a932 ("iio: Add helper function for initializing triggered buffers")
> > Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
> > ---  
> 
> ...here, when it doesn't go to the commit message. One may find this in the
> lore archive.
> 
> ...
> 
> Code wise now it looks good.
>

Re: [PATCH v2] iio: buffer: fix warning in requesting threaded irq

Posted by Jonathan Cameron 1 month, 3 weeks ago

On Fri, 17 Apr 2026 13:50:44 +0100
Jonathan Cameron <jonathan.cameron@huawei.com> wrote:

> On Fri, 17 Apr 2026 14:30:11 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> > On Sat, Apr 18, 2026 at 04:51:56PM +0800, Junxiao Chang wrote:  
> > > IRQF_ONESHOT is for threaded IRQ. If there is no threaded IRQ
> > > handler, this flag should not be set.
> > > 
> > > This change fixes a warning during booting with kernel v7.0-rc3:
> > > 
> > > WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x1639/0x2510, CPU#3: iio-sensor-prox/974    
> Please provide details on which driver is in use to hit this corner case.
> 
> That may help people identify if the bug applies to what they are seeing
> and also provide some background on how urgent this is to get upstream + backported.

Another thing I just noticed related to upstream process.
Please don't send a new version in reply to the older one.
Send it as a new email thread.  It doesn't matter a massive amount in a
simple case like this but when things get more complex threads can become
unmanageable if using this style.

Another practical thing if you want to get code merged is many reviewers
do what I'm doing today and, when they have a massive backlog to review,
start with the latest emails that they see.  In this case your
patch ends up further back in history so is less likely to get reviews
in the short term

Jonathan

> 
> Jonathan
> 
> >   
> > > RIP: 0010:__setup_irq+0x1639/0x2510    
> > 
> > Unneeded line (it dups the previous one).
> >   
> > > Call Trace:
> > > request_threaded_irq+0x2c7/0x490
> > > iio_trigger_attach_poll_func+0x353/0x6b0
> > > __iio_update_buffers+0x2420/0x2c70
> > > enable_store+0x183/0x270
> > > dev_attr_store+0x5e/0x90    
> >   
> > > sysfs_kf_write+0x1e8/0x290
> > > kernfs_fop_write_iter+0x406/0x5f0
> > > vfs_write+0x71c/0xea0    
> > 
> > These 3 lines are also redundant.
> >   
> > > v2: using ternary and drop temp variable    
> > 
> > Changelog should go...
> >   
> > > Fixes: 23f2d735a932 ("iio: Add helper function for initializing triggered buffers")
> > > Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
> > > ---    
> > 
> > ...here, when it doesn't go to the commit message. One may find this in the
> > lore archive.
> > 
> > ...
> > 
> > Code wise now it looks good.
> >   
> 
>

RE: [PATCH v2] iio: buffer: fix warning in requesting threaded irq

Posted by Chang, Junxiao 1 month, 3 weeks ago

>
>On Fri, 17 Apr 2026 13:50:44 +0100
>Jonathan Cameron <jonathan.cameron@huawei.com> wrote:
>
>> Please provide details on which driver is in use to hit this corner case.
>>
>> That may help people identify if the bug applies to what they are
>> seeing and also provide some background on how urgent this is to get
>upstream + backported.
Our hardware platform: ARL-s(Ultra 9 285) desktop. OS: Ubuntu 24.04, kernel v7.0-rc3. It could be reproduced every time.
With code review, some drivers don't have threaded IRQ handler in triggered buffer setup. For example:
vf610_adc_probe in drivers/iio/adc/vf610_adc.c
hid_sensor_setup_trigger in drivers/iio/common/hid-sensors/hid-sensor-trigger.c
This might introduce warning during boot.

>
>Another thing I just noticed related to upstream process.
>Please don't send a new version in reply to the older one.
>Send it as a new email thread.  It doesn't matter a massive amount in a simple
>case like this but when things get more complex threads can become
>unmanageable if using this style.
>
>Another practical thing if you want to get code merged is many reviewers do
>what I'm doing today and, when they have a massive backlog to review, start
>with the latest emails that they see.  In this case your patch ends up further
>back in history so is less likely to get reviews in the short term
Thank you for your suggestion! I will send updated patch as new thread.