can/should a disabled irq become pending?

[Uwe Kleine-König]

Hello Thomas,

[This mail is about an issue identified in a thread on the linux-iio
mailing list, but I guess you missed that because the Subject isn't
"interesting". See
https://lore.kernel.org/linux-iio/20241030204429.70cdcf35@jic23-huawei.
So here comes a dedicated mail about only this topic in the hope it
attracts your attention.]

The ad7124 ADC and a few cousins of it have the peculiarity to report
their interrupt on the SPI MISO line. So while the SPI clock is toggling
it behaves as MISO and after a transfer it's a falling edge irq signal.

So the driver masks the irq during SPI transfers (using irq_disable()).
It also uses irq_set_status_flags(sigma_delta->irq_line,
IRQ_DISABLE_UNLAZY);

Now on some irq controllers (e.g. the rpi GPIO controller) the detection
logic is off between calls to irq_disable() and irq_enable() and so on
that platform calling irq_enable() makes the irq handler called only on
a real irq, while for other irq controllers (e.g. the Altera GPIO
controller) the SPI transfers make the irq pending and irq_enable()
results in a call of the handler immediately (but very likely before the
device actually asserted the interrupt).

I think (but please correct me) that the latter behaviour has to be
expected and the former is even broken as it might miss irq events.

My conclusions from this are:

 - the ad7124 driver needs some additional logic to check the actual
   line state in the irq handler to differentiate between "real" irqs
   and spurious ones triggered by SPI transfers[1];

 - the rpi GPIO controller should be fixed not to honor
   IRQ_DISABLE_UNLAZY.

Can you confirm these?

Best regards
Uwe

[1] it can only check the level, not a passed edge, but that seems to
    work in practise

Attachment: signature.asc
Description: PGP signature