On 2026-03-08 at 18:10:06, Björn Töpel (bjorn@kernel.org) wrote:

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)!

Hi Bjorn,

The component/name/direction model in v2 fits our hardware well.

I am working on loopback support for Marvell OcteonTX2.
The MAC (RPM block) supports a PCS-level loopback. In addition,
the on-chip SerDes (GSERM) is managed by embedded firmware and
supports three more loopback modes:
  NED (Near-End Digital) -- digital domain, before the analog front-end
  NEA (Near-End Analog) -- through the full analog front-end
  FED (Far-End Digital) -- line-side traffic looped back

Since the GSERM is not a phylib phy_device, both the MAC PCS
loopback and the SerDes loopbacks fall under the MAC component
in your model.

Mapped to the v2 model:
  component  name         supported    description
  MAC        mac          near-end     PCS-level loopback
  MAC        serdes-ned   near-end     digital only
  MAC        serdes-nea   near-end     analog
  MAC        serdes-fed   far-end      line-side

The SerDes NED and NEA both have the same (component, direction).
Both are (MAC, near-end) -- but exercise fundamentally different
hardware paths. The name field distinguishes them as per your model,

I can work on MAC + SerDes loopback driver support for CN10K and
post patches on top of your series once MAC component dispatch is
in place.

Thanks,
Naveen

 - 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@kernel.org/ (local)
[2] New loopback modes
  https://lore.kernel.org/netdev/20251024044849.1098222-1-hkelam@marvell.com/ (local)
[3] PHY loopback
  https://lore.kernel.org/netdev/20240911212713.2178943-1-maxime.chevallier@bootlin.com/ (local)
[4] bnxt_en: add .set_module_eeprom_by_page() support
  https://lore.kernel.org/netdev/20250310183129.3154117-8-michael.chan@broadcom.com/ (local)


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