netdev - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <b3f72f80-e41d-4abd-bb6f-10f3b58e65c1@lunn.ch>
Date: Wed, 17 Apr 2024 15:56:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Matthias Schiffer <matthias.schiffer@...tq-group.com>
Cc: Fabio Estevam <festevam@...x.de>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Michael Krummsdorf <michael.krummsdorf@...group.com>,
	netdev@...r.kernel.org, linux@...tq-group.com
Subject: Re: Regression: Commit "net: dsa: mv88e6xxx: Avoid EEPROM timeout
 when EEPROM is absent" *causing* timeouts after kernel update

> 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