netdev - Re: [RFC] increase MDIO i2c poll timeout gradually (including patch)

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: <831ecd46-b658-4bc8-9268-e5202a6e0ebe@kabelmail.de>
Date: Tue, 23 Sep 2025 09:02:31 +0200
From: Janpieter Sollie <janpieter.sollie@...elmail.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 Heiner Kallweit <hkallweit1@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [RFC] increase MDIO i2c poll timeout gradually (including patch)

Op 22/09/2025 om 17:25 schreef Russell King (Oracle):
> On Mon, Sep 22, 2025 at 04:30:56PM +0200, Janpieter Sollie wrote:
>> Based on my mails, I can certainly see why you're thinking this way.
>> I have no idea what goes wrong anywhere between me making a modification in
>> the mdio.c file -> i2c code -> ... -> SFP phy.
>> I'm curious what goes wrong, notice the 3 dots in between,
>> I know there's a pca9545 muxer in in there further complicating it, but that's about it.
>>
>> Long story short: should I somehow try to test the reliability of something else?
> What you have in these setups is:
>
> 1. The I2C bus from the host to the SFP module pins. On the SFP module
>     is an EEPROM at address 0x50 which contains some useful, some not so
>     useful identification of the module.
>
> 2. Sometimes there is a PHY at 0x56, which is normally a Marvell
>     88E1111 which was designed for use on SFPs, and has not only the
>     conventional MDIO bus connectivity, but also supports I2C as well.
The page is indeed present in i2cdetect ...
>
> 3. Some baseT modules, the PHY is not accessible.
>
I saw this on another SFP+ RJ45 module, I have 2 of them (unused),
I'm thinking of breaking the metal cage of one to see what's inside
(out if curiosity). What I do know is that there's no page 56.
>
> It may be interesting to work out whether it is a specific register or
> set of registers that need longer access, and augment our knowledge
> about what is going on with this stuff.
Do you have a suggestion for this? I mean, runninig 'time i2cget xx xx'
in a for loop for all pages (50, 51 and 56) over all registers 10 times or so takes a huge 
amount of time.
>
> Ultimately yes, we likely have no option but to increase the timeout,
> and to do that I suggest simply increasing the number of loops -
> having the approx. 20ms delay between each attempt doesn't stress
> anything.
>
Let's try to avoid that at all costs: if I'm the first one reporting a problem like this,
it may not be useful to let the whole subsystem sit back and relax for all modules,
it may hide the case where there's really something wrong.

Thanks