Re: [RFC net-next v2 1/6] ethtool: Add loopback netlink UAPI definitions
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: 2026-03-09 14:16:56
Also in:
linux-rdma, lkml
Hi, On 08/03/2026 13:40, Björn Töpel wrote:
quoted hunk ↗ jump to hunk
Add the netlink YAML spec and auto-generated UAPI header for a unified loopback interface covering MAC, PCS, PHY, and pluggable module components. Each loopback point is described by a nested entry attribute containing: - component where in the path (MAC, PCS, PHY, MODULE) - name subsystem label, e.g. "cmis-host" or "cmis-media" - id optional instance selector (e.g. PHY id, port id) - supported bitmask of supported directions - direction NEAR_END, FAR_END, or 0 (disabled) Signed-off-by: Björn Töpel <bjorn@kernel.org> --- Documentation/netlink/specs/ethtool.yaml | 115 ++++++++++++++++++ .../uapi/linux/ethtool_netlink_generated.h | 52 ++++++++ 2 files changed, 167 insertions(+)diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 4707063af3b4..05ebad6ae4e0 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml@@ -211,6 +211,39 @@ definitions: name: discard value: 31 + - + name: loopback-component + type: enum + doc: | + Loopback component. Identifies where in the network path the + loopback is applied. + entries: + - + name: mac + doc: MAC loopback + - + name: pcs + doc: PCS loopback + - + name: phy + doc: PHY loopback + - + name: module + doc: Pluggable module (e.g. CMIS (Q)SFP) loopback
Should we also add "serdes" ?
quoted hunk ↗ jump to hunk
+ - + name: loopback-direction + type: flags + doc: | + Loopback direction flags. Used as a bitmask in supported, and as + a single value in direction. + entries: + - + name: near-end + doc: Near-end loopback; host-loop-host + - + name: far-end + doc: Far-end loopback; line-loop-line + attribute-sets: - name: header@@ -1903,6 +1936,60 @@ attribute-sets: name: link type: nest nested-attributes: mse-snapshot + - + name: loopback-entry + doc: Per-component loopback configuration entry. + attr-cnt-name: __ethtool-a-loopback-entry-cnt + attributes: + - + name: unspec + type: unused + value: 0 + - + name: component + type: u32 + enum: loopback-component + doc: Loopback component + - + name: id + type: u32 + doc: | + Optional component instance identifier. Required for PHY, + optional for MODULE, omitted for MAC and PCS.
it doesn't have to be required for PHY. The current idea is that if you don't pass any PHY index when issueing a PHY-targetting command, then it means you're targetting net_device->phydev, that is the PHY device attached to the netdev (if any). I think we can keep that behaviour, as systems with multiple PHYs are not very common.
+ - + name: name + type: string + doc: | + Subsystem-specific name for the loopback point within the + component.
We'll need to be careful about keeping this subsystem-specific and not driver-specific :)
+ - + name: supported + type: u32 + enum: loopback-direction + enum-as-flags: true + doc: Bitmask of supported loopback directions + - + name: direction + type: u32 + enum: loopback-direction + doc: Current loopback direction, 0 means disabled
no need for an u32 for 3 different values I think :) Maxime