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-next>] [day] [month] [year] [list]
Message-ID: <20230907092407.647139-1-maxime.chevallier@bootlin.com>
Date:   Thu,  7 Sep 2023 11:23:58 +0200
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     davem@...emloft.net
Cc:     Maxime Chevallier <maxime.chevallier@...tlin.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Nicolò Veronese <nicveronese@...il.com>,
        thomas.petazzoni@...tlin.com,
        Christophe Leroy <christophe.leroy@...roup.eu>
Subject: [RFC PATCH net-next 0/7] net: phy: introduce phy numbering

Hello everyone,

This is the first RFC series introducing ethernet PHY numbering, in an
effort to better represent the link components and allow userspace to
configure these.

As of today, PHY devices are hidden behind the struct net_device from
userspace, but there exists commands such as PLCA configuration,
cable-testing, soon timestamping, that actually target the phy_device.

These commands rely on the ndev->phydev pointer to find the phy_device.

However, there exists use-cases where we have multiple PHY devices
between the MAC and the front-facing port. The most common case right
now is when a PHY acts as a media-converter, and is wired to an SFP
port :

[MAC] - [PHY] - [SFP][PHY]


Modules plugged in that port may contain a PHY too, and this is
where discrepencies start to happen.

In this case, ndev->phydev will point to the innermost PHY. Users
willing to use the SFP phy for cable-testing for example would get
unexpected results, as the middle PHY will be reached.

This is worsen by the fact that in a scenario like this :

[MAC] - [SFP][PHY]

the ndev->phydev pointer do point to the SFP PHY.

This is only the tip of the iceberg, such scenarios can happen with
other designs that include a mii mux, which isn't supported yet but
would require PHY enumeration to work.

This series therefore tries to add the ability to enumerate the PHYs
sitting behind a MAC, and assign them a unique number.

I've used the term of "phy namespace" to emphasize the fact that the PHY
numbering really is specific to an interface, each interface maintaining
its numbering scheme, starting from 0, and wrapping after all u32 values
have been exhausted.

The PHY namespace is for now contained within struct net_device, meaning
that PHYs that aren't related at all to any net_device wouldn't be
numbered as of right now. The only case I identified is when a PHY sits
between 2 DSA switches, but I don't know how relevant this is.

The phy_ns is its own struct, for now owned by net_device, but it could
be shared with struct dsa_port for example to make a MAC and the DSA CPU
port share the same phy ns.

This is early work, and it has its shortcomings :

 - I didn't include netlink notifications on PHY insersion/removal, but
   I think this could definitely be useful

 - the netlink API would need polishing, I struggle a bit with finding
   the correct netlink design pattern to return variale-length list of u32.

 - I would like to port netlink commands such as cable-test and plca to
   this new model, by adding an optional PHYINDEX field in the request.
   The idea would be that if the PHYINDEX is passed in the netlink
   request, we lookup the corresponding phy_device, and if not, we
   fallback to ndev->phydev.

 - Naming is hard, feel free to suggest any correction

Let me know what you think of this approach,

Best regards,

Maxime

Maxime Chevallier (7):
  net: phy: introduce phy numbering and phy namespaces
  net: sfp: pass the phy_device when disconnecting an sfp module's PHY
  net: phy: add helpers to handle sfp phy connect/disconnect
  net: ethtool: add a netlink command to list PHYs
  netlink: specs: add phy_list command
  net: ethtool: add a netlink command to get PHY information
  netlink: specs: add command to show individual phy information

 Documentation/netlink/specs/ethtool.yaml |  65 ++++++++++++
 drivers/net/phy/Makefile                 |   2 +-
 drivers/net/phy/at803x.c                 |   2 +
 drivers/net/phy/marvell-88x2222.c        |   2 +
 drivers/net/phy/marvell.c                |   2 +
 drivers/net/phy/marvell10g.c             |   2 +
 drivers/net/phy/phy_device.c             |  53 ++++++++++
 drivers/net/phy/phy_ns.c                 |  65 ++++++++++++
 drivers/net/phy/phylink.c                |   3 +-
 drivers/net/phy/sfp-bus.c                |   4 +-
 include/linux/netdevice.h                |   2 +
 include/linux/phy.h                      |   6 ++
 include/linux/phy_ns.h                   |  30 ++++++
 include/linux/sfp.h                      |   2 +-
 include/uapi/linux/ethtool.h             |   7 ++
 include/uapi/linux/ethtool_netlink.h     |  27 +++++
 net/core/dev.c                           |   3 +
 net/ethtool/Makefile                     |   2 +-
 net/ethtool/netlink.c                    |  20 ++++
 net/ethtool/netlink.h                    |   4 +
 net/ethtool/phy.c                        | 124 +++++++++++++++++++++++
 net/ethtool/phy_list.c                   |  99 ++++++++++++++++++
 22 files changed, 520 insertions(+), 6 deletions(-)
 create mode 100644 drivers/net/phy/phy_ns.c
 create mode 100644 include/linux/phy_ns.h
 create mode 100644 net/ethtool/phy.c
 create mode 100644 net/ethtool/phy_list.c

-- 
2.41.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ