RE: [PATCH v4 2/2] iio: adc: ad_sigma_delta: fix clear_pending_event for registerless devices

[Sabau, Radu bogdan]

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx>
> Sent: Friday, May 22, 2026 6:21 PM

...

> > David raised this on v2.
> >
> > This sounds suspiciously like we are in implementation defined territory.
> > IIRC if an irq is disabled, whether the interrupt is latched is down
> > to whether the irq controller happens to do so. There is no hard rule on this
> > or way to detect whether it will or not.
> >
> >
> https://lore.kernel.org/all/io53lznz3qp3jd5rohqsjhosnmdzd6d44sdbwu5jcfr
> s3rz2a2@orquwgflrtyc/
> > Was I think the most recent detailed thread on this.
> >
> > Uwe - you were driving that discussion can you sanity check what we have
> > here if you have a moment?  Thanks!
> 
> Without having looked at the code but skimmed through the old discussion
> again, the result back then was that you won't get reliable behaviour
> without rdy-gpio.
> 
> I didn't try to understand what's different fro "registerless devices",
> but I doubt this implements a robust solution.
> 

Hi everyone,

Thank you so much for looking into this. The concern about IRQ latching is valid,
and after looking more carefully at this I can see the commit message explanation
is simply wrong.

IRQ_DISABLE_UNLAZY I think actually does the opposite... it causes immediate hw
masking when disable_irq_nosync() is called, precisely to prevent spurious interrupts
from MISO. So the claim that it "keeps the hardware IRQ line unmasked while
software-disabled" was backwards. However, as Jonathan says this is implementation
defined territory, but perhaps the comment and commit message could still be corrected.

But, I think return 0 could still be safe, devices with rdy-gpios use that, the ones without
but with registers use the status register and the others which have neither (in our case
ad7191, ad7780 and max11205 as far as I can tell) could safely use return 0 branch from
here and this is why I think its safe:

- ad7191: CS is the PDOWN pin - deasserting it powers down and resets the device. By the
time clear_pending_event() is called at the start of a new conversion, the device has been
reset and there should not be any stale result to clear.
- ad7780 (with powrdown GPIO): same - device is powered down between conversions.
- ad7780 (without powerdown GPIO) and max11205: both are continuously-converting ADCs
that cycle ~DRDY at their output data rate regardless of whether the previous result was read.
The next conversion's falling edge fires naturally.

One limitation still remains (beside the risk of missing a sample for the last case): a future
registerless device (has_registers = false) that holds ~RDY asserted until data is read would
need either num_resetclks set or a rdy-gpio. Perhaps a comment would be useful here.

With Best Regards,
Radu