[lkml]   [2023]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset deactivation
 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 <>

You probably need to repost with my Reviewed-by added, now that Paolo
has changed the status of the patch.


 \ /
  Last update: 2023-06-01 14:03    [W:0.065 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site