netdev - Regression: Commit "net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent" *causing* timeouts after kernel update

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-next>] [day] [month] [year] [list]

Message-ID: <1f22520948180e55125fdc686a0de8a93c317e5f.camel@ew.tq-group.com>
Date: Tue, 16 Apr 2024 16:38:09 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Fabio Estevam <festevam@...x.de>, Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>, Michael Krummsdorf
	 <michael.krummsdorf@...group.com>, netdev@...r.kernel.org, 
	linux@...tq-group.com
Subject: Regression: Commit "net: dsa: mv88e6xxx: Avoid EEPROM timeout when
 EEPROM is absent" *causing* timeouts after kernel update

Hi all,

we are currently updating an i.MX8MN-based board from Linux 6.1.y to 6.6.26, and we are seeing a new
error message during the probe of an MV88E6020 switch:

[   11.330629] mv88e6085 30be0000.ethernet-1:10: switch 0x200 detected: Marvell 88E6020, revision 5
[   11.395525] mv88e6085 30be0000.ethernet-1:10: Timeout while waiting for switch
[   11.496618] mv88e6085 30be0000.ethernet-1:10: Timeout while waiting for switch

As it turns out, these timeouts are caused by the two mv88e6xxx_g2_eeprom_wait() calls introduced in
commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent"), and
reverting just that commit fixes the issue. Our board does not have an EEPROM connected to the
switch.

I've added debug output to mv88e6xxx_g2_eeprom_wait() and found that the busy bit is 0 as expected,
but the running bit is stuck at 1 forever (even when I increase the timeout to something excessive
like 1s).

Any suggestions what the best way to handle this is?

The 88E6520/6020 "Functional Spec" seems to suggest that the old behaviour (waiting for the EEInt
flag) is more appropriate on these models, but I guess we should only do that *after* the hardware
reset, as something else may already have read and cleared the EEInt flag before the kernel probes
the switch otherwise... Maybe something can be done with an explicit EEPROM reload (Global1 Control
register flag RL)?

Best regards,
Matthias

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/