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
| ||
|
Message-ID: <f89e203a-af77-9661-1003-0e9370ff6fab@axis.com> Date: Thu, 1 Jun 2023 11:10:58 +0200 From: Andreas Svensson <andreas.svensson@...s.com> To: Andrew Lunn <andrew@...n.ch> 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>, Paolo Abeni <pabeni@...hat.com>, <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 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 know there are some users who want the switch to boot as fast as > possible, and don't really want the additional 9ms delay. But this is > also a legitimate change. I'm just wondering if we need to consider a > DT property here for those with EEPROM content. Or, if there is an > interrupt line, wait for the EEPROM complete interrupt. We just have > tricky chicken and egg problems. At this point in time, we don't > actually know if the devices exists or not. > > Andrew It just seems like we need to wait longer for the switch 88E6393X until it responds reliably on the MDIO bus. But I'm open to adding a new DT property if that's needed. 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. Best Regards, Andreas Svensson
Powered by blists - more mailing lists