Re: [PATCH] iio: iio_triggered_buffer_setup_ext(): request IRQF_ONESHOT only if threaded handler is present

[Marc Kleine-Budde]

On 14.05.2026 16:41:32, Jonathan Cameron wrote:
> Thanks for the report + patch.
> >
> > I'm not sure if this is the correct fix, or if the
> > stm32-adc.c/stm32-dfsdm-adc.c driver needs fixing.
>
> Sounds like another case of what we had to fix for hid-sensors (and a few others
> IIRC).
>
> They should never have been using triggers in the first place for this path -
> but now we have ABI we can't touch.  Note there are even comments saying that
> the infrastructure registered is not used!
>
> So we have to have do a small dance to ensure the sysfs files are still created
> but without the need for the pollfunc setup etc.
>
> https://lore.kernel.org/all/20260220224514.471348-1-srinivas.pandruvada@xxxxxxxxxxxxxxx/
>
> It is in theory possible to have a case that needs the fix you have below
> but that would not be using iio_pollfunc_store_time().
> That being used without a thread is pretty much pointless as no one reads
> the timestamp.
>
> I took a look just at stm32_adc and things are more complex because in some
> cases we should be registering a triggered buffer (with both top and bottom
> half set) and in some cases we should not - but should be doing what we
> did in the hid sensors.
>
> Given I believe this is a harmless warning I'm not in a huge rush to fix it.

It's a warning including a stack trace:

| ------------[ cut here ]------------
| WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x104/0x81c, CPU#1: adc-stm32/370
| Modules linked in:
| CPU: 1 UID: 0 PID: 370 Comm: adc-stm32 Not tainted 7.1.0-rc3+ #2 PREEMPT  dba7a20aa885d5558721d75378dc67d9c58ca68c
| Hardware name: STM32 (Device Tree Support)
| Call trace:
|  unwind_backtrace from show_stack+0x18/0x1c
|  show_stack from dump_stack_lvl+0x50/0x64
|  dump_stack_lvl from __warn+0x98/0x178
|  __warn from warn_slowpath_fmt+0x1a4/0x1ac
|  warn_slowpath_fmt from __setup_irq+0x104/0x81c
|  __setup_irq from request_threaded_irq+0xb8/0x14c
|  request_threaded_irq from iio_trigger_attach_poll_func+0xa8/0x1a4
|  iio_trigger_attach_poll_func from __iio_update_buffers+0xab8/0xb6c
|  __iio_update_buffers from enable_store+0x84/0xd4
|  enable_store from kernfs_fop_write_iter+0x154/0x220
|  kernfs_fop_write_iter from vfs_write+0x27c/0x4fc
|  vfs_write from ksys_write+0x68/0xf0
|  ksys_write from ret_fast_syscall+0x0/0x54
| Exception stack(0xe12f9fa8 to 0xe12f9ff0)
| 9fa0:                   00000000 00000000 00000009 01ad2358 00000002 00000000
| 9fc0: 00000000 00000000 0f387d24 00000004 01accc68 01ad13b8 01accc68 b5ffe44c
| 9fe0: b5ffdf08 b5ffdef4 b6d34659 b6d3d038
| ---[ end trace 0000000000000000 ]---

which looks quite scary :)

> We need someone who has the time + hardware to test solutions as they
> can be a bit fiddly.

We have the hardware, we're happy to test patches.

> Whilst the code you have here papers over the problem it's changing from
> having an entirely correct warning to hiding that the code is wrong so
> I'd rather not merge that.  I've rejected it as a proposed solution a couple
> of times so far - and thought we were getting to the end of drivers that abused
> this stuff :(  Seems not quite yet.

regards,
Marc

--
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Attachment: signature.asc
Description: PGP signature