mbox series

[ethtool-next,0/3] ethtool: Introduce PHY listing and targetting

Message ID 20240103142950.235888-1-maxime.chevallier@bootlin.com (mailing list archive)
Headers show
Series ethtool: Introduce PHY listing and targetting | expand

Message

Maxime Chevallier Jan. 3, 2024, 2:29 p.m. UTC
Hello everyone,

This series implements the ethtool part of the multi-PHY support that was
recently merged into net-next :

https://lore.kernel.org/netdev/20231221180047.1924733-1-maxime.chevallier@bootlin.com/

The series starts with a UAPI header copy (I don't really know if it's up
to me to do this, let me know if I should drop it).

The second patch adds the possibility of passing a PHY index for the
PSE-PD, PLCA and Cable-testing commands, in such a manner :

ethtool --phy 2 --cable-test eth0

The new '--phy' parameter is optional for PHY-targetting commands, if it's
not there, we use the old behaviour of relying on the PHY directly attached
to the netdevice to perform the command.

The parameter comes before the actual command to make it generic, after all
the PHY index is passed in the request header.

The Third patch adds a new ethtool option to display the PHYs present on
an interface, along with enough information to reconstruct the link topology.
As it relies on the netlink DUMP messages, some internal helpers were added
in ethtool to send DUMP requests that includes a devname in the header, to
perform a filtered dump. Here are a few examples of what you can expect on
an interface that has 2 PHYs (the 88x3310 PHY exposes an SFP bus, on which
a module that also contains a PHY is plugged)

# ethtool --show-phys eth0

PHY for eth0:
PHY index: 1
Driver name: mv88x3310
PHY device name: f212a600.mdio-mii:00
Downstream SFP bus name: sfp-eth0
PHY id: 0
Upstream type: MAC

PHY for eth0:
PHY index: 2
Driver name: Marvell 88E1111
PHY device name: i2c:sfp-eth0:16
PHY id: 21040322
Upstream type: PHY
Upstream PHY index: 1
Upstream SFP name: sfp-eth0

Here's another example using the wildcard devname, that lists all PHYs on
all interfaces :

# ethtool --show-phys *

PHY for eth0:
PHY index: 1
Driver name: mv88x3310
PHY device name: f212a600.mdio-mii:00
Downstream SFP bus name: sfp-eth0
PHY id: 0
Upstream type: MAC

PHY for eth0:
PHY index: 2
Driver name: Marvell 88E1111
PHY device name: i2c:sfp-eth0:16
PHY id: 21040322
Upstream type: PHY
Upstream PHY index: 1
Upstream SFP name: sfp-eth0

PHY for eth2:
PHY index: 1
Driver name: Marvell 88E1510
PHY device name: f212a200.mdio-mii:00
PHY id: 21040593
Upstream type: MAC

Thanks,

Maxime

Maxime Chevallier (3):
  update UAPI header copies
  ethtool: Allow passing a PHY index for phy-targetting commands
  ethtool: Introduce a command to list PHYs

 Makefile.am                  |   1 +
 ethtool.c                    |  30 +-
 internal.h                   |   1 +
 netlink/cable_test.c         |   4 +-
 netlink/extapi.h             |   1 +
 netlink/msgbuff.c            |  52 +++-
 netlink/msgbuff.h            |   3 +
 netlink/nlsock.c             |  25 ++
 netlink/nlsock.h             |   2 +
 netlink/phy.c                | 139 +++++++++
 netlink/plca.c               |   4 +-
 netlink/pse-pd.c             |   4 +-
 uapi/linux/ethtool.h         |  56 +++-
 uapi/linux/ethtool_netlink.h |  31 ++
 uapi/linux/if_link.h         | 529 +++++++++++++++++++++++++++++++++++
 uapi/linux/stddef.h          |   2 +-
 16 files changed, 851 insertions(+), 33 deletions(-)
 create mode 100644 netlink/phy.c

Comments

Michal Kubecek April 17, 2024, 8:44 p.m. UTC | #1
On Wed, Jan 03, 2024 at 03:29:45PM +0100, Maxime Chevallier wrote:
> Hello everyone,
> 
> This series implements the ethtool part of the multi-PHY support that was
> recently merged into net-next :
> 
> https://lore.kernel.org/netdev/20231221180047.1924733-1-maxime.chevallier@bootlin.com/
> 
[...]
> Maxime Chevallier (3):
>   update UAPI header copies
>   ethtool: Allow passing a PHY index for phy-targetting commands
>   ethtool: Introduce a command to list PHYs

As far as I can see, part of the kernel side support has been reverted
and is going to be reworked but that hasn't happened yet. Unless
I missed something, patch 2/3 can be already applied. Should I pick it
now for the 6.9 cycle or would you prefer to resubmit the whole series
once the kernel side code is complete?

Michal