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