Re: [PATCH net-next v2 1/2] net: phy: sfp: Add support for SMBus module access

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi Sean,

On Tue, 25 Feb 2025 13:41:57 -0500
Sean Anderson <sean.anderson@linux.dev> wrote:

> On 2/25/25 13:04, Russell King (Oracle) wrote:
> > On Tue, Feb 25, 2025 at 12:20:39PM +0100, Maxime Chevallier wrote:  
> >> The SFP module's eeprom and internals are accessible through an i2c bus.
> >> However, all the i2c transfers that are performed are SMBus-style
> >> transfers for read and write operations.  
> > 
> > Note that there are SFPs that fail if you access them by byte - the
> > 3FE46541AA locks the bus if you byte access the emulated EEPROM at
> > 0x50, address 0x51. This is documented in sfp_sm_mod_probe().
> > 
> > So there's a very real reason for adding the warning - this module
> > will not work!
> >   
> 
> I had a look at sfp_sm_mod_probe, and from what I can tell the SFP that
> I was having issues with should have been fixed by commit 426c6cbc409c
> ("net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips"). I
> re-tested without this series applied, and the SFP still worked. So I
> guess I don't have an SFP module with the issue this series is trying to
> address after all.

I see, this series actually wasn't supposed to solve that at all (but
it's true that the solution was to fallback to 1-byte access, as
Russell explains on that thread) :)

The use-case for that series is to deal with situations where the Host
(i2c master) is only capable of 1-byte transactions (it's not a true
i2c controller, but rather a very limited smbus controller) :)

Maxime