Re: [PATCH net-next v1] r8169: implement get_module functions for rtl8127atf

[Fabio Baltieri <fabio.baltieri@gmail.com>]

On Sun, Apr 05, 2026 at 12:46:41AM +0200, Andrew Lunn wrote:
> On Sat, Apr 04, 2026 at 11:55:25PM +0200, Heiner Kallweit wrote:
> > On 04.04.2026 22:13, Fabio Baltieri wrote:
> > > Implement get_module_info and get_module_eeprom for supported devices,
> > > right now that's the rtl8127atf.
> > > 
> > > This enables using ethtool to retrieve the transceiver identification
> > > and diagnostic data.
> > > 
> > > Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
> > > ---
> > > 
> > > Hi,
> > > 
> > > Realtek released a new out of tree driver for the rtl8127 and it
> > > includes some code that exposes the I2C controller connected to the SFP
> > > port.
> > > 
> > > This patch implements get_module_info and get_module_eeprom based on the
> > > information found on that driver, it allows ethtool to fetch the SFP
> > > module information, which is useful both to identify the module and to
> > > track the health of fiber optic transceivers.
> > > 
> > > The logic for the SFF standard and i2c address selection is borrowed
> > > directly from the aquantia/atlantic driver, I don't have a lot of stuff
> > > to test it but I was able to trigger all code paths from a fiber optic
> > > transceiver and an SFP cable I have available.
> > > 
> > 
> > Hi Fabio, thanks for the patch. Being able to access the SFP I2C bus is an
> > important step towards future phylink/SFP support.
> > 
> > @Russell/@Andrew
> > I'm not really familiar with the phylink and sfp code. And I would like to have
> > the functionality being implemented here reusable once we do further steps
> > towards phylink support in r8169. So how shall the code be modeled, which
> > components are needed?
> > - Shall the SFP I2C bus be modeled as a struct i2c_adapter?
> 
> Yes, that would be best. Call i2c_add_adapter() to add it to the I2C
> core. The SFP code in drivers/net/phy can then make use of it.
> 
> > - Shall we (partially?) implement a struct sfp, so that functions like
> >   sfp_module_eeprom() can be used (implicitly)?
> > 
> > I assume this patch includes logic which duplicates what is available in
> > phylink/sfp already. I'd a appreciate any hints you can provide.
> 
> No. phylink etc will end up populating netdev->sfp_bus, and then
> get_module_eeprom_by_page() should then just make the module work in
> ethtool.
> 
> The interesting bit if gluing it all together, without DT. But
> txgbe_phy.c should be something you can copy from.
> 
> Does the out of tree driver give access to GPIOs connected to the SFP
> cage pins? Ideally you want those as well, for loss of signal,
> transmitter disable, knowing when a module has been inserted into the
> cage, etc.

The current version does not seem to do that, maybe the Realtek folks
can chime in about it.

I'll look into the dw driver, thanks for the pointer.

> And you will need a PCS driver.
> 
> But first step is probably to work with the existing Base-T devices
> and convert the driver to phylink.