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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 27 May 2020 11:33:18 +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: [PATCH RFC v2 0/9] Clause 45 PHY probing cleanups

Hi,

This is version 2 of my proposal to expand our Clause 45 PHY probing.
This series does not change the functionality beyond probing further
MMDs.

The first four patches clean up get_phy_device() and called functions,
updating the kernel doc, adding information about the various error
return values.

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.

I haven't tested the new changes in version 2 yet beyond compile
testing.

Given the proximity of the merge window, this *isn't* code I'd like to
see merged into net-next - it's way too risky at this point.  So, we
have time to consider our options.

If we want to start scanning for Clause 45 PHYs like we do for Clause
22 PHYs, we definitely need to have indications from the MDIO drivers
that they support Clause 45 accesses, or all MDIO drivers audited to
add the necessary rejection; many of them do not explicitly reject a
request to perform Clause 45 accesses, and will just try and fit the
unmasked register address into their registers, potentially setting
invalid bits when writing their registers.

Changes from v2:
- Further cleanups to get_phy_c45_ids(), get_phy_c22_id() and
  get_phy_device(), with kerneldoc updates to better describe what
  is going on, and what the error return codes signify.

- Only read status register 2 to detect device presence for the
  two vendor MMDs which we know are a potential problem on 88x3310
  PHYs.  We can expand to also check MMDs 1 through 6 if necessary,
  but that would be a behaviour change beyond what this series is
  trying to do.

Unaddressed issues:
- Reading zero from PHY ID registers - OUI 00:00:00 is allocated to
  Xerox Corporation, but it's unlikely that there is a PHY out there
  validly using this OUI. However, I believe that we do know that
  there are PHYs with zero PHY ID registers (in DSA switches, Andrew?)

- mmds_present - I have a patch on top of this which clears the vendor
  MMDs if the devices-present field in status register 2 indicates
  not-present.  We may wish to do this for MMDs 1 through 6 as well
  which have status register 2, but that comes with some risk.

Discussion points:
- drivers/net/phy is becoming quite large, do we want to split it
  into separate subdirectories for PHY drivers, MDIO drivers, and
  core code?
- I have a patch that splits the "genphy" clause 22 code like I did
  with the clause 45 code, which will need refreshing before I
  submit - do my fellow phylib maintainers think that's a good move?

 drivers/net/phy/phy-c45.c    |   4 +-
 drivers/net/phy/phy_device.c | 159 ++++++++++++++++++++++++++++---------------
 drivers/net/phy/phylink.c    |   8 +--
 include/linux/phy.h          |   8 ++-
 4 files changed, 117 insertions(+), 62 deletions(-)

-- 
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

Powered by blists - more mailing lists