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

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

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