netdev - Re: [PATCH 2/2] net: phy: 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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 30 Aug 2023 15:23:54 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Eric Dumazet <edumazet@...gle.com>, Andrew Lunn <andrew@...n.ch>,
 davem@...emloft.net, Woojung Huh <woojung.huh@...rochip.com>, Vladimir
 Oltean <olteanv@...il.com>, Tristram.Ha@...rochip.com, Florian Fainelli
 <f.fainelli@...il.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, UNGLinuxDriver@...rochip.com, Russell King
 <linux@...linux.org.uk>, Heiner Kallweit <hkallweit1@...il.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] net: phy: Provide Module 4 KSZ9477 errata
 (DS80000754C)

Hi Oleksij,

> On Wed, Aug 30, 2023 at 01:51:51PM +0200, Lukasz Majewski wrote:
> > Hi Oleksij,  
> 
> > It looks like the most optimal solution would be the one proposed by
> > Tristam:
> > https://www.spinics.net/lists/netdev/msg932044.html  
> 
> In this case, please add the reason why it would work on this HW and
> will not break by any changes in PHYlib or micrel.c driver.
> 

The ksz9477_config_cpu_port() is called from ksz_setup. In this
function we would clear 7.60 MMD register for EEE advertisement.

Only after the switch initialization, the phy code reads 7.60 register
for each port and on that basis decides if the EEE is supported or not.

(And only then ksz9477_get_features() is executed. Finally
ksz_get_phy_flags() is called.

> If I remember it correctly, in KSZ9477 variants, if you write to EEE
> advertisement register, it will affect the state of a EEE capability
> register. Which break IEEE 802.3 specification and the reason why
> ksz9477_get_features() actually exist. But can be used as workaround
> if it is written early enough before PHYlib tried to read EEE
> capability register.
> 
> Please confirm my assumption by applying your workaround and testing
> it with ethtool --show-eee lanX.
> 

# ethtool --show-eee lan1
EEE Settings for lan1:
        EEE status: disabled
        Tx LPI: 0 (us)
        Supported EEE link modes:  100baseT/Full 
                                   1000baseT/Full 
        Advertised EEE link modes:  Not reported
        Link partner advertised EEE link modes:  Not reported
# 
# ethtool --show-eee lan2
EEE Settings for lan2:
        EEE status: disabled
        Tx LPI: 0 (us)
        Supported EEE link modes:  100baseT/Full 
                                   1000baseT/Full 
        Advertised EEE link modes:  Not reported
        Link partner advertised EEE link modes:  Not reported


> It should be commented in the code with all kind of warnings:
> Don't move!!! We use one bug to workaround another bug!!!

As I've pointed out in the previous e-mail. This kind of bug cannot be
easily fixed with modifying flags in ksz_get_phy_flags() as this
function is called after ksz9477_get_features().

I'm open for ideas to do it right...

> If PHYlib
> start scanning PHYs before this code is executed, then thing may
> break!!

Is it possible that PHY lib will start scanning for phys before the DSA
switch IC is probed with SPI?

KSZ9477-EVB DTS is not using "mdio" node - i.e. the "old" scheme for DSA
switch is used.

> 
> ... it is broken as hell....
> 


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