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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250225192055.32168b48@fedora.home>
Date: Tue, 25 Feb 2025 19:20:55 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: 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>,
 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

On Tue, 25 Feb 2025 18:04:29 +0000
"Russell King (Oracle)" <linux@...linux.org.uk> 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!

That's indeed pretty serious and since we can't even read the
eeprom, there's not even a chance to have, say, a list of modules that
will break with 1-byte io. So indeed the warning is needed...

Thanks

Maxime