Re: [PATCH v2 3/4] iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO

["Nuno Sá" <noname.nuno@gmail.com>]

On Mon, 2024-10-28 at 17:07 +0100, Uwe Kleine-König wrote:
> Some of the ADCs by Analog signal their irq condition on the MISO line.
> So typically that line is connected to an SPI controller and a GPIO. The
> GPIO is used as input and the respective interrupt is enabled when the
> last SPI transfer is completed.
> 
> Depending on the GPIO controller the toggling MISO line might make the
> interrupt pending even while it's masked. In that case the irq handler
> is called immediately after irq_enable() and so before the device
> actually pulls that line low which results in non-sense values being
> reported to the upper layers.
> 
> The only way to find out if the line was actually pulled low is to read
> the GPIO. (There is a flag in AD7124's status register that also signals
> if an interrupt was asserted, but reading that register toggles the MISO
> line and so might trigger another spurious interrupt.)
> 
> Add the possibility to specify an interrupt GPIO in the machine
> description instead of a plain interrupt. This GPIO is used as interrupt
> source and to check if the irq line is actually active in the irq
> handler.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---

Hi all,

Regarding this, I do share some of the concerns already raised by Jonathan. I fear
that we're papering around an issue with the IRQ controller rather than being an
issue with the device. When I look at irq_disable() docs [1], it feels that we're
already doing what we're supposed to do. IOW, we disable the lazy approach so we
*should* not get any pending IRQ. Also looking at drivers as the xilinx gpio
controller, it seems some are careful about this [2] and make sure to clear all
pending IRQs when unmasking.

Jonathan also said this:

"True enough - that race is a possibility, but not all interrupt inputs
are capable of gpio usage whilst setup to received interrupts."

To my understanding this also means this is doomed to fail for some devices or am I
not following it?

All that said, my naive feeling would be for a masked line to not get any pending IRQ
and if it does, the driver should make sure to clean all outstanding interrupts when
unmasking. But I'm far from being an expert of the IRQ subsystem. Maybe it would be
interesting to get some inputs about someone who actually knows better?

[1]: https://elixir.bootlin.com/linux/v6.11.5/source/kernel/irq/chip.c#L366
[2]: https://elixir.bootlin.com/linux/v6.11.5/source/kernel/irq/chip.c#L366

- Nuno Sá