netdev - Re: [PATCH] net: dsa: mv88e6xxx: Wait for EEPROM done after HW reset

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: <20201118112623.4eb9bb8a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Wed, 18 Nov 2020 11:26:23 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "Ruslan V. Sushko" <rus@...hko.dev>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: dsa: mv88e6xxx: Wait for EEPROM done after HW
 reset

On Wed, 18 Nov 2020 20:10:17 +0100 Andrew Lunn wrote:
> On Wed, Nov 18, 2020 at 10:52:51AM -0800, Jakub Kicinski wrote:
> > On Mon, 16 Nov 2020 08:43:01 -0800 Ruslan V. Sushko wrote:  
> > > From: Andrew Lunn <andrew@...n.ch>
> > > 
> > > When the switch is hardware reset, it reads the contents of the
> > > EEPROM. This can contain instructions for programming values into
> > > registers and to perform waits between such programming. Reading the
> > > EEPROM can take longer than the 100ms mv88e6xxx_hardware_reset() waits
> > > after deasserting the reset GPIO. So poll the EEPROM done bit to
> > > ensure it is complete.
> > > 
> > > Signed-off-by: Andrew Lunn <andrew@...n.ch>
> > > Signed-off-by: Ruslan Sushko <rus@...hko.dev>  
> > 
> > Andrew, do we need this in net?  
> 
> I was wondering about that. I actually recommend leaving the EEPROM
> empty. The driver has no idea what magic the EEPROM has done, and so
> will stomp over it, or make assumptions which are not true about
> register values.
> 
> But Zodiac has valid use cases of putting stuff into the EEPROM, and
> they are aware of the danger. And this patch has got lost at least
> once, causing lots of head scratching. So getting it into 5.10 makes
> sense for them. I don't think it needs to go further back.
> 
> Not sure what Fixes: tag to use.

Ack, sound reasonable. Applying to net and not queuing, thanks!