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]
Date: Thu, 01 Jun 2023 15:42:06 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Andrew Lunn <andrew@...n.ch>, Andreas Svensson
 <andreas.svensson@...s.com>
Cc: Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean
 <olteanv@...il.com>,  "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,  kernel@...s.com,
 Baruch Siach <baruch@...s.co.il>, netdev@...r.kernel.org, 
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset
 deactivation

On Thu, 2023-06-01 at 14:01 +0200, Andrew Lunn wrote:
>  On Thu, Jun 01, 2023 at 11:10:58AM +0200, Andreas Svensson wrote:
> > On 5/30/23 19:28, Andrew Lunn wrote:
> > > On Tue, May 30, 2023 at 04:52:23PM +0200, Andreas Svensson wrote:
> > > > A switch held in reset by default needs to wait longer until we can
> > > > reliably detect it.
> > > > 
> > > > An issue was observed when testing on the Marvell 88E6393X (Link Street).
> > > > The driver failed to detect the switch on some upstarts. Increasing the
> > > > wait time after reset deactivation solves this issue.
> > > > 
> > > > The updated wait time is now also the same as the wait time in the
> > > > mv88e6xxx_hardware_reset function.
> > > 
> > > Do you have an EEPROM attached and content in it?
> > 
> > There's no EEPROM attached to the switch in our design.
> > 
> > > 
> > > It is not necessarily the reset itself which is the problem, but how
> > > long it takes after the reset to read the contents of the
> > > EEPROM. While it is doing that, is does not respond on the MDIO
> > > bus. Which is why mv88e6xxx_hardware_reset() polls for that to
> > > complete.
> > 
> > Ok, yes that makes sense. I could add the mv88e6xxx_g1_wait_eeprom_done
> > function after the reset deactivation.
> 
> I don't think that works, because how to talk to the switch is not
> determined until after the switch has been detected.
> 
> > The datasheet for 88E6393X also states that it needs at least 10ms
> > before it's ready. But I suppose this varies from switch to switch.
> 
> O.K, let go with this change and see if anybody really complains. We
> can always add a DT property later.
> 
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
> 
> You probably need to repost with my Reviewed-by added, now that Paolo
> has changed the status of the patch.

Not needed. I can restore the patch in PW.

Thanks,

Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ