linux-kernel - Re: [PATCH net-next v2 1/2] net: phy: sfp: Add support for SMBus module 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250308194251.30622971@fedora.home>
Date: Sat, 8 Mar 2025 19:42:51 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: davem@...emloft.net, Andrew Lunn <andrew@...n.ch>, 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>
Cc: 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 v2 1/2] net: phy: sfp: Add support for SMBus
 module access

Hi,

On Tue, 25 Feb 2025 12:20:39 +0100
Maxime Chevallier <maxime.chevallier@...tlin.com> 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@...ux.dev>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
> ---
> 
> 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