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
Subject: [RFC net-next 0/4] ethtool: CMIS module diagnostic loopback support
Date: Thu, 19 Feb 2026 14:00:41 +0100 [thread overview]
Message-ID: <20260219130050.2390226-1-bjorn@kernel.org> (raw)
Hi!
Background
==========
This series adds initial ethtool support for CMIS loopback.
The Common Management Interface Specification (CMIS) is an
industry-standard used by host devices (like switches and routers) to
talk to high-speed optical transceivers (like QSFP-DD, OSFP, and
QSFP112).
Ethtool already supports mechanism updating the transceiver firmware
via CMIS, and this series builds on top of this work.
In CMIS, four different types of loopback are defined by the
specification, characterized by the location of the loopback on Host
(electrical) or Media (optical) Side and the direction of the signal
being looped-back:
* Media Side Output (Tx->Rx) Loopback
* Media Side Input (Rx->Tx) Loopback
* Host Side Output (Tx->Rx) Loopback
* Host Side Input (Rx->Tx) Loopback
To detect and enable loopback in a CMIS transceiver, the following
registers are used:
* Detect Support: Read Page 13h, Byte 128 indicate if the hardware
supports host-side or media-side loopback.
* Enable Loopback: Write to Page 13h, Bytes 180–184. Each bit in these
registers typically corresponds to a specific lane (0–7). Setting a
bit to 1 requests loopback for that lane.
Implementation
==============
Patch 1/4 ethtool: module: Define CMIS loopback YAML spec and UAPI
Adds the netlink YAML specification and UAPI for module loopback.
Defines a flags enum with the four CMIS 5.2 diagnostic loopback
types (media-side output/input, host-side output/input) and two new
module attributes: loopback-capabilities (supported modes) and
loopback-enabled (active modes). Regenerates the UAPI header.
Patch 2/4 ethtool: module: Add CMIS loopback GET/SET support
Implements the core loopback GET/SET logic for CMIS modules. Reads
capabilities from Page 01h Byte 142 and controls loopback via Page
13h Bytes 180-183, using the existing get/set_module_eeprom_by_page
driver ops. No new ethtool_ops callbacks are introduced.
Patch 3/4 ethtool: module: refactor fw flash init to reuse CMIS
helpers Refactors module_flash_fw_work_init() to reuse the
module_is_cmis() helper and ethtool_cmis_page_init() introduced in
patch 2, removing open-coded CMIS type checking and manual EEPROM
page setup from the firmware flash path.
Patch 4/4 net/mlx5e: Implement set_module_eeprom_by_page ethtool
callback Adds EEPROM write support to mlx5 by implementing
set_module_eeprom_by_page, mirroring the existing read path via the
MCIA register. This enables the loopback SET path which requires
both get and set callbacks.
Limitations
===========
Only four modes are supported host/media-side near-/far-end. No
per-lane support.
I'm working on kselftest; It's not part of the RFC.
RFC
===
I'm not familiar with the mlx5 internals, and need guidance if my
set_module_eeprom_by_page() hack is the right way forward. I've tested
this on a transceiver in a CX7 NIC, and it did switch on the loopback
mode, so it's somewhat working.
I'd like input from other NIC vendors, if the
{set,get}_module_eeprom_by_page() is the right interface/ops from a
driver POV.
Extensibility; Is this the right interface?
Related work
============
* New loopback modes [1].
* PHY loopback [2]
* bnxt_en: add .set_module_eeprom_by_page() support [3]
* ethtool: qsfp transceiver reset, interrupt and presence pin control
[4]
[1] https://lore.kernel.org/netdev/20251024044849.1098222-1-hkelam@marvell.com/
[2] https://lore.kernel.org/netdev/20240911212713.2178943-1-maxime.chevallier@bootlin.com/
[3] https://lore.kernel.org/netdev/20250310183129.3154117-8-michael.chan@broadcom.com/
[4] https://lore.kernel.org/netdev/20250513224017.202236-1-mpazdan@arista.com/
Björn Töpel (4):
ethtool: module: Define CMIS loopback YAML spec and UAPI
ethtool: module: Add CMIS loopback GET/SET support
ethtool: module: refactor fw flash init to reuse CMIS helpers
net/mlx5e: Implement set_module_eeprom_by_page ethtool callback
Documentation/netlink/specs/ethtool.yaml | 27 ++
.../ethernet/mellanox/mlx5/core/en_ethtool.c | 52 ++-
.../ethernet/mellanox/mlx5/core/mlx5_core.h | 6 +-
.../net/ethernet/mellanox/mlx5/core/port.c | 34 +-
include/linux/ethtool.h | 12 +
.../uapi/linux/ethtool_netlink_generated.h | 22 ++
net/ethtool/module.c | 302 ++++++++++++++++--
net/ethtool/netlink.h | 2 +-
8 files changed, 397 insertions(+), 60 deletions(-)
base-commit: 37a93dd5c49b5fda807fd204edf2547c3493319c
--
2.53.0
next reply other threads:[~2026-02-19 13:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 13:00 Björn Töpel [this message]
2026-02-19 13:00 ` [RFC net-next 1/4] ethtool: module: Define CMIS loopback YAML spec and UAPI Björn Töpel
2026-02-19 13:00 ` [RFC net-next 2/4] ethtool: module: Add CMIS loopback GET/SET support Björn Töpel
2026-02-19 15:59 ` Andrew Lunn
2026-02-19 13:00 ` [RFC net-next 3/4] ethtool: module: refactor fw flash init to reuse CMIS helpers Björn Töpel
2026-02-19 13:00 ` [RFC net-next 4/4] net/mlx5e: Implement set_module_eeprom_by_page ethtool callback Björn Töpel
2026-02-19 13:16 ` [RFC net-next 0/4] ethtool: CMIS module diagnostic loopback support Björn Töpel
2026-02-19 15:51 ` Andrew Lunn
2026-02-20 0:05 ` Jakub Kicinski
2026-02-20 14:18 ` Andrew Lunn
2026-02-20 21:12 ` Jakub Kicinski
2026-02-22 19:58 ` Björn Töpel
2026-02-23 14:30 ` Andrew Lunn
2026-02-23 14:41 ` Björn Töpel
2026-02-23 23:04 ` Jakub Kicinski
2026-02-24 10:28 ` Björn Töpel
2026-02-25 4:04 ` Andrew Lunn
2026-02-25 8:39 ` Björn Töpel
2026-02-25 13:14 ` Andrew Lunn
2026-03-02 9:00 ` Maxime Chevallier
2026-03-04 15:52 ` Björn Töpel
2026-03-04 16:09 ` Maxime Chevallier
2026-02-25 10:22 ` Maxime Chevallier
2026-02-25 11:20 ` Björn Töpel
2026-02-20 8:11 ` Björn Töpel
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=20260219130050.2390226-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=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