Re: [PATCH v2 0/2] iio: add IRQF_NO_THREAD to hardirq-only trigger helpers

[Jonathan Cameron <jic23@kernel.org>]

On Thu,  4 Jun 2026 09:42:45 +0800
Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:

> This series fixes two IIO trigger registration sites that pass
> iio_trigger_generic_data_rdy_poll() to request_irq() without
> IRQF_NO_THREAD.
> 
> Both sites are intended to drive iio_trigger_poll() from hardirq
> context, but under forced IRQ threading they can otherwise run through
> irq/... thread context instead.
> 
> This issue was first flagged by our static analysis tool while scanning
> request_irq() sites that register iio_trigger_generic_data_rdy_poll(),
> then manually audited on Linux v6.18.21.
> 
> It was further validated with a no-device QEMU selftest using irq_sim
> to model a parent IRQ and a child IIO trigger IRQ under threadirqs. The
> same trigger path ran from irq/... thread context without IRQF_NO_THREAD
> and stayed in hardirq context after adding IRQF_NO_THREAD. The selftest
> logged:
> 
>   3395 selftest: phase=bad current=irq/30-patchpar in_hardirq=0
>   3395 selftest: phase=fixed current=swapper/0 in_hardirq=1
>   3395 selftest: validation succeeded
> 
> Patch 1 fixes the ADIS non-FIFO managed trigger path.
> Patch 2 fixes the BMI160 data-ready trigger path.
> 
> Build-tested by compiling adis_trigger.o and bmi160_core.o.
> 
> No ADIS or BMI160 hardware was available for end-to-end runtime testing
> on this submission branch.
> 
> Changes in v2:
> - move build/runtime validation notes out of the per-patch commit
>   messages
> 
I forgot to say - there was something corrupted in the 1st patch so
I made the same edit by hand.  That is probably what stopped Sashiko
from looking at these.

Jonathan

> Runyu Xiao (2):
>   iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ
>   iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ
> 
>  drivers/iio/imu/adis_trigger.c       | 3 +--
>  drivers/iio/imu/bmi160/bmi160_core.c | 3 ++-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>