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

[Maxime Chevallier]

Hi,

On Tue, 25 Feb 2025 12:20:39 +0100
Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> 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.
> 
> It is possible that the SFP might be connected to an SMBus-only
> controller, such as the one found in some PHY devices in the VSC85xx
> family.
> 
> Introduce a set of sfp read/write ops that are going to be used if the
> i2c bus is only capable of doing smbus byte accesses.
> 
> As Single-byte SMBus transaction go against SFF-8472 and breaks the
> atomicity for diagnostics data access, hwmon is disabled in the case
> of SMBus access.
> 
> Moreover, as this may cause other instabilities, print a warning at
> probe time to indicate that the setup may be unreliable because of the
> hardware design.
> 
> Tested-by: Sean Anderson <sean.anderson@xxxxxxxxx>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx>
> ---
> 
> V2: - Added Sean's tested-by
>     - Added a warning indicating that operations won't be reliable, from
>       Russell and Andrew's reviews
>     - Also added a flag saying we're under a single-byte-access bus, to
>       both print the warning and disable hwmon.
> 
>  drivers/net/phy/sfp.c | 79 +++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 73 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 9369f5297769..6e9d3d95eb95 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -282,6 +282,7 @@ struct sfp {
>  	unsigned int rs_state_mask;
>  
>  	bool have_a2;
> +	bool single_byte_access;

Looking back at that code and our discussions, struct sfp already has an
"i2c_block_size", that is set to 1 for modules with broken emulated
eeprom, and there's already some logging and all the logic to disable
hwmon in such case.

So I think V3 will ditch that "single_byte_access" bool, and rather add
a "i2c_max_block_size" member, set depending on the bus capabilities,
that we'll use to clamp the i2c_block_size.

Of course the big warning to say that the design is inherently broken
because we're on a bus that's limited will stay, but that should make
our life easier for proper non-single-byte smbus support, and also
keep the code flow cleaner.

Let me know what you think,

Maxime