Hi Guenter,
as I mentioned before I now have to deal with SMBusAlert as well and had
a chance to review and test this series. When developing the SMBAlert
trigger mechanism for the i2c testunit, I also experienced the interrupt
storm and your patches helped. See later mails for details.
Note that there is one situation which is not addressed by this set of
patches: If the corrupted address points to yet another device with alert
handler on the same bus, the alert handler of that device will be called.
If it is not a source of the alert, we are back to the original problem.
I do not know how to address this case.
I think this can only work if we require .alert-handlers to start with a
sanity check to make sure their device really raised an interrupt
condition. And then return either -EBUSY or 0, similar to IRQ_HANDLED or
IRQ_NONE. Or?