[RFC net-next v2 0/6] ethtool: Generic loopback support
From: Björn Töpel
Date: Sun Mar 08 2026 - 08:40:40 EST
Hi!
Background
==========
This is the v2 RFC of the CMIS loopback series, reworked based on
feedback from v1 [1].
The main change is that loopback is no longer bolted onto the existing
module interface. Instead, it gets its own netlink commands
(LOOPBACK_GET/SET) with a generic component/name/direction model that
can represent loopback points across the entire data path -- MODULE,
PHY, MAC, and PCS. This series wires up MODULE/CMIS as the first user;
the other component types return -EOPNOTSUPP for now.
The Common Management Interface Specification (CMIS) defines four
diagnostic loopback types, characterized by location (Host or Media
Side) and signal direction:
- Host Side Input (Rx->Tx) -- near-end
- Host Side Output (Tx->Rx) -- far-end
- Media Side Input (Rx->Tx) -- near-end
- Media Side Output (Tx->Rx) -- far-end
Support is detected via Page 13h Byte 128, and loopback is controlled
via Page 13h Bytes 180-183 (one byte per type, one bit per lane).
The CMIS helpers work entirely over get/set_module_eeprom_by_page, so
any driver that already has EEPROM page access gets module loopback
without new ethtool_ops or driver changes.
Implementation
==============
Patch 1/6 ethtool: Add loopback netlink UAPI definitions
Adds the YAML spec and generated UAPI header for the new
LOOPBACK_GET/SET commands. Each loopback entry carries a component
type, optional id, name string, supported directions bitmask, and
current direction.
Patch 2/6 ethtool: Add loopback GET/SET netlink implementation
Implements GET/SET dispatch in a new loopback.c. GET collects
entries from each subsystem. SET switches on the component and
calls the right handler per entry. No components are wired yet.
Patch 3/6 ethtool: add CMIS loopback helpers for module loopback control
Adds cmis_loopback.c with the MODULE component handlers. GET reads
Page 13h and appends one entry per supported loopback point
("cmis-host" and/or "cmis-media"). SET resolves name to control
byte indices and enforces mutual exclusivity -- switching directions
first disables the active one in a separate EEPROM write, then
enables the new one.
Patch 4/6 selftests: drv-net: Add loopback driver test
Adds loopback_drv.py with generic tests that work on any device
with module loopback support: enable/disable, direction switching,
idempotent enable, and rejection while interface is up.
Patch 5/6 netdevsim: Add module EEPROM simulation via debugfs
Adds get/set_module_eeprom_by_page to netdevsim, backed by a
256-page x 128-byte array exposed via debugfs. This enables
testing the CMIS loopback path without hardware.
Patch 6/6 selftests: drv-net: Add CMIS loopback netdevsim test
Adds loopback_nsim.py with netdevsim-specific tests that seed the
EEPROM via debugfs: capability reporting, EEPROM byte verification,
and error paths for unsupported or missing CMIS support.
Limitations
===========
Only MODULE/CMIS is wired up. PHY, MAC, and PCS loopback are defined
in the UAPI but not yet implemented.
No per-lane support -- loopback is all-or-nothing (0xFF/0x00) across
lanes.
Extending to PHY/MAC/PCS
=========================
PHY loopback can walk phy_link_topology to enumerate PHYs by phyindex
and call phy_loopback() directly. MAC and PCS loopback can route
through phylink via new mac_set_loopback()/pcs_set_loopback()
callbacks. Drivers that don't use phylink could add new ethtool_ops.
The dispatch framework already handles all component types.
Open questions
==============
- Is this the right extensibility model? I'd appreciate input from
other NIC vendors on whether component/name/direction is flexible
enough for their loopback implementations. Also, from the PHY/port
folks (Maxime, Russell)!
- The MODULE id field is currently unused. For multi-module setups it
could serve as a port selector. It could also help detect module
swaps -- a hash of the CMIS vendor serial number (Page 00h, Bytes
168-183), vendor name, and part number would give userspace a
stable identifier to verify the module hasn't changed since
loopback was configured. Worth adding now, or defer until there's a
concrete user?
- Are patches 5-6 (netdevsim EEPROM simulation + netdevsim-specific
tests) worth carrying? They drive the CMIS Page 13h registers from
debugfs, which gives good coverage without hardware, but it's
another netdevsim surface to maintain. If the consensus is that the
generic driver tests (patch 4) are sufficient, I'm happy to drop
them.
Related work
============
[1] CMIS loopback v1
https://lore.kernel.org/netdev/20260219130050.2390226-1-bjorn@xxxxxxxxxx/
[2] New loopback modes
https://lore.kernel.org/netdev/20251024044849.1098222-1-hkelam@xxxxxxxxxxx/
[3] PHY loopback
https://lore.kernel.org/netdev/20240911212713.2178943-1-maxime.chevallier@xxxxxxxxxxx/
[4] bnxt_en: add .set_module_eeprom_by_page() support
https://lore.kernel.org/netdev/20250310183129.3154117-8-michael.chan@xxxxxxxxxxxx/
Björn Töpel (6):
ethtool: Add loopback netlink UAPI definitions
ethtool: Add loopback GET/SET netlink implementation
ethtool: add CMIS loopback helpers for module loopback control
selftests: drv-net: Add loopback driver test
netdevsim: Add module EEPROM simulation via debugfs
selftests: drv-net: Add CMIS loopback netdevsim test
Documentation/netlink/specs/ethtool.yaml | 115 ++++++
drivers/net/netdevsim/ethtool.c | 79 ++++
drivers/net/netdevsim/netdevsim.h | 11 +
include/linux/ethtool.h | 28 ++
.../uapi/linux/ethtool_netlink_generated.h | 52 +++
net/ethtool/Makefile | 2 +-
net/ethtool/cmis_loopback.c | 338 ++++++++++++++++++
net/ethtool/loopback.c | 248 +++++++++++++
net/ethtool/netlink.c | 20 ++
net/ethtool/netlink.h | 8 +
.../selftests/drivers/net/hw/loopback_drv.py | 227 ++++++++++++
.../selftests/drivers/net/hw/loopback_nsim.py | 249 +++++++++++++
12 files changed, 1376 insertions(+), 1 deletion(-)
create mode 100644 net/ethtool/cmis_loopback.c
create mode 100644 net/ethtool/loopback.c
create mode 100755 tools/testing/selftests/drivers/net/hw/loopback_drv.py
create mode 100755 tools/testing/selftests/drivers/net/hw/loopback_nsim.py
base-commit: 0bcac7b11262557c990da1ac564d45777eb6b005
--
2.53.0