RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Ayoub Kaanich]

Hi,

Raising a gap in the ethtool netlink module-EEPROM API and asking whether a symmetric write-side command would be considered upstream.

Background:
ETHTOOL_MSG_MODULE_EEPROM_GET (net/ethtool/eeprom.c) already accepts an explicit i2c_address attribute alongside page/bank/offset/length, not just the SFF-8472 0x50/0x51 pair.

For SFP cages backed by phy/sfp.c + phylink with a real i2c_adapter, this lets userspace read arbitrary vendor-specific I2C addresses on the module through a standard interface, which is useful well beyond SFF-8472.

There is no equivalent SET. ethtool --set-module-eeprom (both netlink and the legacy ioctl fallback)

Concrete use case:

We (Technica Engineering) manufacture automotive SFP/SFP+ modules for 100/1000BASE-T1 and multi-gig automotive Ethernet (TE-1441, PT-1445). Alongside the standard SFF-8472 EEPROM at 0x50, these modules expose an I2C-to-MDIO gateway at I2C address 0x40 (0x80/0x81 as 8-bit read/write):

Writes to that address are relayed by the module's own logic as MDIO Clause 22/45 transactions to the embedded automotive PHY, giving access to link speed, master/slave mode, and other PHY configuration without needing register-level documentation of the PHY itself.


This isn't a one-off design choice -- at least two other automotive SFP vendor use similar patterns
    * Intrepid Control Systems: https://guide.intrepidcs.com/docs/1000BASE-T1-SFP/A-Tour-of-1G-SFP-Hardware.html#i2c-communication
    * FL3X: https://flex-product.com/assets/produkte/fl3x_sfp_1000base-t1/instruction_for_use_fl3x_sfp_1000base-t1.pdf

This suggests this is a de facto convention among automotive Ethernet SFP vendors rather than something specific to us. The framing on top of the raw MDIO transaction is vendor-specific, but the kernel doesn't need to understand that -- we just need raw byte-level write access to a non-default I2C address on the module, symmetric to what MODULE_EEPROM_GET already provides for reads.

Today there's no standard kernel path for this write from userspace on phylink/sfp.c-backed ports. Where the SFP's I2C bus happens to be a directly exposed i2c_adapter (board-dependent), i2c-tools works, but that's not guaranteed, and on the phylink-managed path the bus is typically owned/locked by the sfp driver rather than freely available via /dev/i2c-N.

Ask:
Would a SET_MODULE_EEPROM_BY_PAGE netlink command, mirroring the existing GET (same page/bank/offset/length/i2c_address attributes, same 128-byte half-page constraint), be something you'd consider taking?
Wanted to check direction first given Andrew's existing work on the generic SFP GET path before spending time on an RFC series that goes against the intended design.

Thanks.


 
Ayoub Kaanich
Principal Software Engineer
Engineering Department
 
Technica Engineering GmbH
Leopoldstr. 236
D - 80807 München/Munich
 
Telefon:
+49 89 200 07 24-XX

Fax: +49 89 200 07 24-30
E-Mail:
ayoub.kaanich@technica-engineering.de
Website: www.technica-engineering.de

________________________________________
Technica Engineering GmbH is based in Munich | Managing Directors: Pankaj Sathe, Anup Sable, Thomas Königseder | Register Court: Munich Local Court, HRB 172
 759 | Ust-ID.: DE-260220745
 
The information contained in this e-mail is intended solely for the use of the individual or entity to whom it is addressed, and others authorized to receive
 it. It may contain confidential or privileged information. If you are not the intended recipient you are notified that any disclosure, copying, distribution or taking any action in reliance on the content of this email is strictly prohibited and may be unlawful.
 If you have received this communication in error, please notify us immediately by responding to this email and then delete it. Technica Engineering GmbH is neither liable for the proper and complete transmission of the information obtained or for any delay
 in this receipt.
 
 

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Andrew Lunn]

> There is no equivalent SET. ethtool --set-module-eeprom (both
> netlink and the legacy ioctl fallback)

In general, we are trying to block user space drivers, by only
allowing read.

> Concrete use case:
> 
> We (Technica Engineering) manufacture automotive SFP/SFP+ modules for 100/1000BASE-T1 and multi-gig automotive Ethernet (TE-1441, PT-1445). Alongside the standard SFF-8472 EEPROM at 0x50, these modules expose an I2C-to-MDIO gateway at I2C address 0x40 (0x80/0x81 as 8-bit read/write):
> 
> Writes to that address are relayed by the module's own logic as MDIO Clause 22/45 transactions to the embedded automotive PHY, giving access to link speed, master/slave mode, and other PHY configuration without needing register-level documentation of the PHY itself.

What protocol does it use? Have you seen drivers/net/mdio/mdio-i2c.c.
That currently implements two different C22 or C45 over I2C.

You should add your protocol here, and then Linux can just drive the
PHY, like it does for any other PHY.

	Andrew

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Ayoub Kaanich]

Hi,

> In general, we are trying to block user space drivers, by only allowing read.

So in principle, a write from a third party driver (not the NIC own driver) is allowed?


> What protocol does it use? Have you seen drivers/net/mdio/mdio-i2c.c.
> That currently implements two different C22 or C45 over I2C.

Our current addressing schema does not fit C22, C45 or ROLLBALL.

Even if we were to change it (not sure of possible) or add another addressing schema to mdio-i2c.c, there is still one fundamental issue:

Our issue is that the NIC drivers (especially the netlink based drivers), have no standard way to expose the I2C bus of the SFP module to other drivers.
phylink based drivers don't have this issue.

The current hierarchy is

net_device => sfp_bus (missing in many drivers) => sfp (internal) => i2c_adapter

For example: ice driver does not create an i2c_adapter or sfp_bus, even though many of the NICs using that driver have SFP28 or QSFP28 pluggable cages.

This means no i2c_adapter and no sfp_bus are available to build the mii_bus on when using ice driver.

Best Regards.


Ayoub Kaanich
Principal Software Engineer
Engineering Department







________________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Tuesday, July 14, 2026 09:55 PM
To: Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>
Cc: Russell King <linux@armlinux.org.uk>; netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



> There is no equivalent SET. ethtool --set-module-eeprom (both

> netlink and the legacy ioctl fallback)



In general, we are trying to block user space drivers, by only

allowing read.



> Concrete use case:

>

> We (Technica Engineering) manufacture automotive SFP/SFP+ modules for 100/1000BASE-T1 and multi-gig automotive Ethernet (TE-1441, PT-1445). Alongside the standard SFF-8472 EEPROM at 0x50, these modules expose an I2C-to-MDIO gateway at I2C address 0x40 (0x80/0x81 as 8-bit read/write):

>

> Writes to that address are relayed by the module's own logic as MDIO Clause 22/45 transactions to the embedded automotive PHY, giving access to link speed, master/slave mode, and other PHY configuration without needing register-level documentation of the PHY itself.



What protocol does it use? Have you seen drivers/net/mdio/mdio-i2c.c.

That currently implements two different C22 or C45 over I2C.



You should add your protocol here, and then Linux can just drive the

PHY, like it does for any other PHY.



        Andrew

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Andrew Lunn]

On Wed, Jul 15, 2026 at 08:09:56AM +0000, Ayoub Kaanich wrote:
> Hi,
> 
> > In general, we are trying to block user space drivers, by only allowing read.
> 
> So in principle, a write from a third party driver (not the NIC own driver) is allowed?

We would expect the code to fit in with the current architecture. So
mdio-i2c would provide a Linux MDIO bus. You "third party driver"
would be a PHY driver. 

> Our issue is that the NIC drivers (especially the netlink based
> drivers), have no standard way to expose the I2C bus of the SFP
> module to other drivers.  phylink based drivers don't have this
> issue.
> 
> The current hierarchy is
> 
> net_device => sfp_bus (missing in many drivers) => sfp (internal) => i2c_adapter
> 
> For example: ice driver does not create an i2c_adapter or sfp_bus, even though many of the NICs using that driver have SFP28 or QSFP28 pluggable cages.

So Linux Ethernet drivers fall into two classes. Those where Linux
driver the hardware, making use of phylink/phylib, and those where
firmware drive the hardware, eg ice, and pretty much all intel
hardware, and most NICs which support > 10G.

For NICs using firmware, you will need to talk to each vendor, and ask
them to extend their firmware to support your SFP.

For NICs where Linux drives the hardware, which is pretty much all
NICs used in embedded systems, with a bandwidth up to 1G, and some
10G, provide an implementation of the protocol in mdio-i2c, and a PHY
driver, and it should all just work.

Looking at the other devices you pointed to, one used a Marvell
88q2xxx, for which a Linux driver already exists. And there was
sufficient hints in the document to make writing the I2C protocol
possible. The other device explicitly described the I2C protocol, but
did not mention what PHY was used, so might need a PHY driver. But
there are not too many T1 PHYs, so it might have a driver already.

    Andrew

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Ayoub Kaanich]

Hi,


> We would expect the code to fit in with the current architecture. So
> mdio-i2c would provide a Linux MDIO bus. You "third party driver"
> would be a PHY driver.

Sounds fair.


> For NICs using firmware, you will need to talk to each vendor, and ask
> them to extend their firmware to support your SFP.

That does not sound reasonable, given that the only interface needed to the SFP/PHY is the I2C bus which the kernel could access directly (to read EEPROM for example)

The only change needed as far as I see, is to have the driver expose the internal SFP I2C bus (basically only the I2C read/write functions)

for the case of the ice driver, the functions ice_aq_read_i2c and ice_aq_write_i2c already exists, so creating the i2c_adapter from it should be trivial.


If the NIC does not expose the I2C bus at all, then it would be understandable if a NIC firmware is the only viable path, but it's not the case here.


Best Regards.


Ayoub Kaanich
Principal Software Engineer
Engineering Department


________________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, July 15, 2026 03:05 PM
To: Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>
Cc: Russell King <linux@armlinux.org.uk>; netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



On Wed, Jul 15, 2026 at 08:09:56AM +0000, Ayoub Kaanich wrote:

> Hi,

>

> > In general, we are trying to block user space drivers, by only allowing read.

>

> So in principle, a write from a third party driver (not the NIC own driver) is allowed?



We would expect the code to fit in with the current architecture. So

mdio-i2c would provide a Linux MDIO bus. You "third party driver"

would be a PHY driver.



> Our issue is that the NIC drivers (especially the netlink based

> drivers), have no standard way to expose the I2C bus of the SFP

> module to other drivers.  phylink based drivers don't have this

> issue.

>

> The current hierarchy is

>

> net_device => sfp_bus (missing in many drivers) => sfp (internal) => i2c_adapter

>

> For example: ice driver does not create an i2c_adapter or sfp_bus, even though many of the NICs using that driver have SFP28 or QSFP28 pluggable cages.



So Linux Ethernet drivers fall into two classes. Those where Linux

driver the hardware, making use of phylink/phylib, and those where

firmware drive the hardware, eg ice, and pretty much all intel

hardware, and most NICs which support > 10G.



For NICs using firmware, you will need to talk to each vendor, and ask

them to extend their firmware to support your SFP.



For NICs where Linux drives the hardware, which is pretty much all

NICs used in embedded systems, with a bandwidth up to 1G, and some

10G, provide an implementation of the protocol in mdio-i2c, and a PHY

driver, and it should all just work.



Looking at the other devices you pointed to, one used a Marvell

88q2xxx, for which a Linux driver already exists. And there was

sufficient hints in the document to make writing the I2C protocol

possible. The other device explicitly described the I2C protocol, but

did not mention what PHY was used, so might need a PHY driver. But

there are not too many T1 PHYs, so it might have a driver already.



    Andrew

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Andrew Lunn]

> That does not sound reasonable, given that the only interface needed
> to the SFP/PHY is the I2C bus which the kernel could access directly
> (to read EEPROM for example)

The MAC driver needs to know what the PHY has negotiated. Should it be
sending packets at 10Mbps half duplex, or 1G full duplex. Has the PHY
negotiated pause? sync or async pause? The configuration API via
netlink is via the top of the MAC driver. So the MAC driver needs to
ask the PHY to advertise what the user wants it to advertise. Enabling
loopback again comes via the MAC driver. There are all sorts of APIs
between the MAC and the PHY. The firmware needs to implement all
these. You cannot drive the PHY independent of the MAC.

And when you consider this is an SFP, ideally you need access to the
GPIO lines. You want to know when a module is inserted. For a copper
SFP, LOS has less meaning, so you can probably do without it. You
could maybe use TX_ENABLE to save power when the MAC is admin down.

I'm actually surprised you are interested in ice. You seem to be
targeting automotive. I would of expected a more embedded SoC,
probably ARM based, and those do tend to have Linux driving the
hardware.

	Andrew

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Ayoub Kaanich]

Hi,

I suppose a bit of context is required here.

We develop SFP modules on top of automotive PHYs, the SFP module takes care of all what's needed for the PHY to function correctly (it has a mini embedded processor).

The NIC firmware does not need to know the details of the PHY and how it operates, we take care of that in the SFP.

The SFP modules we develop, are not meant to go in the car, they are meant to go into PC test-benches that communicate and validated the embedded devices.
This is the reason we are interested in the Intel cards in particular (and not embedded systems)


The issue is that automotive PHYs have extra functions, not available in standard SFP 1000BASET/Fiber modules.

Namely:

* 1000BASET1 PHY needs to be assigned a role (either master or slave), a standard NIC have no concept of this.
* The PHY have multiple operational speeds, for example 100BASET1 and 1000BASET1

Example of how it looks like, can be found in table 9: https://flex-product.com/assets/produkte/fl3x_sfp_1000base-t1/instruction_for_use_fl3x_sfp_1000base-t1.pdf

In order to set those configurations, we need to send an I2C command to the SFP module; to inform it in which mode the user wants it to work (the entire config is just few bytes of data)

This pattern is common in automotive SFPs, where SFP behaves as close as possible to a Fiber/RJ45 SFP so "it just works".

We made workarounds using DIP-Switches in the SFP module body so far, but that's won't scale for the next generation of automotive features:

* Configuring the PHY Macsec certificates
* Automotive TC10 (sleep/wakeup commands)

To make those features work, the only interface available between the PC and SFP, is the I2C bus controlled by the NIC driver.

Since this bus is already exposed for other operations (like read EEPROM and flash EEPROM), it would be nice if the kernel was able to expose the I2C bus to third party drivers, so that SFP manufactures can develop SFP drivers.

Best Regards.

Ayoub Kaanich

Principal Software Engineer
Engineering Department







________________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, July 15, 2026 04:49 PM
To: Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>
Cc: Russell King <linux@armlinux.org.uk>; netdev@vger.kernel.org <netdev@vger.kernel.org>; Dr. Lars Völker <lars.voelker@technica-engineering.de>
Subject: Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



> That does not sound reasonable, given that the only interface needed

> to the SFP/PHY is the I2C bus which the kernel could access directly

> (to read EEPROM for example)



The MAC driver needs to know what the PHY has negotiated. Should it be

sending packets at 10Mbps half duplex, or 1G full duplex. Has the PHY

negotiated pause? sync or async pause? The configuration API via

netlink is via the top of the MAC driver. So the MAC driver needs to

ask the PHY to advertise what the user wants it to advertise. Enabling

loopback again comes via the MAC driver. There are all sorts of APIs

between the MAC and the PHY. The firmware needs to implement all

these. You cannot drive the PHY independent of the MAC.



And when you consider this is an SFP, ideally you need access to the

GPIO lines. You want to know when a module is inserted. For a copper

SFP, LOS has less meaning, so you can probably do without it. You

could maybe use TX_ENABLE to save power when the MAC is admin down.



I'm actually surprised you are interested in ice. You seem to be

targeting automotive. I would of expected a more embedded SoC,

probably ARM based, and those do tend to have Linux driving the

hardware.



        Andrew

Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages

[Andrew Lunn]

> The issue is that automotive PHYs have extra functions, not
> available in standard SFP 1000BASET/Fiber modules.

But this is not a fiber module. It is a copper module. How are you
setting the connector byte at 130? Do you have an RJ45?
SFF8024_CONNECTOR_RJ45? The other option is SFF8024_CONNECTOR_UNSPEC
and transceiver byte 134, bit 3 e1000_base_t True to mean twisted
pair.

> Namely:
> 
> * 1000BASET1 PHY needs to be assigned a role (either master or slave), a standard NIC have no concept of this.

Nothing special here:

ethtool -s devname [master-slave preferred-master|preferred-slave|forced-master|forced-slave]

Standard NICs do have this concept. I cannot say if NICs using
firmware actually implement this API, but any NIC using Linux to drive
the hardware probably does, and it is a standard part of phylib, and
802.3 registers in C22 and C45. There are helpers for PHY drivers to
set the bits.

> * The PHY have multiple operational speeds, for example 100BASET1 and 1000BASET1

Again, nothing special. The PHY driver should enumerate what the
capabilities of the PHY are, there are bits defined in 802.3 for this,
so nothing special needed. From that, the MAC can decide how it
configures itself. Again, nothing special.

> In order to set those configurations, we need to send an I2C command
> to the SFP module; to inform it in which mode the user wants it to
> work (the entire config is just few bytes of data)

How are you intercepting the ethtool netlink messages at the top of
the MAC? You need to intercept the ksetting_set/get calls.

Sorry, but for Mainline, you need to follow Mainline way of doing
things.

Linux is however open source. Feel free to fork Linux, make whatever
changes you want, and ship your fork to your customers.

	Andrew