i2c: smbus: Improve handling of stuck alerts
The following messages were observed while testing alert functionality on systems with multiple I2C devices on a single bus if alert was active on more than one chip. smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()! and: smbus_alert 3-000c: SMBALERT# from dev 0x28, flag 0 Once it starts, this message repeats forever at high rate. There is no device at any of the reported addresses. Analysis shows that this is seen if multiple devices have the alert pin active. Apparently some devices do not support SMBus arbitration correctly. They keep sending address bits after detecting an address collision and handle the collision not at all or too late. Specifically, address 0x0c is seen with ADT7461A at address 0x4c and ADM1021 at address 0x18 if alert is active on both chips. Address 0x28 is seen with ADT7483 at address 0x2a and ADT7461 at address 0x4c if alert is active on both chips. Once the system is in bad state (alert is set by more than one chip), it often only recovers by power cycling. To reduce the impact of this problem, abort the endless loop in smbus_alert() if the same address is read more than once and not handled by a driver. Fixes: b5527a77 ("i2c: Add SMBus alert support") Signed-off-by: Guenter Roeck <linux@roeck-us.net> [wsa: it also fixed an interrupt storm in one of my experiments] Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> [wsa: rebased, moved a comment as well, improved the 'invalid' value] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Showing
Please register or sign in to comment