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

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

[Bert Karwatzki]

Since commit 
aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler")
has been merged into linux-next the following warning appears when booting my 
MSI Alpha 15 laptop (running linux-next-20260130 with debian stable/trixie):

[    8.436584] [   T1180] ------------[ cut here ]------------
[    8.436811] [   T1180] WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x4fa/0x730, CPU#15: iio-sensor-prox/1180
[    8.436817] [   T1180] Modules linked in: rfcomm bnep nls_ascii nls_cp437 vfat fat snd_hda_codec_generic btusb btrtl snd_hda_codec_atihdmi btintel snd_hda_codec_hdmi btbcm uvcvideo btmtk videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc videobuf2_v4l2 snd_intel_dspcfg snd_hda_codec snd_acp3x_rn snd_soc_dmic snd_acp3x_pdm_dma bluetooth snd_hda_core snd_soc_core snd_hwdep videodev snd_pcm_oss snd_mixer_oss snd_pcm snd_rn_pci_acp3x hid_sensor_magn_3d hid_sensor_prox hid_sensor_accel_3d hid_sensor_als hid_sensor_gyro_3d videobuf2_common snd_acp_config snd_soc_acpi hid_sensor_trigger msi_wmi ecdh_generic ecc mc sparse_keymap wmi_bmof snd_timer k10temp snd snd_pci_acp3x ccp ac soundcore industrialio_triggered_buffer battery kfifo_buf button industrialio amd_pmc hid_sensor_iio_common joydev evdev mt7921e mt7921_common mt792x_lib mt76_connac_lib mt76 mac80211 libarc4 cfg80211 rfkill msr fuse nvme_fabrics efi_pstore configfs efivarfs autofs4 ext4 mbcache jbd2 usbhid amdgpu amdxcp i2c_algo_bit drm_client_lib drm_ttm_helper ttm xhci_pci
[    8.437165] [   T1180]  drm_exec drm_panel_backlight_quirks xhci_hcd gpu_sched drm_suballoc_helper hid_sensor_hub drm_buddy mfd_core hid_multitouch hid_generic drm_display_helper usbcore i2c_hid_acpi psmouse amd_sfh i2c_hid drm_kms_helper nvme hid serio_raw nvme_core r8169 i2c_piix4 cec i2c_smbus usb_common crc16 i2c_designware_platform i2c_designware_core
[    8.437185] [   T1180] CPU: 15 UID: 0 PID: 1180 Comm: iio-sensor-prox Tainted: G        W           6.19.0-rc7-next-20260130-iiodebug-00002-g2875feff2cee #292 PREEMPT(full) 
[    8.437188] [   T1180] Tainted: [W]=WARN
[    8.437189] [   T1180] Hardware name: Micro-Star International Co., Ltd. Alpha 15 B5EEK/MS-158L, BIOS E158LAMS.10F 11/11/2024
[    8.437190] [   T1180] RIP: 0010:__setup_irq+0x4fa/0x730
[    8.437193] [   T1180] Code: e7 e8 ca 6f 00 00 e9 7e fd ff ff b8 01 00 00 00 48 c7 c2 ff ff ff ff f3 48 0f bc d2 c4 e2 e9 f7 c0 48 89 43 48 e9 d8 fd ff ff <0f> 0b 85 c9 0f 85 8c 00 00 00 81 e2 00 00 01 00 0f 85 7d fb ff ff
[    8.437194] [   T1180] RSP: 0018:ffffc3b6c46d7c70 EFLAGS: 00010246
[    8.437196] [   T1180] RAX: 0000000000002000 RBX: ffffa04c05503e80 RCX: 0000000000000000
[    8.437197] [   T1180] RDX: 0000000000000400 RSI: ffffa04c112e0e00 RDI: ffffffffc181cac0
[    8.437198] [   T1180] RBP: 0000000000000077 R08: 0000000000000000 R09: ffffa04c05503e80
[    8.437199] [   T1180] R10: 0000000000000001 R11: 0000000000000003 R12: 0000000000000077
[    8.437200] [   T1180] R13: ffffa04c112e0e00 R14: ffffa04c112e0e00 R15: ffffa04c05503e80
[    8.437201] [   T1180] FS:  00007f447c23f940(0000) GS:ffffa04f2cb1d000(0000) knlGS:0000000000000000
[    8.437203] [   T1180] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    8.437204] [   T1180] CR2: 0000559507dd86d8 CR3: 0000000103b55000 CR4: 0000000000750ef0
[    8.437205] [   T1180] PKRU: 55555554
[    8.437206] [   T1180] Call Trace:
[    8.437207] [   T1180]  <TASK>
[    8.437209] [   T1180]  request_threaded_irq+0xdf/0x170
[    8.437213] [   T1180]  iio_trigger_attach_poll_func.cold+0x3e/0x111 [industrialio]
[    8.437220] [   T1180]  __iio_update_buffers.cold+0x5c/0x70 [industrialio]
[    8.437224] [   T1180]  ? __entry_text_end+0x1021d7/0x1021db
[    8.437227] [   T1180]  ? _dev_info+0x6a/0x84
[    8.437232] [   T1180]  enable_store+0x95/0xe7 [industrialio]
[    8.437236] [   T1180]  kernfs_fop_write_iter+0x14b/0x200
[    8.437240] [   T1180]  vfs_write+0x21d/0x420
[    8.437244] [   T1180]  ksys_write+0x5e/0xd0
[    8.437246] [   T1180]  do_syscall_64+0x66/0x380
[    8.437250] [   T1180]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[    8.437252] [   T1180] RIP: 0033:0x7f447c6459ee
[    8.437254] [   T1180] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
[    8.437255] [   T1180] RSP: 002b:00007ffc44efa068 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[    8.437257] [   T1180] RAX: ffffffffffffffda RBX: 00007f447c23f940 RCX: 00007f447c6459ee
[    8.437258] [   T1180] RDX: 0000000000000001 RSI: 00007ffc44efa210 RDI: 0000000000000008
[    8.437259] [   T1180] RBP: 00007ffc44efa210 R08: 0000000000000000 R09: 0000000000000000
[    8.437260] [   T1180] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[    8.437261] [   T1180] R13: 0000559507d382a0 R14: 00007f447c78fee0 R15: 0000000000000001
[    8.437263] [   T1180]  </TASK>
[    8.437264] [   T1180] ---[ end trace 0000000000000000 ]---

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.

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?

Bert Karwatzki

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

[Sebastian Andrzej Siewior]

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.
> 
> 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?

> Bert Karwatzki

Sebastian

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

[Bert Karwatzki]

Am Dienstag, dem 03.02.2026 um 09:38 +0100 schrieb Sebastian Andrzej Siewior:
> 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.
> > 
> > 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.

Yes, this should call warn_no_thread() when the interrupt is triggered, but
I don't know if these sensors are actually functional on my laptop (I've never
tried to use them).

So I installed libiio-utils from debian and this is the output from
iio_info:


# iio_info 
iio_info version: 0.26 (git tag:v0.26)
Libiio version: 0.26 (git tag: v0.26) backends: local xml ip usb serial
IIO context created with local backend.
Backend version: 0.26 (git tag: v0.26)
Backend description string: Linux lisa 6.19.0-rc7-next-20260130-iiofix-00001-gc30f943f5645 #293 SMP PREEMPT_DYNAMIC Tue Feb  3 00:32:20 CET 2026 x86_64
IIO context has 2 attributes:
	local,kernel: 6.19.0-rc7-next-20260130-iiofix-00001-gc30f943f5645
	uri: local:
IIO context has 21 devices:
	hwmon0: acpitz
		1 channels found:
			temp1:  (input)
			1 channel-specific attributes found:
				attr  0: input value: 59000
		No trigger on this device
	hwmon1: nvme
		2 channels found:
			temp3:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 77850
				attr  1: label value: Sensor 2
			temp1:  (input)
			6 channel-specific attributes found:
				attr  0: alarm value: 0
				attr  1: crit value: 88850
				attr  2: input value: 29850
				attr  3: label value: Composite
				attr  4: max value: 83850
				attr  5: min value: -20150
		No trigger on this device
	hwmon2: nvme
		4 channels found:
			temp2:  (input)
			4 channel-specific attributes found:
				attr  0: input value: 32850
				attr  1: label value: Sensor 1
				attr  2: max value: 65261850
				attr  3: min value: -273150
			temp6:  (input)
			4 channel-specific attributes found:
				attr  0: input value: 35850
				attr  1: label value: Sensor 5
				attr  2: max value: 65261850
				attr  3: min value: -273150
			temp3:  (input)
			4 channel-specific attributes found:
				attr  0: input value: 30850
				attr  1: label value: Sensor 2
				attr  2: max value: 65261850
				attr  3: min value: -273150
			temp1:  (input)
			6 channel-specific attributes found:
				attr  0: alarm value: 0
				attr  1: crit value: 79850
				attr  2: input value: 31850
				attr  3: label value: Composite
				attr  4: max value: 69850
				attr  5: min value: -273150
		No trigger on this device
	hwmon3: amdgpu
		7 channels found:
			temp3:  (input)
			5 channel-specific attributes found:
				attr  0: crit value: 100000
				attr  1: crit_hyst value: -273150
				attr  2: emergency value: 105000
				attr  3: input value: 46000
				attr  4: label value: mem
			temp2:  (input)
			5 channel-specific attributes found:
				attr  0: crit value: 100000
				attr  1: crit_hyst value: -273150
				attr  2: emergency value: 105000
				attr  3: input value: 46000
				attr  4: label value: junction
			in0:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 6
				attr  1: label value: vddgfx
			power1:  (input)
			6 channel-specific attributes found:
				attr  0: average value: 4000000
				attr  1: cap value: 65000000
				attr  2: cap_default value: 65000000
				attr  3: cap_max value: 65000000
				attr  4: cap_min value: 65000000
				attr  5: label value: PPT
			fan1:  (input)
			5 channel-specific attributes found:
				attr  0: enable value: 0
				attr  1: input value: 0
				attr  2: max value: 3300
				attr  3: min value: 0
				attr  4: target value: 0
			temp1:  (input)
			5 channel-specific attributes found:
				attr  0: crit value: 100000
				attr  1: crit_hyst value: -273150
				attr  2: emergency value: 105000
				attr  3: input value: 46000
				attr  4: label value: edge
			pwm1:  (input)
			4 channel-specific attributes found:
				attr  0: enable value: 2
				attr  1: max value: 255
				attr  2: min value: 0
				attr  3: pwm1 value: 91
		4 device-specific attributes found:
				attr  0: freq1_input value: 0
				attr  1: freq1_label value: sclk
				attr  2: freq2_input value: 96000000
				attr  3: freq2_label value: mclk
		No trigger on this device
	hwmon4: amdgpu
		4 channels found:
			in1:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 962
				attr  1: label value: vddnb
			in0:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 1099
				attr  1: label value: vddgfx
			power1:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 17000000
				attr  1: label value: PPT
			temp1:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 49000
				attr  1: label value: edge
		2 device-specific attributes found:
				attr  0: freq1_input value: 400000000
				attr  1: freq1_label value: sclk
		No trigger on this device
	hwmon5: ADP1
		0 channels found:
		No trigger on this device
	hwmon6: k10temp
		1 channels found:
			temp1:  (input)
			2 channel-specific attributes found:
				attr  0: input value: 56500
				attr  1: label value: Tctl
		No trigger on this device
	hwmon7: BAT1
		2 channels found:
			in0:  (input)
			1 channel-specific attributes found:
				attr  0: input value: 15801
			curr1:  (input)
			1 channel-specific attributes found:
				attr  0: input value: 0
		No trigger on this device
	hwmon8: mt7921_phy0
		1 channels found:
			temp1:  (input)
			1 channel-specific attributes found:
				attr  0: input value: 42000
		No trigger on this device
	iio:device0: als (buffer capable)
		6 channels found:
			intensity_both:  (input, index: 0, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 10.000000
				attr  5: scale value: 0.100000000
			illuminance:  (input, index: 1, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 10.000000
				attr  5: scale value: 0.100000000
			colortemp:  (input, WARN:iio_channel_get_type()=UNKNOWN, index: 2, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: -16843009
				attr  4: sampling_frequency value: 10.000000
				attr  5: scale value: 0.100000000
			chromaticity_x:  (input, WARN:iio_channel_get_type()=UNKNOWN, index: 3, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: -1073087296
				attr  4: sampling_frequency value: 10.000000
				attr  5: scale value: 0.100000000
			chromaticity_y:  (input, WARN:iio_channel_get_type()=UNKNOWN, index: 4, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 10.000000
				attr  5: scale value: 0.100000000
			timestamp:  (input, index: 5, format: le:S64/64>>0)
		1 device-specific attributes found:
				attr  0: current_timestamp_clock value: realtime
		2 buffer-specific attributes found:
				attr  0: data_available value: 0
				attr  1: direction value: in
		Current trigger: trigger0(als-dev0)
	iio:device1: als (buffer capable)
		6 channels found:
			intensity_both:  (input, index: 0, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 0.000000
				attr  5: scale value: 0.100000000
			illuminance:  (input, index: 1, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 0.000000
				attr  5: scale value: 0.100000000
			colortemp:  (input, WARN:iio_channel_get_type()=UNKNOWN, index: 2, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 0.000000
				attr  5: scale value: 0.100000000
			chromaticity_x:  (input, WARN:iio_channel_get_type()=UNKNOWN, index: 3, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 0.000000
				attr  5: scale value: 0.100000000
			chromaticity_y:  (input, WARN:iio_channel_get_type()=UNKNOWN, index: 4, format: le:S32/32>>0)
			6 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: hysteresis_relative value: 0.000000
				attr  2: offset value: 0
				attr  3: raw value: 0
				attr  4: sampling_frequency value: 0.000000
				attr  5: scale value: 0.100000000
			timestamp:  (input, index: 5, format: le:S64/64>>0)
		1 device-specific attributes found:
				attr  0: current_timestamp_clock value: realtime
		2 buffer-specific attributes found:
				attr  0: data_available value: 0
				attr  1: direction value: in
		Current trigger: trigger1(als-dev1)
	iio:device2: gyro_3d (buffer capable)
		4 channels found:
			anglvel_x:  (input, index: 0, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 0.000000
				attr  4: scale value: 0.000174532
			anglvel_y:  (input, index: 1, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 0.000000
				attr  4: scale value: 0.000174532
			anglvel_z:  (input, index: 2, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 0.000000
				attr  4: scale value: 0.000174532
			timestamp:  (input, index: 3, format: le:S64/64>>0)
		1 device-specific attributes found:
				attr  0: current_timestamp_clock value: realtime
		2 buffer-specific attributes found:
				attr  0: data_available value: 0
				attr  1: direction value: in
		Current trigger: trigger2(gyro_3d-dev2)
	iio:device3: prox (buffer capable)
		1 channels found:
			proximity0:  (input, index: 0, format: le:s8/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis ERROR: Invalid argument (22)
				attr  1: offset value: 0
				attr  2: raw value: 15
				attr  3: sampling_frequency value: 10.000000
				attr  4: scale value: 1.000000000
		2 buffer-specific attributes found:
				attr  0: data_available value: 0
				attr  1: direction value: in
		Current trigger: trigger4(prox-dev3)
	iio:device4: accel_3d (buffer capable)
		4 channels found:
			accel_x:  (input, index: 0, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 10.000000
				attr  4: scale value: 0.098066500
			accel_y:  (input, index: 1, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 10.000000
				attr  4: scale value: 0.098066500
			accel_z:  (input, index: 2, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 10.000000
				attr  4: scale value: 0.098066500
			timestamp:  (input, index: 3, format: le:S64/64>>0)
		1 device-specific attributes found:
				attr  0: current_timestamp_clock value: realtime
		2 buffer-specific attributes found:
				attr  0: data_available value: 0
				attr  1: direction value: in
		Current trigger: trigger3(accel_3d-dev4)
	iio:device5: magn_3d (buffer capable)
		3 channels found:
			magn_x:  (input, index: 0, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 0.000000
				attr  4: scale value: 0.000001000
			magn_y:  (input, index: 1, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 0.000000
				attr  4: scale value: 0.000001000
			magn_z:  (input, index: 2, format: le:S32/32>>0)
			5 channel-specific attributes found:
				attr  0: hysteresis value: 0.000000
				attr  1: offset value: 0
				attr  2: raw value: 0
				attr  3: sampling_frequency value: 0.000000
				attr  4: scale value: 0.000001000
		2 buffer-specific attributes found:
				attr  0: data_available value: 0
				attr  1: direction value: in
		Current trigger: trigger5(magn_3d-dev5)
	trigger0: als-dev0
		0 channels found:
		No trigger on this device
	trigger1: als-dev1
		0 channels found:
		No trigger on this device
	trigger2: gyro_3d-dev2
		0 channels found:
		No trigger on this device
	trigger3: accel_3d-dev4
		0 channels found:
		No trigger on this device
	trigger4: prox-dev3
		0 channels found:
		No trigger on this device
	trigger5: magn_3d-dev5
		0 channels found:
		No trigger on this device

The iio:device* sensors all report 0 for the "offset value", so these
sensors are maybe non-fuctional.


> What did I miss?

I don't think you missed something, but the thread function being NULL here
could a problem on devices where these sensors actually work. (Or perhaps these sensors
need to be polled and the interrupts never trigger (?))

Bert Karwatzki
> 

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

[Sebastian Andrzej Siewior]

On 2026-02-03 11:43:53 [+0100], Bert Karwatzki wrote:
> Yes, this should call warn_no_thread() when the interrupt is triggered, but
> I don't know if these sensors are actually functional on my laptop (I've never
> tried to use them).
> 
> So I installed libiio-utils from debian and this is the output from
> iio_info:
…
> 
> The iio:device* sensors all report 0 for the "offset value", so these
> sensors are maybe non-fuctional.
> 
> 
> > What did I miss?
> 
> I don't think you missed something, but the thread function being NULL here
> could a problem on devices where these sensors actually work. (Or perhaps these sensors
> need to be polled and the interrupts never trigger (?))

I only found one handler where the thread handler was NULL and it
returned WAKE_THREAD. So this _is_ broken.
Was it one of the driver I mentioned? If so I suggest to fix those
first. I have no idea how this should work…

> Bert Karwatzki

Sebastian

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

[Jonathan Cameron]

On Tue, 3 Feb 2026 15:58:56 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> On 2026-02-03 11:43:53 [+0100], Bert Karwatzki wrote:
> > Yes, this should call warn_no_thread() when the interrupt is triggered, but
> > I don't know if these sensors are actually functional on my laptop (I've never
> > tried to use them).
> > 
> > So I installed libiio-utils from debian and this is the output from
> > iio_info:  
> …
> > 
> > The iio:device* sensors all report 0 for the "offset value", so these
> > sensors are maybe non-fuctional.
> > 
> >   
> > > What did I miss?  
> > 
> > I don't think you missed something, but the thread function being NULL here
> > could a problem on devices where these sensors actually work. (Or perhaps these sensors
> > need to be polled and the interrupts never trigger (?))  
> 
> I only found one handler where the thread handler was NULL and it
> returned WAKE_THREAD. So this _is_ broken.
> Was it one of the driver I mentioned? If so I suggest to fix those
> first. I have no idea how this should work…
Both the drivers that are called out in this discussion look to
be registering a triggered buffer, but are not using a trigger to fill
it. So they should not be doing that in the first place.

The right fix is either to not use those helpers at all and register
the kfifo directly (so none of the problem infrastructure is used) or
implement a proper trigger / buffer separation by having their interrupt
handlers as the trigger then moving the data reading into the pollfuncs.
At that point there would be a thread here to do that read and we'd
not have the bug.

Jonathan

> 
> > Bert Karwatzki  
> 
> Sebastian

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

[srinivas pandruvada]

On Sat, 2026-02-07 at 15:46 +0000, Jonathan Cameron wrote:
> On Tue, 3 Feb 2026 15:58:56 +0100
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> > On 2026-02-03 11:43:53 [+0100], Bert Karwatzki wrote:
> > > Yes, this should call warn_no_thread() when the interrupt is
> > > triggered, but
> > > I don't know if these sensors are actually functional on my
> > > laptop (I've never
> > > tried to use them).
> > > 
> > > So I installed libiio-utils from debian and this is the output
> > > from
> > > iio_info:  
> > …
> > > 
> > > The iio:device* sensors all report 0 for the "offset value", so
> > > these
> > > sensors are maybe non-fuctional.
> > > 
> > >   
> > > > What did I miss?  
> > > 
> > > I don't think you missed something, but the thread function being
> > > NULL here
> > > could a problem on devices where these sensors actually work. (Or
> > > perhaps these sensors
> > > need to be polled and the interrupts never trigger (?))  
> > 
> > I only found one handler where the thread handler was NULL and it
> > returned WAKE_THREAD. So this _is_ broken.
> > Was it one of the driver I mentioned? If so I suggest to fix those
> > first. I have no idea how this should work…
> Both the drivers that are called out in this discussion look to
> be registering a triggered buffer, but are not using a trigger to
> fill
> it. So they should not be doing that in the first place.

Replacing with devm_iio_kfifo_buffer_setup_ext() breaks user space on
laptops as they expect current_trigger. This is not available for
INDIO_BUFFER_SOFTWARE. Using INDIO_BUFFER_TRIGGERED doesn't help
without poll function. Still breaks user space. This all works from
Linux 3.1x in this mode.

Sensors are powered off till user space writes to current_trigger which
results in call to .set_trigger_state() via
iio_trigger_attach_poll_func(). 

Here the hub is pushing data, not pulled to register a thread handler
and read.

So not sure what to add to thread handler other than dummy function.
 

Thanks,
Srinivas

> 
> The right fix is either to not use those helpers at all and register
> the kfifo directly (so none of the problem infrastructure is used) or
> implement a proper trigger / buffer separation by having their
> interrupt
> handlers as the trigger then moving the data reading into the
> pollfuncs.
> At that point there would be a thread here to do that read and we'd
> not have the bug.
> 
> Jonathan
> 
> > 
> > > Bert Karwatzki  
> > 
> > Sebastian

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

[Jonathan Cameron]

On Sun, 08 Feb 2026 18:00:53 -0800
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:

> On Sat, 2026-02-07 at 15:46 +0000, Jonathan Cameron wrote:
> > On Tue, 3 Feb 2026 15:58:56 +0100
> > Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> >   
> > > On 2026-02-03 11:43:53 [+0100], Bert Karwatzki wrote:  
> > > > Yes, this should call warn_no_thread() when the interrupt is
> > > > triggered, but
> > > > I don't know if these sensors are actually functional on my
> > > > laptop (I've never
> > > > tried to use them).
> > > > 
> > > > So I installed libiio-utils from debian and this is the output
> > > > from
> > > > iio_info:    
> > > …  
> > > > 
> > > > The iio:device* sensors all report 0 for the "offset value", so
> > > > these
> > > > sensors are maybe non-fuctional.
> > > > 
> > > >     
> > > > > What did I miss?    
> > > > 
> > > > I don't think you missed something, but the thread function being
> > > > NULL here
> > > > could a problem on devices where these sensors actually work. (Or
> > > > perhaps these sensors
> > > > need to be polled and the interrupts never trigger (?))    
> > > 
> > > I only found one handler where the thread handler was NULL and it
> > > returned WAKE_THREAD. So this _is_ broken.
> > > Was it one of the driver I mentioned? If so I suggest to fix those
> > > first. I have no idea how this should work…  
> > Both the drivers that are called out in this discussion look to
> > be registering a triggered buffer, but are not using a trigger to
> > fill
> > it. So they should not be doing that in the first place.  
> 
> Replacing with devm_iio_kfifo_buffer_setup_ext() breaks user space on
> laptops as they expect current_trigger. This is not available for
> INDIO_BUFFER_SOFTWARE. Using INDIO_BUFFER_TRIGGERED doesn't help
> without poll function. Still breaks user space. This all works from
> Linux 3.1x in this mode.

Ah ok.  So I wouldn't have gone in this direction in the first
place. Obviously I missed it at the time ;(
Given where we are we can't remove it without breaking backwards compatibility.
I thought we'd long ago taught userspace to handle devices with untriggered
buffers but as ever with ABI we can never assume that's universal (and maybe
not even common!)  IIRC the reason untriggered buffers became common
was when device with hardware FIFOs came along and the trigger is still there
but never visible to software.  Which is kind of similar to the cases you
are referring to I think.

> 
> Sensors are powered off till user space writes to current_trigger which
> results in call to .set_trigger_state() via
> iio_trigger_attach_poll_func(). 

With hindsight I'm not sure why we'd do that rather than doing it in the
buffer enable, but we are stuck so that doesn't matter now.

> 
> Here the hub is pushing data, not pulled to register a thread handler
> and read.
> 
> So not sure what to add to thread handler other than dummy function.

Yes, let's do that but add a note to it saying that it should not
be copied into new drivers + can we throw a big warning print in the
dummy handler and stop proving a meaningless top half?

We have a few really annoying corner cases where a 'fake' current trigger
is used to switch between types of trigger. This is usually for wiring
up various in device signals rather than having software in the path.
Those would need a different rethink if we get a new one of those.
They aren't common.

Jonathan


>  
> 
> Thanks,
> Srinivas
> 
> > 
> > The right fix is either to not use those helpers at all and register
> > the kfifo directly (so none of the problem infrastructure is used) or
> > implement a proper trigger / buffer separation by having their
> > interrupt
> > handlers as the trigger then moving the data reading into the
> > pollfuncs.
> > At that point there would be a thread here to do that read and we'd
> > not have the bug.
> > 
> > Jonathan
> >   
> > >   
> > > > Bert Karwatzki    
> > > 
> > > Sebastian  
> 

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

[Jonathan Cameron]

On Sat, 14 Feb 2026 15:00:42 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Sun, 08 Feb 2026 18:00:53 -0800
> srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> 
> > On Sat, 2026-02-07 at 15:46 +0000, Jonathan Cameron wrote:  
> > > On Tue, 3 Feb 2026 15:58:56 +0100
> > > Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> > >     
> > > > On 2026-02-03 11:43:53 [+0100], Bert Karwatzki wrote:    
> > > > > Yes, this should call warn_no_thread() when the interrupt is
> > > > > triggered, but
> > > > > I don't know if these sensors are actually functional on my
> > > > > laptop (I've never
> > > > > tried to use them).
> > > > > 
> > > > > So I installed libiio-utils from debian and this is the output
> > > > > from
> > > > > iio_info:      
> > > > …    
> > > > > 
> > > > > The iio:device* sensors all report 0 for the "offset value", so
> > > > > these
> > > > > sensors are maybe non-fuctional.
> > > > > 
> > > > >       
> > > > > > What did I miss?      
> > > > > 
> > > > > I don't think you missed something, but the thread function being
> > > > > NULL here
> > > > > could a problem on devices where these sensors actually work. (Or
> > > > > perhaps these sensors
> > > > > need to be polled and the interrupts never trigger (?))      
> > > > 
> > > > I only found one handler where the thread handler was NULL and it
> > > > returned WAKE_THREAD. So this _is_ broken.
> > > > Was it one of the driver I mentioned? If so I suggest to fix those
> > > > first. I have no idea how this should work…    
> > > Both the drivers that are called out in this discussion look to
> > > be registering a triggered buffer, but are not using a trigger to
> > > fill
> > > it. So they should not be doing that in the first place.    
> > 
> > Replacing with devm_iio_kfifo_buffer_setup_ext() breaks user space on
> > laptops as they expect current_trigger. This is not available for
> > INDIO_BUFFER_SOFTWARE. Using INDIO_BUFFER_TRIGGERED doesn't help
> > without poll function. Still breaks user space. This all works from
> > Linux 3.1x in this mode.  
> 
> Ah ok.  So I wouldn't have gone in this direction in the first
> place. Obviously I missed it at the time ;(
> Given where we are we can't remove it without breaking backwards compatibility.
> I thought we'd long ago taught userspace to handle devices with untriggered
> buffers but as ever with ABI we can never assume that's universal (and maybe
> not even common!)  IIRC the reason untriggered buffers became common
> was when device with hardware FIFOs came along and the trigger is still there
> but never visible to software.  Which is kind of similar to the cases you
> are referring to I think.
> 
> > 
> > Sensors are powered off till user space writes to current_trigger which
> > results in call to .set_trigger_state() via
> > iio_trigger_attach_poll_func().   
> 
> With hindsight I'm not sure why we'd do that rather than doing it in the
> buffer enable, but we are stuck so that doesn't matter now.
> 
> > 
> > Here the hub is pushing data, not pulled to register a thread handler
> > and read.
> > 
> > So not sure what to add to thread handler other than dummy function.  
> 
> Yes, let's do that but add a note to it saying that it should not
> be copied into new drivers + can we throw a big warning print in the
> dummy handler and stop proving a meaningless top half?

Actually. Given neither handler make sense (top half or thread), can we
check for both being NULL and then just not register the interrupt at
all?  Then we just need a bit of documentation to say what that
'special' set of parameters means.

I think that just means not allocating + assigning the pollfunc but
I haven't chased through to make sure that works and I'd imagine the tear
down path will need to handle that differently.

Another nastier route that might work that I'm a bit less keen on is
register the buffer without trigger and then set the modes manually
to include a triggered one so current_trigger gets created.  If that
works then we'd want some very careful documentation + maybe helpers as that
feels a bit too much like we are taking advantage of an internal implementation
detail rather than something that will obviously work.

Jonathan


> 
> We have a few really annoying corner cases where a 'fake' current trigger
> is used to switch between types of trigger. This is usually for wiring
> up various in device signals rather than having software in the path.
> Those would need a different rethink if we get a new one of those.
> They aren't common.
> 
> Jonathan
> 
> 
> >  
> > 
> > Thanks,
> > Srinivas
> >   
> > > 
> > > The right fix is either to not use those helpers at all and register
> > > the kfifo directly (so none of the problem infrastructure is used) or
> > > implement a proper trigger / buffer separation by having their
> > > interrupt
> > > handlers as the trigger then moving the data reading into the
> > > pollfuncs.
> > > At that point there would be a thread here to do that read and we'd
> > > not have the bug.
> > > 
> > > Jonathan
> > >     
> > > >     
> > > > > Bert Karwatzki      
> > > > 
> > > > Sebastian    
> >   
> 

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

[srinivas pandruvada]

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.
> > 
> > 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.


Thanks,
Srinivas



> > Bert Karwatzki
> 
> Sebastian

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

[Jonathan Cameron]

On Tue, 03 Feb 2026 09:29:25 -0800
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> 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.
> > > 
> > > 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.
 
Jonathan

> 
> 
> Thanks,
> Srinivas
> 
> 
> 
> > > Bert Karwatzki  
> > 
> > Sebastian  

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@linux.intel.com> 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.

---
From e8385576498ad2f833f89af650e3dbc230c91fc0 Mon Sep 17 00:00:00 2001
From: David Lechner <dlechner@baylibre.com>
Date: Sun, 1 Mar 2026 16:53:48 -0600
Subject: [PATCH] iio: hid-sensors: trigger: use no_action for non-interrupt
 trigger

Use the no_action special function to indicate that we aren't actually
using the interrupt for the trigger registered in hid-sensor-trigger.c.

Due to recent changes in the irq subsystem, we are now getting a warning
about a threaded interrupt being registered with only a handler for the
top half.

Signed-off-by: David Lechner <dlechner@baylibre.com>
---
 drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 6 +++++-
 1 file changed, 5 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..11660adb644a 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -239,8 +239,12 @@ int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char *name,
 	else
 		fifo_attrs = NULL;
 
+	/*
+	 * There is no interrupt for the trigger. We are just using this to have
+	 * a trigger automatically attached to the buffer.
+	 */
 	ret = iio_triggered_buffer_setup_ext(indio_dev,
-					     &iio_pollfunc_store_time, NULL,
+					     NULL, no_action,
 					     IIO_BUFFER_DIRECTION_IN,
 					     NULL, fifo_attrs);
 	if (ret) {
-- 
2.43.0

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

[David Lechner]

On 3/1/26 5:17 PM, David Lechner wrote:
> On 2/7/26 9:42 AM, Jonathan Cameron wrote:
>> On Tue, 03 Feb 2026 09:29:25 -0800
>> srinivas pandruvada <srinivas.pandruvada@linux.intel.com> 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.
>     

...

> 
> I saw that Jonathan mentioned some other more thorough approaches in
> a later reply, but here is the "quick fix" I came up with.
> 
I later found [1] that has an alternate fix, so no need to reply
about my "solution" here.

[1]: https://lore.kernel.org/linux-iio/20260220224514.471348-1-srinivas.pandruvada@linux.intel.com/

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

[David Lechner]

On 2/3/26 2:38 AM, 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.
>>
>> 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

I think we also have in the list:

- drivers/iio/adc/stm32-dfsdm-adc.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?
> 
>> Bert Karwatzki
> 
> Sebastian
>