public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: "Björn Töpel" <bjorn@kernel.org>
To: netdev@vger.kernel.org, Donald Hunter <donald.hunter@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Tariq Toukan <tariqt@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	Andrew Lunn <andrew+netdev@lunn.ch>
Cc: "Björn Töpel" <bjorn@kernel.org>,
	"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Michael Chan" <michael.chan@broadcom.com>,
	"Hariprasad Kelam" <hkelam@marvell.com>,
	"Ido Schimmel" <idosch@nvidia.com>,
	"Danielle Ratson" <danieller@nvidia.com>,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	"Russell King" <linux@armlinux.org.uk>
Subject: [RFC net-next v2 0/6] ethtool: Generic loopback support
Date: Sun,  8 Mar 2026 13:40:06 +0100	[thread overview]
Message-ID: <20260308124016.3134012-1-bjorn@kernel.org> (raw)

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@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


             reply	other threads:[~2026-03-08 12:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-08 12:40 Björn Töpel [this message]
2026-03-08 12:40 ` [RFC net-next v2 1/6] ethtool: Add loopback netlink UAPI definitions Björn Töpel
2026-03-09 14:16   ` Maxime Chevallier
2026-03-09 14:59     ` Björn Töpel
2026-03-09 16:45     ` Andrew Lunn
2026-03-10 10:23       ` Maxime Chevallier
2026-03-10 13:56         ` Andrew Lunn
2026-03-08 12:40 ` [RFC net-next v2 2/6] ethtool: Add loopback GET/SET netlink implementation Björn Töpel
2026-03-09  7:34   ` Maxime Chevallier
2026-03-09  8:21     ` Björn Töpel
2026-03-09 14:51       ` Björn Töpel
2026-03-09 16:14         ` Maxime Chevallier
2026-03-08 12:40 ` [RFC net-next v2 3/6] ethtool: add CMIS loopback helpers for module loopback control Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 4/6] selftests: drv-net: Add loopback driver test Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 5/6] netdevsim: Add module EEPROM simulation via debugfs Björn Töpel
2026-03-08 12:40 ` [RFC net-next v2 6/6] selftests: drv-net: Add CMIS loopback netdevsim test Björn Töpel
2026-03-09 13:49 ` [RFC net-next v2 0/6] ethtool: Generic loopback support Naveen Mamindlapalli
2026-03-09 14:55   ` Björn Töpel
2026-03-10  7:35     ` Naveen Mamindlapalli
2026-03-10 14:00       ` Andrew Lunn
2026-03-11  5:59         ` Naveen Mamindlapalli
2026-03-11 12:32           ` Andrew Lunn
2026-03-11 16:52             ` Russell King (Oracle)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260308124016.3134012-1-bjorn@kernel.org \
    --to=bjorn@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=danieller@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=hkelam@marvell.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox