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

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 23 Apr 2026 09:44:26 +0800
Junxiao Chang <junxiao.chang@intel.com> 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.
> Hardware: ARLs(Ultra 9 285) desktop
> Software: Ubuntu 24.04 + v7.0-rc3 kernel.
> 
> WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x1639/0x2510, CPU#3: iio-sensor-prox/974
> 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
> 
> There is no threaded handler in thiggered buffer setup, e.g. vf610_adc
> and hid-sensor. They might introduce this warning.
> 
> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
Sashiko just did us a big favour:
https://sashiko.dev/#/patchset/20260423014426.1999735-1-junxiao.chang%40intel.com
I was making too many assumptions on what the vf610 driver was doing.
The issue here isn't in the core at all (though maybe what you are fixing
here is relevant to other drivers) it's in the vf610 driver. 

It registers a triggered buffer, but not trigger and yet actually pushes
the data from the interrupt service routine.  That is fairly nasty misuse
of the IIO infrastructure.  There are two ways to solve this.
1) Rip out the triggered buffer infrastructure and use the buffer directly.
If we need to 'pretend' that's still relevant use the same approach we used
in the hid sensors driver to keep the current_trigger interface (it just
won't do anything).
https://lore.kernel.org/all/20260220224514.471348-1-srinivas.pandruvada@linux.intel.com/
2) Actually implement a trigger. Then the isr will call iio_trigger_poll()
and the vf610_adc_read() will occur in the trigger bottom half with timestamp coming
form the top half that is currently registered.

I'd slightly prefer option 2.

Any idea what trigger your userspace is trying to use with this driver?

No idea if you are up for fixing this - if not I can have a go but have no means
to test that the driver isn't broken.  I don't have time to emulate this device
just now.

Now that's not to say there aren't drivers doing what I was assuming was happening
here (having foolishly not checked the particular driver) and registering only
a custom top half in the poll func.  For those, your fix would be the correct one.
I'm just not sure they exist.  Maybe we can merge that anyway on basis there is
a latent bug that future drivers might hit, but we should also fix the vf610 properly.

Jonathan


> ---
> V4 -> V5: remove Fixes tag and add back change log
> V3 -> V4: remove unneeded backtrace log
> V2 -> V3: remove unneeded log in git message
> V1 -> V2: use ternary and drop temp variable
> 
> V3/V4: https://lore.kernel.org/linux-iio/20260421103807.7ca935e9@jic23-huawei/T/#t
> V2: https://lore.kernel.org/linux-iio/20260418002334.3643504-1-junxiao.chang@intel.com/T/#mc0803722dce6585bbc8c9e0ec8289bd96afe99aa
> V1: https://lore.kernel.org/linux-iio/20260418002334.3643504-1-junxiao.chang@intel.com/T/#mf0eba6c23049d15c2b43ea5528b5f5a47e216c58
> 
>  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,