Re: [PATCH] iio: light: gp2ap020a00f: drain irq_work after free_irq

Hi Jonathan,

Thanks for the review and for applying the fix.

Yes, happy to take that on. I agree iio_trigger_poll_nested() is a
better fit here, given the device IRQ handler is already threaded.

I'll prepare a follow-up on top of this patch.

Thanks,
Fan

> On Aug 17, 2026, at 01:46, Jonathan Cameron <[email protected]> wrote:
> 
> Hi,
> 
> Thanks for the patch. It looks correct to me but this is an old driver
> and we'd not use an irq work at all these days. The reason it was used
> was to ensure we could use the trigger from this device to drive capture
> on another one that needed a top half.  However the top half (non threaded
> bit) of trigger handlers only ever gets a timestamp, so we end up dancing
> through
> threaded_irq->irq_work->iio_pollfunc_get_timestamp->actualhander.
> which almost certainly gives a less useful timestamp than
> threaded_irq->actuallhandler without the irq_work part.
> The slight risk is someone is actually using that timestamp in
> a consumer and will find pf->timestamp is now always 0.  However
> I think that's very unlikely with a light sensor (sensor fusion
> doesn't really occur much like it does for inertial sensors)
> 
> So I think a better solution given you've identified a bug here, would be
> to rip out the irq_work dance in favour of a direct call to
> iio_trigger_poll_nested() instead of irq_work_queue() in 
> gp2ap020a00f_thresh_event_handler()
> 
> That would mean also grabbing a timestamp locally in
> gp2ap020a00f_trigger_handler() rather than using pf->timestamp()
> + dropping the use of iio_pollfunc_store_time.
> 
> A more invasive change, but one that lands us with a more modern solution
> and removes the problematic code entirely.
> 
> Do you feel like taking that challenge on?  If so do it on top
> of this patch because this one is going to be easier to backport.
> 
> Applied to the fixes-togreg branch of iio.git but note that won't
> go upstream until after rc1 is released (and I'll rebase on that)
> 
> Thanks,
> 
> Jonathan
>>