[PATCH net-next v2 00/12] net: phy_port: SFP modules representation and phy_port listing

Maxime Chevallier posted 12 patches 1 week, 2 days ago
There is a newer version of this series
Documentation/netlink/specs/ethtool.yaml      |  50 +++
Documentation/networking/ethtool-netlink.rst  |  35 ++
MAINTAINERS                                   |   1 +
drivers/net/phy/phy-caps.h                    |   2 +
drivers/net/phy/phy_caps.c                    |  26 ++
drivers/net/phy/phy_device.c                  | 106 ++++-
drivers/net/phy/phy_link_topology.c           |  82 +++-
drivers/net/phy/phy_port.c                    |   9 +-
drivers/net/phy/phylink.c                     | 124 ++++++
drivers/net/phy/sfp-bus.c                     |  20 +
drivers/net/phy/sfp.c                         |  14 +
drivers/net/phy/sfp.h                         |   2 +
include/linux/phy.h                           |   4 +
include/linux/phy_link_topology.h             |  35 ++
include/linux/phy_port.h                      |   5 +
include/linux/sfp.h                           |   5 +
.../uapi/linux/ethtool_netlink_generated.h    |  19 +
net/ethtool/Makefile                          |   2 +-
net/ethtool/netlink.c                         |  26 ++
net/ethtool/netlink.h                         |   8 +
net/ethtool/port.c                            | 376 ++++++++++++++++++
21 files changed, 925 insertions(+), 26 deletions(-)
create mode 100644 net/ethtool/port.c
[PATCH net-next v2 00/12] net: phy_port: SFP modules representation and phy_port listing
Posted by Maxime Chevallier 1 week, 2 days ago
Hello everyone,

Here's V2 of the second phy_port series, this time bringing support for
more phy_port use especially for SFP, as well as the beggining of a
ethnl uAPI. That's a quick repost, but with the build issues and AI
review, I think it's worth getting this version out there for review.

It builds on the recent addition of phy_port representation to enable
listing the front-facing ports of an interface. For now, we don't control
these ports, we merely list their presence and their capabilities.

As the most common use-case of multi-port interfaces is combo-ports that
provide both RJ45 and SFP connectors on a single MAC, there's a lot of
SFP stuff in this series.

This series is in 2 main parts. The first one aims at representing the
SFP cages and modules using phy_port, as combo-ports with RJ45 + SFP are
by far the most common cases for multi-connector setups.

The second part is the netlink interface to list those ports, now that
most use-cases are covered.

Let's see what we can do with some examples of the new ethtool API :

- Get MII interfaces supported by an empty SFP cage :

# ethtool --show-ports eth3

Port for eth3:
	Port id: 1
	Occupied: no
	Supported MII interfaces : sgmii, 1000base-x, 2500base-x
	Port type: sfp


- Get Combo-ports supported modes, on each port :

# ethtool --show-ports eth0

Port for eth0:
	Port id: 1
	Occupied: no
	Supported link modes:  10baseT/Half 10baseT/Full
	                       100baseT/Half 100baseT/Full
	                       1000baseT/Half 1000baseT/Full
	                       10000baseT/Full
	                       2500baseT/Full
	                       5000baseT/Full
	Port type: mdi

Port for eth0:
	Port id: 2
	Occupied: no
	Supported MII interfaces : 10gbase-r
	Port type: sfp
	

- Get Achievable linkmodes on a SFP module (combo port with a DAC in the
SFP cage)

# ethtool --show-ports eth1

Port for eth1:
	Port id: 1
	Occupied: no
	Supported link modes:  10baseT/Half 10baseT/Full
	                       100baseT/Half 100baseT/Full
	                       1000baseT/Half 1000baseT/Full
	                       10000baseT/Full
	                       2500baseT/Full
	                       5000baseT/Full
	Port type: mdi

Port for eth1:
	Port id: 2
	Occupied: yes
	Supported MII interfaces : 10gbase-r
	Port type: sfp

Port for eth1:
	Port id: 3
	Occupied: no
	Supported link modes:  10000baseCR/Full
	Port type: mdi

Note that here, we have 3 ports :
 - The Copper port
 - The SFP Cage itself, marked as 'occupied'
 - The SFP module

This series builds on top of phy_port and phy_link_topology to allow
tracking the ports of an interface. We maintain a list of supported
linkmodes/interfaces on each port, which allows for fine-grained
reporting of each port's capability.

What this series doesn't do :
 - We don't support selecting which port is active. This is the next step.
 - We only support PHY-driven combo ports. The end-goal of this whole
   journey that started with phy_link_topology is to get support for MII
   muxes, such as the one we have on the Turris Omnia. This will eventually
   be upstreamed as well.

If you want to play around with it, here's [1] the patched ethtool that I've
been using to produce the outputs above.

Thanks !

Maxime

[1] : https://github.com/minimaxwell/ethtool/tree/mc/ethtool_port

Changelog :

Changes in V2:
 - Fix the cleanup path of phy_link_topo_add_phy, as per AI review
 - Fix the cleanup path of phy_sfp_probe, as per AI review
 - Fix the call-site of the disconnect_nophy sfp bus ops, per AI review
 - Fix the netdev-less case uin phylink, per AI review
 - Fix the prototype of phy_link_topo_get_port for the stubs
 - Dropped patch 11. It ended-up breaking 'allnoconfig', so instead we
   built a phy_interface_names array in net/ethtool/netlink.c
 - Fix an ethool-netlink spec discrepancy with the type of an attribute
 - Fix the size computation in the netlink port API
 - Fix the cleanup path in the netlink port API

Maxime Chevallier (12):
  net: phy: phy_port: Correctly recompute the port's linkmodes
  net: phy: phy_link_topology: Add a helper for opportunistic alloc
  net: phy: phy_link_topology: Track ports in phy_link_topology
  net: phylink: Register a phy_port for MAC-driven SFP busses
  net: phy: Create SFP phy_port before registering usptream
  net: sfp: Add a sfp-bus ops when connecting a module without PHY
  net: phy: Represent PHY-less SFP modules with phy_port
  net: phylink: Represent PHY-less SFP modules with phy_port
  net: phy: phy_port: Store information about a MII port's occupancy
  net: phy: phy_link_topology: Add a helper to retrieve ports
  netlink: specs: Add ethernet port listing with ethtool
  net: ethtool: Introduce ethtool command to list ports

 Documentation/netlink/specs/ethtool.yaml      |  50 +++
 Documentation/networking/ethtool-netlink.rst  |  35 ++
 MAINTAINERS                                   |   1 +
 drivers/net/phy/phy-caps.h                    |   2 +
 drivers/net/phy/phy_caps.c                    |  26 ++
 drivers/net/phy/phy_device.c                  | 106 ++++-
 drivers/net/phy/phy_link_topology.c           |  82 +++-
 drivers/net/phy/phy_port.c                    |   9 +-
 drivers/net/phy/phylink.c                     | 124 ++++++
 drivers/net/phy/sfp-bus.c                     |  20 +
 drivers/net/phy/sfp.c                         |  14 +
 drivers/net/phy/sfp.h                         |   2 +
 include/linux/phy.h                           |   4 +
 include/linux/phy_link_topology.h             |  35 ++
 include/linux/phy_port.h                      |   5 +
 include/linux/sfp.h                           |   5 +
 .../uapi/linux/ethtool_netlink_generated.h    |  19 +
 net/ethtool/Makefile                          |   2 +-
 net/ethtool/netlink.c                         |  26 ++
 net/ethtool/netlink.h                         |   8 +
 net/ethtool/port.c                            | 376 ++++++++++++++++++
 21 files changed, 925 insertions(+), 26 deletions(-)
 create mode 100644 net/ethtool/port.c

-- 
2.49.0
Re: [PATCH net-next v2 00/12] net: phy_port: SFP modules representation and phy_port listing
Posted by Jakub Kicinski 1 week, 1 day ago
On Wed, 28 Jan 2026 21:45:13 +0100 Maxime Chevallier wrote:
> Here's V2 of the second phy_port series, this time bringing support for
> more phy_port use especially for SFP, as well as the beggining of a
> ethnl uAPI. That's a quick repost, but with the build issues and AI
> review, I think it's worth getting this version out there for review.
> 
> It builds on the recent addition of phy_port representation to enable
> listing the front-facing ports of an interface. For now, we don't control
> these ports, we merely list their presence and their capabilities.
> 
> As the most common use-case of multi-port interfaces is combo-ports that
> provide both RJ45 and SFP connectors on a single MAC, there's a lot of
> SFP stuff in this series.
> 
> This series is in 2 main parts. The first one aims at representing the
> SFP cages and modules using phy_port, as combo-ports with RJ45 + SFP are
> by far the most common cases for multi-connector setups.
> 
> The second part is the netlink interface to list those ports, now that
> most use-cases are covered.

I'll send out the AI code review. The one on patch 9 looks plausible,
not sure about the rest. LMK if none of them in fact make sense.
Re: [PATCH net-next v2 00/12] net: phy_port: SFP modules representation and phy_port listing
Posted by Maxime Chevallier 1 week, 1 day ago
Hi Jakub,

On 30/01/2026 04:59, Jakub Kicinski wrote:
> On Wed, 28 Jan 2026 21:45:13 +0100 Maxime Chevallier wrote:
>> Here's V2 of the second phy_port series, this time bringing support for
>> more phy_port use especially for SFP, as well as the beggining of a
>> ethnl uAPI. That's a quick repost, but with the build issues and AI
>> review, I think it's worth getting this version out there for review.
>>
>> It builds on the recent addition of phy_port representation to enable
>> listing the front-facing ports of an interface. For now, we don't control
>> these ports, we merely list their presence and their capabilities.
>>
>> As the most common use-case of multi-port interfaces is combo-ports that
>> provide both RJ45 and SFP connectors on a single MAC, there's a lot of
>> SFP stuff in this series.
>>
>> This series is in 2 main parts. The first one aims at representing the
>> SFP cages and modules using phy_port, as combo-ports with RJ45 + SFP are
>> by far the most common cases for multi-connector setups.
>>
>> The second part is the netlink interface to list those ports, now that
>> most use-cases are covered.
> 
> I'll send out the AI code review. The one on patch 9 looks plausible,
> not sure about the rest. LMK if none of them in fact make sense.

Thanks, I'll look carefully into that :)

Maxime