Message-ID: <20250225140640.382fec83@fedora.home>
Date: Tue, 25 Feb 2025 14:06:40 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Bjørn Mork <bjorn@...k.no>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, davem@...emloft.net,
 Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 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>
Subject: Re: [PATCH net-next 0/2] net: phy: sfp: Add single-byte SMBus SFP
 access

Hi,

On Tue, 25 Feb 2025 13:38:30 +0100
Bjørn Mork <bjorn@...k.no> wrote:

> "Russell King (Oracle)" <linux@...linux.org.uk> writes:
> > On Sun, Feb 23, 2025 at 06:28:45PM +0100, Maxime Chevallier wrote:  
> >> Hi everyone,
> >> 
> >> Some PHYs such as the VSC8552 have embedded "Two-wire Interfaces" designed to
> >> access SFP modules downstream. These controllers are actually SMBus controllers
> >> that can only perform single-byte accesses for read and write.  
> >
> > This goes against SFF-8472, and likely breaks atomic access to 16-bit
> > PHY registers.
> >
> > For the former, I quote from SFF-8472:
> >
> > "To guarantee coherency of the diagnostic monitoring data, the host is
> > required to retrieve any multi-byte fields from the diagnostic
> > monitoring data structure (e.g. Rx Power MSB - byte 104 in A2h, Rx
> > Power LSB - byte 105 in A2h) by the use of a single two-byte read
> > sequence across the 2-wire interface."
> >
> > So, if using a SMBus controller, I think we should at the very least
> > disable exporting the hwmon parameters as these become non-atomic
> > reads.  
> 
> Would SMBus word reads be an alternative for hwmon, if the SMBus
> controller support those?  Should qualify as "a single two-byte read
> sequence across the 2-wire interface."

There are different flavors when it comes to what an SMBus controller
can do. In the case of what this patchset supports, its really about
SMBus controllers that can only perform single-byte operations, which
will cause issues here.

What I have is a controller that only supports I2C_FUNC_SMBUS_BYTE, in
that the controller will issue a STOP after reading/writing one byte.

But if you have a controller that supports, say,
I2C_FUNC_SMBUS_WORD_DATA (i.e. 16 bits words xfers), that's already a
different story, as the diags situation Russell mentions will fit in a
word. That will also make MDIO accesses to embedded PHYs easier, at
least for C22. 

> > Whether PHY access works correctly or not is probably module specific.
> > E.g. reading the MII_BMSR register may not return latched link status
> > because the reads of the high and low bytes may be interpreted as two
> > seperate distinct accesses.  
> 
> Bear with me.  Trying to learn here.  AFAIU, we only have a defacto
> specification of the clause 22 phy interface over i2c, based on the
> 88E1111 implementation.  As Maxime pointed out, this explicitly allows
> two sequential distinct byte transactions to read or write the 16bit
> registers. See figures 27 and 30 in
> https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e1111-datasheet.pdf
> 
> Looks like the latch timing restrictions are missing, but I still do not
> think that's enough reason to disallow access to phys over SMBus.  If
> this is all the interface specification we have?
> 
> I have been digging around for the RollBall protocol spec, but Google
> isn't very helpful.  This list and the mdio-i2c.c implementation is all
> that comes up.  It does use 4 and 6 byte transactions which will be
> difficult to emulate on SMBus.  But the
> 
> 	/* By experiment it takes up to 70 ms to access a register for these
> 	 * SFPs. Sleep 20ms between iterations and try 10 times.
> 	 */
> 
> comment in i2c_rollball_mii_poll() indicates that it isn't very timing
> sensitive at all. The RollBall SFP+ I have ("FS", "SFP-10G-T") is faster
> than the comment indicates, but still leaves plenty of time for the
> single byte SMBus transactions to complete.
> 
> Haven't found any formal specification of i2c clause 45 access either.
> But some SFP+ vendors have been nice enough to document their protocol
> in datasheets.  Examples:
> 
> https://www.repotec.com/download/managed-ethernet/ds-ml/01-MOD-M10GTP-DS-verB.pdf
> https://www.apacoe.com.tw/files/ASFPT-TNBT-X-NA%20V1.4.pdf
> 
> They all seem to agree that 2/4/6 byte accesses are required, and they
> offer no single byte alternative even if the presence of a "smart"
> bridge should allow intelligent latching.  So this might be
> "impossible" (aka "hard") to do over SMBus.   I have no such SFP+ so I
> cannot even try.
> 
> > In an ideal world, I'd prefer to say no to hardware designs like this,
> > but unfortunately, hardware designers don't know these details of the
> > protocol, and all they see is "two wire, oh SMBus will do".  
> 
> I believe you are reading more into the spec than what's actually there.
> 
> SFF-8419 defines the interface as
> 
>  "The SFP+ management interface is a two-wire interface, similar to
>   I2C."
> 
> There is no i2c requirement. This does not rule out SMBus. Maybe I am
> reading too much into it as well, but in my view "similar to I2C" sounds
> like they wanted to include SMBus.
> 
> Both the adhoc phy additions and the diagnostic parts of SFF-8472
> silently ignores this.  I do not think the blame for any incompatibilty
> is solely on the host side here.

At least for this series, SMBus by itself isn't the main issue, the
main problem is single-byte SMBus. As soon as you can do 16 bits xfers,
that rules-out a whole class of potential problems (which doesn't mean
there will be no issue :) ), but I haven't really digged into how C45
and rollball will behave in that case.

Note that the series actually doesn't support I2C_FUNC_SMBUS_WORD_DATA,
but doesn't prevent it either :)

The driver for the SMBus controller in the rtl930x SoC you mention seem
to support I2C_FUNC_SMBUS_WORD_DATA and even longer xfers, in which
case you could add SFP support for smbus-only controllers in a much
more reliable way. It could be conceivable to remove the hwmon-disabled
restriction for I2C_FUNC_SMBUS_WORD_DATA.

Maxime

Powered by blists - more mailing lists