Hello everyone,

This is V3 for the single-byte SMBus support for SFP cages as well as
embedded PHYs accessed over mdio-i2c.

Discussions on the previous iteration raised some questions on the
ordering of the accesses (from Andrew), after further testing it still
seems correct to me, I can properly read EEPROMS and by hacking around,
read 16 bits values (although this is disabled anyways).

This series compared to V2 changes the approach used internally to use
the degraded mode (no hwmon), by setting the i2c_block_size to 1 and
re-using the logic already in place to deal with that.

As we now have 2 scenarios for 1-byte accesses (broken EEPROM that needs
to be accessed 1 byte at a time or single-byte SMBus), I've updated some
of the in-place error logs. Users should still be plenty warned and
made aware of the situation.

I also renamed the internal helpers to reflect that we use single-byte
accesses.

The rest was left untouched (I didn't have time yet to test around with
Rollball for example or 16-bits SMBus).

As I reworked patch 1, I dropped Sean's tested-by :(

V2 : https://lore.kernel.org/netdev/20250225112043.419189-1-maxime.chevallier@bootlin.com/
V1 : https://lore.kernel.org/netdev/20250223172848.1098621-1-maxime.chevallier@bootlin.com/#t

@Maintainers: I already have a few series queued for review, let me know
if you prefer that I resend that one at a later time.

Maxime

Maxime Chevallier (2):
  net: phy: sfp: Add support for SMBus module access
  net: mdio: mdio-i2c: Add support for single-byte SMBus operations

 drivers/net/mdio/mdio-i2c.c | 79 ++++++++++++++++++++++++++++++++++-
 drivers/net/phy/sfp.c       | 82 +++++++++++++++++++++++++++++++++----
 2 files changed, 152 insertions(+), 9 deletions(-)

-- 
2.48.1

On Fri, Mar 14, 2025 at 05:23:16PM +0100, Maxime Chevallier wrote:
> Hello everyone,
> 
> This is V3 for the single-byte SMBus support for SFP cages as well as
> embedded PHYs accessed over mdio-i2c.

Just curious, what hardware is this? And does it support bit-banging
the I2C pins? If it does, you get a choice, slow but correct vs fast
but broken and limited?

	Andrew

Hello Andrew,

On Mon, 17 Mar 2025 22:34:09 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

> On Fri, Mar 14, 2025 at 05:23:16PM +0100, Maxime Chevallier wrote:
> > Hello everyone,
> > 
> > This is V3 for the single-byte SMBus support for SFP cages as well as
> > embedded PHYs accessed over mdio-i2c.  
> 
> Just curious, what hardware is this? And does it support bit-banging
> the I2C pins? If it does, you get a choice, slow but correct vs fast
> but broken and limited?

The HW is a VSC8552 PHY that includes a so-called "i2c mux", which in
reality is that smbus interface.

             +---------+
 +-----+     |         |     +-----+
 | MAC | --- | VSC8552 | --- | SFP |
 +-----+     |         |     +-----+
    |        |         |        |
    +-mdio---|         |-smbus--+
             +---------+

it has 4 SCL and 1 SDA lines, that you can connect to 4 different SFP
cages.

You perform transfers by using 2 dedicated MDIO registers , one
register contains xfer info such as the address to access over smbus,
the direction of the xfer, and the other one contains data :
 - lower byte is write data
 - upper byte is read-back data

and that's all you have :( so the HW can only really do one single byte
transfer at a time, then you re-configure the 2 registers above, rinse
and repeat.

Looks like the datasheet is publicly available :

https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/60001809A.pdf

The whole xfer protocol is described in page 35.

On the board itself, the i2c for the SFP cage is connected to that PHY
smbus.

Now it looks like there's some pinmux within the PHY and we can use the
PHY as a gpio controller, so we could consider using a bitbang approach
indeed (provided that SFP is on PHY smbus bus 0 or 1).

I didn't consider that, it's probably worth giving a try, even if as
you say it's probably be very slow, each bit being set amounting to a
mdio xfer towards the PHY.

But if it allows better HW support, and the SFP reacts well on slow
busses, it may be work :)

Do we still want the current series ? Looks like some other people were
interested in that.

On my side that's the second time I deal with a product that uses a PHY
from this family and uses that smbus feature (but if that bitbang thing
works it's probably better)

Thanks,

Maxime

On Tue, Mar 18, 2025 at 09:25:51AM +0100, Maxime Chevallier wrote:
> Hello Andrew,
> 
> On Mon, 17 Mar 2025 22:34:09 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
> > On Fri, Mar 14, 2025 at 05:23:16PM +0100, Maxime Chevallier wrote:
> > > Hello everyone,
> > > 
> > > This is V3 for the single-byte SMBus support for SFP cages as well as
> > > embedded PHYs accessed over mdio-i2c.  
> > 
> > Just curious, what hardware is this? And does it support bit-banging
> > the I2C pins? If it does, you get a choice, slow but correct vs fast
> > but broken and limited?
> 
> The HW is a VSC8552 PHY that includes a so-called "i2c mux", which in
> reality is that smbus interface.
> 
>              +---------+
>  +-----+     |         |     +-----+
>  | MAC | --- | VSC8552 | --- | SFP |
>  +-----+     |         |     +-----+
>     |        |         |        |
>     +-mdio---|         |-smbus--+
>              +---------+
> 
> it has 4 SCL and 1 SDA lines, that you can connect to 4 different SFP
> cages.
> 
> You perform transfers by using 2 dedicated MDIO registers , one
> register contains xfer info such as the address to access over smbus,
> the direction of the xfer, and the other one contains data :
>  - lower byte is write data
>  - upper byte is read-back data
> 
> and that's all you have :( so the HW can only really do one single byte
> transfer at a time, then you re-configure the 2 registers above, rinse
> and repeat.
> 
> Looks like the datasheet is publicly available :
> 
> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/60001809A.pdf
> 
> The whole xfer protocol is described in page 35.
> 
> On the board itself, the i2c for the SFP cage is connected to that PHY
> smbus.
> 
> Now it looks like there's some pinmux within the PHY and we can use the
> PHY as a gpio controller, so we could consider using a bitbang approach
> indeed (provided that SFP is on PHY smbus bus 0 or 1).
> 
> I didn't consider that, it's probably worth giving a try, even if as
> you say it's probably be very slow, each bit being set amounting to a
> mdio xfer towards the PHY.

This going to be very slow. My guess is people will live with limited
functionality. But it could be interesting to implement the GPIO
support and see how slow it is.

It might also be worth pointing out to microchip how broken this is,
and see if they can do anything about it in the firmware running in
PHY. 2 byte SMBUS would solve the problems.

> Do we still want the current series ? Looks like some other people were
> interested in that.

Yes, it is useful.

	Andrew