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


             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