netdev - 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: <cd630175-d0e4-41e3-bc4c-41d32647e9ed@linux.dev>
Date: Tue, 25 Feb 2025 13:41:57 -0500
From: Sean Anderson <sean.anderson@...ux.dev>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Maxime Chevallier <maxime.chevallier@...tlin.com>
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>, Bjørn Mork
 <bjorn@...k.no>
Subject: Re: [PATCH net-next v2 1/2] net: phy: sfp: Add support for SMBus
 module access

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.

--Sean