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

[Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>]

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