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

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

[Matthias Schiffer]

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/

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

[Andrew Lunn]

> 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)?

By the time mv88e6xxx_g2_eeprom_wait() is called, we have detected the
chip, and know what it is. We have the chip->info->ops structure. So
maybe add an op to be used in mv88e6xxx_hardware_reset() to wait for
the EEPROM to be idle? You can then have the family 6250 use a
different mechanism to all the other devices.

	  Andrew