linux-kernel - Re: [PATCH 1/2] i2c: smbus: Improve handling of stuck alerts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZqdJngPM5_4qXy8S@shikoro>
Date: Mon, 29 Jul 2024 09:49:50 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Wolfram Sang <wsa@...nel.org>, Jean Delvare <khali@...ux-fr.org>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] i2c: smbus: Improve handling of stuck alerts

On Mon, Jan 10, 2022 at 09:28:56AM -0800, Guenter Roeck wrote:
> 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: b5527a7766f0 ("i2c: Add SMBus alert support")
> Signed-off-by: Guenter Roeck <linux@...ck-us.net>

Applied to for-current (with the minor changes mentioned before),
thanks!


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)