linux-kernel - Re: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset deactivation

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]

Message-ID: <d36ba731c063b3ddace873926cc773426c55ca4a.camel@redhat.com>
Date:   Thu, 01 Jun 2023 12:32:19 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Andreas Svensson <andreas.svensson@...s.com>,
        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>, 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 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