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

[Andrew Lunn <andrew@lunn.ch>]

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