Messages in this thread | | | Subject | Re: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset deactivation | From | Paolo Abeni <> | Date | Thu, 01 Jun 2023 12:32:19 +0200 |
| |
On Thu, 2023-06-01 at 11:10 +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 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.
I read the above as a new version of this fix is coming, thus not applying this patch.
Thanks,
Paolo
| |