linux-kernel - Re: [PATCH 2/2] net: dsa: microchip: Provide Module 4 KSZ9477 errata (DS80000754C)

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] [day] [month] [year] [list]

Message-ID: <20230830101347.0f2aad73@wsk>
Date:   Wed, 30 Aug 2023 10:13:47 +0200
From:   Lukasz Majewski <lukma@...x.de>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Tristram.Ha@...rochip.com, olteanv@...il.com,
        linux@...pel-privat.de, Arun.Ramadoss@...rochip.com,
        f.fainelli@...il.com, andrew@...n.ch, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, Woojung.Huh@...rochip.com,
        pabeni@...hat.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH 2/2] net: dsa: microchip: Provide Module 4 KSZ9477
 errata (DS80000754C)

Hi Oleksij,

> On Tue, Aug 29, 2023 at 10:23:26PM +0000, Tristram.Ha@...rochip.com
> wrote:
> > > Yes, removing linkmod_and() will not should not help. I said, "The
> > > phydev->supported_eee should be cleared."
> > > 
> > > For example like this:
> > > --- a/drivers/net/phy/micrel.c
> > > +++ b/drivers/net/phy/micrel.c
> > > @@ -1400,6 +1400,7 @@ static int ksz9131_config_aneg(struct
> > > phy_device *phydev)
> > > 
> > >  static int ksz9477_get_features(struct phy_device *phydev)
> > >  {
> > > +       __ETHTOOL_DECLARE_LINK_MODE_MASK(zero) = { 0, };
> > >         int ret;
> > > 
> > >         ret = genphy_read_abilities(phydev);
> > > @@ -1413,7 +1414,7 @@ static int ksz9477_get_features(struct
> > > phy_device *phydev)
> > >          * KSZ8563R should have 100BaseTX/Full only.
> > >          */
> > >         linkmode_and(phydev->supported_eee, phydev->supported,
> > > -                    PHY_EEE_CAP1_FEATURES);
> > > +                    zero);
> > > 
> > >         return 0;
> > >  }
> > > 
> > > You will need to clear it only on KSZ9477 variants with this bug.
> > > This change is tested and it works on my KSZ9477-EVB.  
> >  
> > I think this is best for disabling EEE support.
> > I think before some customers asked for Ethtool EEE support not
> > because they want to use it but to disable it because of link
> > instability. KSZ9893/KSZ9563 switches should have the same problem.
> >  The EEE problem depends on the link partner.  For example my
> > laptop does not have problem even though EEE is enabled, although I
> > am not sure if EEE is really active.  The problem here is just
> > using two KSZ9477 switches and programming those PHY setup values
> > and enabling EEE will make the link unstable.  Management decided
> > to disable EEE feature to avoid customer support issues.
> > Another issue is EEE should be disabled when using 1588 PTP.
> >   
> 
> I'd like to share my thoughts on the concerns raised:
> 
> - KSZ9477 & EEE: Disabling EEE for the KSZ9477 makes sense,
> especially since the datasheet doesn't list it as supported.
> 

+1

I will prepare proper patch

> - EEE Support for KSZ9893 & KSZ9563: The datasheets for the KSZ9893
> indicate support for EEE. The erratum recommends making adjustments
> to the "transmit Refresh Time for Waketx to meet the IEEE Refresh
> Time specification" instead of turning it off completely. The same
> applies to KSZ9563. We should consider these adjustments.
> 
> - General Experience with KSZ Chips*: From my experience with these
> chips, irrespective of the EEE functionality, only the 1000/full and
> 100/full link modes tend to be stable enough.
> 
> - Responsibility to Customers and Certifications: As a part of the
> product supply chain, I believe in our commitment to honesty with our
> customers. When we select components for end products, we trust their
> listed features. For instance, designing for ENERGY STAR
> certification requires that all copper-based physical network ports
> in an LNE product must be compliant with IEEE 802.3 Clause 78, which
> mandates Energy Efficient Ethernet. If Microchip promotes a KSZ* chip
> with EEE as a feature, it becomes a cornerstone of the end product.
> Negating a key functionality, which was sold and then incorporated
> into the product, could risk non-compliance with certification
> criteria.
> 
> - Consistency in Product Representation: If the overarching company
> decision is to disable the EEE feature for all chips to preempt
> potential customer support issues, our product information should
> mirror this change. It's crucial that we neither misrepresent nor
> over-promise on features. Your deeper insights, given your
> involvement with Microchip's strategy, would be most enlightening.
> 

For the last two - at least the KSZ9477 Errata was clear about the
issue. Other (switch IC) vendors have even problems to admit that
something is wrong with their silicon design...

> Regards,
> Oleksij




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped