Re: [RFC net-next v2 0/6] ethtool: Generic loopback support

[Naveen Mamindlapalli <naveenm@marvell.com>]

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