linux-kernel - Re: [PATCH net-next v3 0/2] net: phy: sfp: Add single-byte SMBus SFP access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b199d9e2-1b95-468a-b826-08abe1795557@lunn.ch>
Date: Tue, 18 Mar 2025 13:21:07 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net, Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>,
	Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
	Florian Fainelli <f.fainelli@...il.com>,
	Köry Maincent <kory.maincent@...tlin.com>,
	Simon Horman <horms@...nel.org>,
	Romain Gantois <romain.gantois@...tlin.com>,
	Antoine Tenart <atenart@...nel.org>,
	Marek Behún <kabel@...nel.org>,
	Sean Anderson <sean.anderson@...ux.dev>,
	Bjørn Mork <bjorn@...k.no>
Subject: Re: [PATCH net-next v3 0/2] net: phy: sfp: Add single-byte SMBus SFP
 access

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@...n.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