netdev - Re: [PATCH RFC 0/7] Clause 45 PHY probing cleanups

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: <20200526154335.GB1551@shell.armlinux.org.uk>
Date:   Tue, 26 May 2020 16:43:35 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Jeremy Linton <jeremy.linton@....com>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC 0/7] Clause 45 PHY probing cleanups

On Tue, May 26, 2020 at 03:29:48PM +0100, Russell King - ARM Linux admin wrote:
> Hi,
> 
> In response to the patch set that Jeremy posted, this is my proposal
> to expand our Clause 45 PHY probing.
> 
> I've taken a slightly different approach, with the view to avoiding
> as much behavioural change as possible.  The biggest difference is
> to do with "devices_in_package" - we were using it for two different
> purposes, which are now separated.
> 
> This is not against net-next nor net trees, but against my own private
> tree, but I'm posting it to serve as an illustration of what I think
> should be done - I knocked this up this morning.
> 
> The only potential regression that I'm expecting is with 88x3310 PHYs
> of the later revision, which have the clause 22 registers implemented.
> I haven't yet checked whether they set bit 0, but if they do, the
> various decision points that we have based on that bit could adversely
> affect this PHY - it needs testing, which I'll do when I dig out the
> appropriate hardware.  Probably also needs the 2110 PHYs checked as
> well.

Tested on the later revision of the 88x3310 PHY with some additional
prints:

orion-mdio f212a600.mdio: scanning prt 0 mmd 1...
orion-mdio f212a600.mdio: prt 0: dip=c000009a
orion-mdio f212a600.mdio: prt 0 mmd 1: id 0x002b09ab
orion-mdio f212a600.mdio: prt 0 mmd 3: id 0x002b09ab
orion-mdio f212a600.mdio: prt 0 mmd 4: id 0x01410dab
orion-mdio f212a600.mdio: prt 0 mmd 7: id 0x002b09ab
orion-mdio f212a600.mdio: prt 0 mmd 30: prs=0
orion-mdio f212a600.mdio: prt 0 mmd 31: prs=0

orion-mdio f212a600.mdio: scanning prt 8 mmd 1...
orion-mdio f212a600.mdio: prt 8: dip=c000009a
orion-mdio f212a600.mdio: prt 8 mmd 1: id 0x002b09ab
orion-mdio f212a600.mdio: prt 8 mmd 3: id 0x002b09ab
orion-mdio f212a600.mdio: prt 8 mmd 4: id 0x01410dab
orion-mdio f212a600.mdio: prt 8 mmd 7: id 0x002b09ab
orion-mdio f212a600.mdio: prt 8 mmd 30: prs=0
orion-mdio f212a600.mdio: prt 8 mmd 31: prs=0

which is what is expected from this PHY.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up