Re: [tip: irq/core] genirq: Warn about using IRQF_ONESHOT without a threaded handler

[David Lechner]

On 2/7/26 9:42 AM, Jonathan Cameron wrote:
> On Tue, 03 Feb 2026 09:29:25 -0800
> srinivas pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote:
> 
>> On Tue, 2026-02-03 at 09:38 +0100, Sebastian Andrzej Siewior wrote:
>>> On 2026-02-03 00:27:40 [+0100], Bert Karwatzki wrote:  
>>>>
>>>> The warning appears because iio_triggered_buffer_setup_ext() (in 
>>>> drivers/iio/buffer/industrialio-triggered-buffer.c) is called with
>>>> thread = NULL
>>>> during the probe of the iio device and calls iio_alloc_pollfunc()
>>>> (in drivers/iio/industrialio-trigger.c) with thread = NULL and type
>>>> = IRQF_ONESHOT.


I noticed this while testing hid-sensor-rotation.
    
------------[ cut here ]------------
WARNING: kernel/irq/manage.c:1502 at __setup_irq+0xdc/0x864, CPU#0: bash/425
 CPU: 0 UID: 0 PID: 425 Comm: bash Not tainted 7.0.0-rc1-next-20260227ad7944-mainline-00005-g4d0a79e89547-dirty #54 PREEMPT
Hardware name: Generic DA850/OMAP-L138/AM18x
Call trace:
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x3c/0x4c
 dump_stack_lvl from __warn+0x8c/0x108
 __warn from warn_slowpath_fmt+0x1a8/0x1bc
 warn_slowpath_fmt from __setup_irq+0xdc/0x864
 __setup_irq from request_threaded_irq+0xbc/0x170
 request_threaded_irq from iio_trigger_attach_poll_func+0x8c/0x174
 iio_trigger_attach_poll_func from __iio_update_buffers+0x9f8/0xa60
 __iio_update_buffers from enable_store+0x88/0xd8
 enable_store from kernfs_fop_write_iter+0x10c/0x1f8
 kernfs_fop_write_iter from vfs_write+0x220/0x3c0
 vfs_write from ksys_write+0x6c/0xec
 ksys_write from ret_fast_syscall+0x0/0x44
Exception stack(0xc49a5fa8 to 0xc49a5ff0)
5fa0:                   00000002 00125a08 00000001 00125a08 00000002 00000000
5fc0: 00000002 00125a08 b6f6dd50 00000004 00000002 00000004 00000000 00118fd8
5fe0: 00000000 bed6f71c b6e9260c b6eee04c
---[ end trace 0000000000000000 ]---

>>>>
>>>> A simple fix could be this:
>>>>
>>>> diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c
>>>> b/drivers/iio/buffer/industrialio-triggered-buffer.c
>>>> index 9bf75dee7ff8..40eea3a44724 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,
>>>>
>>>>
>>>> Are there any problems with this?  
>>>
>>> Urgh. Haven't seen those.
>>>
>>> Looking at all the users of of *iio_triggered_buffer_setup*() the
>>> primary handler is either NULL or iio_pollfunc_store_time(). 
>>> So IRQF_ONESHOST should work all the time.
>>>
>>> Then there is 
>>> - drivers/iio/adc/vf610_adc.c 
>>> - drivers/iio/common/hid-sensors/hid-sensor-trigger.c
>>>
>>> They use iio_pollfunc_store_time() as primary and have no secondary.
>>> This would trigger the warning but not having a secondary handler
>>> while
>>> returning IRQF_WAKE_THREAD should create a warning of its own.
>>> What did I miss?
>>>   
>>
>> hid-sensor doesn't need a bh handler. This patch can fix. 
>>
>> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
>> b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
>> index 5540e2d28f4a..b2b09b544f43 100644
>> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
>> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
>> @@ -227,6 +227,11 @@ static const struct iio_trigger_ops
>> hid_sensor_trigger_ops = {
>>         .set_trigger_state = &hid_sensor_data_rdy_trigger_set_state,
>>  };
>>  
>> +static irqreturn_t triggered_buffer_handler(int irq, void *p)
>> +{
>> +        return IRQ_HANDLED;
>> +}
>> +
>>  int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char
>> *name,
>>                                 struct hid_sensor_common *attrb)
>>  {
>> @@ -240,7 +245,8 @@ 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,
>> +                                            triggered_buffer_handler,
>>                                              IIO_BUFFER_DIRECTION_IN,
>>                                              NULL, fifo_attrs);
>>         if (ret) {
>>
>>
>> Or add it to industrialio-triggered-buffer.c as a common handler for
>> all caller with no bh, whatever Jonathan prefers.
> 
> I'm confused about how this works today.  Why do we store a timestamp
> in the pollfunc structure that is never used by a bottom half?
> 
> If we have an actual top half that doesn't need a bottom half, then the
> core code can easily insert a dummy handler, or register something sensible
> in the first place.
>  


I saw that Jonathan mentioned some other more thorough approaches in
a later reply, but here is the "quick fix" I came up with.

Probably a better solution would be to allow NULL for both IRQ handlers
and just not request the IRQ in that case. I didn't have the time/energy
to dig into what it would take to do that yet.

So here it is to see if it is "good enough". The no_action function
isn't used outside of arch/ though (other than one irqchip driver)
so it makes me suspect that using it might be frowned upon.

---