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: <20250225194829.724eca08@fedora.home>
Date: Tue, 25 Feb 2025 19:48:29 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Sean Anderson <sean.anderson@...ux.dev>
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>, Bjørn Mork
 <bjorn@...k.no>
Subject: Re: [PATCH net-next v2 1/2] net: phy: sfp: Add support for SMBus
 module access

Hi Sean,

On Tue, 25 Feb 2025 13:41:57 -0500
Sean Anderson <sean.anderson@...ux.dev> wrote:

> On 2/25/25 13:04, Russell King (Oracle) wrote:
> > On Tue, Feb 25, 2025 at 12:20:39PM +0100, Maxime Chevallier 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.  
> > 
> > Note that there are SFPs that fail if you access them by byte - the
> > 3FE46541AA locks the bus if you byte access the emulated EEPROM at
> > 0x50, address 0x51. This is documented in sfp_sm_mod_probe().
> > 
> > So there's a very real reason for adding the warning - this module
> > will not work!
> >   
> 
> I had a look at sfp_sm_mod_probe, and from what I can tell the SFP that
> I was having issues with should have been fixed by commit 426c6cbc409c
> ("net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips"). I
> re-tested without this series applied, and the SFP still worked. So I
> guess I don't have an SFP module with the issue this series is trying to
> address after all.

I see, this series actually wasn't supposed to solve that at all (but
it's true that the solution was to fallback to 1-byte access, as
Russell explains on that thread) :)

The use-case for that series is to deal with situations where the Host
(i2c master) is only capable of 1-byte transactions (it's not a true
i2c controller, but rather a very limited smbus controller) :)

Maxime