netdev - Re: [PATCH RFC] increase i2c_mii_poll timeout for very slow SFP modules

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: <21cb8551-ce9c-4051-8b40-2ada0ef51a33@kabelmail.de>
Date: Tue, 30 Sep 2025 14:41:40 +0200
From: Janpieter Sollie <janpieter.sollie@...elmail.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, 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>,
 netdev@...r.kernel.org, Marek Behún <kabel@...nel.org>
Subject: Re: [PATCH RFC] increase i2c_mii_poll timeout for very slow SFP
 modules

Op 29/09/2025 om 15:27 schreef Russell King (Oracle):
> Your persistent attempts to differentiate between the platforms that
> this code was developed on (allegedly, according to you, "high
> performance") and your "embedded devices" is becoming very very
> wearing.
I was surprised reading this.
The code of Marek seems to work since 2023, very few modifications have been made.
I assume it has been tested + used many many times, and nobody ever had problems.

Why target embedded devices?
I also assumed the major use of this code are corporations using enterprise setups.
Whatever device Marek his code was developed for,
It seems to be stable with a total wait of +- 200ms targeting 70ms, for every user using it.
Me using rare setups -> me trying to fix a almost nonexistent situation.
The BPI people suggested it *might* be a power problem.

The phy is known to work correctly, AQR113C has been supported for quite some time now.
I can't imagine the SFP module vendor sells a not-linux-compatible EEPROM which needs > 200 ms.
There must be something inside the module that's slowing down for whatever reason.

So is it wearing?  Yes.

Using your hints, I saw the i2c_transfer_rollball() call takes 10ms to execute,
with a 20ms sleep this is 33% of one loop querying the endpoint for an answer.
If it would have been 10% or even less, I'd simply say:
"increase i to 20, query a few more times".
But in this case I'd rather not.

> Please come back when you've changed your attitude.
>
> Thanks.
>

No worries, you gave me the knowledge I needed to fix it.
If it's that rare, it should not be implemented at all.
I hope my clarification explains.  I've overthought things more-than-once.

Thanks