[PATCH] Replace NULL thread handler with a dummy function.

[PATCH] Replace NULL thread handler with a dummy function.

[junan]

Hi,

This is a similar problem as [1]:

[1] https://lore.kernel.org/linux-iio/20260227071409.aEG-iBFD@linutronix.de/T/#m15ab81856b42f72169fe51bd87fa399b5147441f

Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT
without a threaded handler"), the IRQ core checks IRQF_ONESHOT flag
in IRQ request and gives a warning if there is no threaded handler.

There are two iio devices on my machine:

```
junan@fedora:~$ ls /sys/bus/iio/devices/
iio:device0  trigger0
junan@fedora:~$ cat /sys/bus/iio/devices/*/name
als
als-dev0
```

The function calling chain is as following:

hid_als_probe(hid-sensor-als.c)
	=> hid_sensor_setup_trigger(hid-sensor-trigger.c)
		=> iio_triggered_buffer_setup_ext(industrialio-triggered-buffer.c)

`iio_triggered_buffer_setup_ext` is called with a NULL thread handler, and the flag is set to `IRQF_ONESHOT` inside it.
I am not sure which flag to change, so I replace the NULL pointer with a dummy function or can we just change the flag?

Signed-off-by: junan <junan76@163.com>
---
 drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
index 5540e2d28f4a..ec251beeca92 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -202,6 +202,11 @@ static void hid_sensor_set_power_work(struct work_struct *work)
 		_hid_sensor_power_state(attrb, true);
 }
 
+static irqreturn_t hid_sensor_dummy_handler(int irq, void *p)
+{
+	return IRQ_HANDLED;
+}
+
 static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
 						bool state)
 {
@@ -240,7 +245,7 @@ int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char *name,
 		fifo_attrs = NULL;
 
 	ret = iio_triggered_buffer_setup_ext(indio_dev,
-					     &iio_pollfunc_store_time, NULL,
+					     &iio_pollfunc_store_time, &hid_sensor_dummy_handler,
 					     IIO_BUFFER_DIRECTION_IN,
 					     NULL, fifo_attrs);
 	if (ret) {
-- 
2.53.0

Re: [PATCH] Replace NULL thread handler with a dummy function.

[Andy Shevchenko]

On Sat, Feb 28, 2026 at 10:36:46AM +0800, junan wrote:
> Hi,
> 
> This is a similar problem as [1]:

> [1] https://lore.kernel.org/linux-iio/20260227071409.aEG-iBFD@linutronix.de/T/#m15ab81856b42f72169fe51bd87fa399b5147441f
> 

Make it a Link tag.

> without a threaded handler"), the IRQ core checks IRQF_ONESHOT flag
> in IRQ request and gives a warning if there is no threaded handler.
> 
> There are two iio devices on my machine:

IIO

> ```
> junan@fedora:~$ ls /sys/bus/iio/devices/
> iio:device0  trigger0
> junan@fedora:~$ cat /sys/bus/iio/devices/*/name
> als
> als-dev0
> ```
> 
> The function calling chain is as following:
> 
> hid_als_probe(hid-sensor-als.c)
> 	=> hid_sensor_setup_trigger(hid-sensor-trigger.c)
> 		=> iio_triggered_buffer_setup_ext(industrialio-triggered-buffer.c)
> 
> `iio_triggered_buffer_setup_ext` is called with a NULL thread handler, and the flag is set to `IRQF_ONESHOT` inside it.

> I am not sure which flag to change, so I replace the NULL pointer with a
> dummy function or can we just change the flag?

Besides you used way too long lines, the last sentence (question) has to be
located in the comment block...

> Signed-off-by: junan <junan76@163.com>
> ---

...somewhere here.

And answering to it I think it's band-aid and wrong approach.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] Replace NULL thread handler with a dummy function.

[Jonathan Cameron]

On Sat, 28 Feb 2026 12:15:51 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Sat, Feb 28, 2026 at 10:36:46AM +0800, junan wrote:
> > Hi,
> > 
Hi.

One general comment is to follow the formating of patch titles used in the
particular subsystem you are sending a patch to. So something like:

iio: hid-als: Provide a dummy thread handler to avoid warning.


> > This is a similar problem as [1]:  
> 
> > [1] https://lore.kernel.org/linux-iio/20260227071409.aEG-iBFD@linutronix.de/T/#m15ab81856b42f72169fe51bd87fa399b5147441f
> >   
> 
https://lore.kernel.org/all/20260220224514.471348-1-srinivas.pandruvada@linux.intel.com/

Is perhaps more relevant here and the preferred approach.  These sensors should
in theory have never provided a trigger in the first place but we can't fix
that now because of ABI issues.  The approach used in Srinivas' set gets us
to the position where the ABI remains the same but the underlying structure
correctly doesn't use a trigger.

I haven't checked how Srinivas' approach would apply here though so
I may well be missing something!
+CC Srinivas.




> Make it a Link tag.
> 
> > without a threaded handler"), the IRQ core checks IRQF_ONESHOT flag
> > in IRQ request and gives a warning if there is no threaded handler.
> > 
> > There are two iio devices on my machine:  
> 
> IIO
> 
> > ```
> > junan@fedora:~$ ls /sys/bus/iio/devices/
> > iio:device0  trigger0
> > junan@fedora:~$ cat /sys/bus/iio/devices/*/name
> > als
> > als-dev0
> > ```
> > 
> > The function calling chain is as following:
> > 
> > hid_als_probe(hid-sensor-als.c)  
> > 	=> hid_sensor_setup_trigger(hid-sensor-trigger.c)
> > 		=> iio_triggered_buffer_setup_ext(industrialio-triggered-buffer.c)  
> > 
> > `iio_triggered_buffer_setup_ext` is called with a NULL thread handler, and the flag is set to `IRQF_ONESHOT` inside it.  

It's not as though the top half is valid here either!  This is a completely
fake registration of an interrupt handler that never gets called.

> 
> > I am not sure which flag to change, so I replace the NULL pointer with a
> > dummy function or can we just change the flag?  
> 
> Besides you used way too long lines, the last sentence (question) has to be
> located in the comment block...
> 
> > Signed-off-by: junan <junan76@163.com>
> > ---  
> 
> ...somewhere here.
> 
> And answering to it I think it's band-aid and wrong approach.
We need a bit of a band aid to avoid an ABI break, but the approach in Srinivas' patch
for the main hid sensors support is cleaner than the one here.

Jonathan

>