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

Message-ID: <f86737b0-a0fe-49a6-aeca-9e51fbdf0f0d@kabelmail.de>
Date: Sat, 20 Sep 2025 12:00:50 +0200
From: Janpieter Sollie <janpieter.sollie@...elmail.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>,
 Heiner Kallweit <hkallweit1@...il.com>, 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>
Subject: Re: [RFC] increase MDIO i2c poll timeout gradually (including patch)

Op 19/09/2025 om 19:04 schreef Andrew Lunn:
> On Fri, Sep 19, 2025 at 03:52:55PM +0200, Janpieter Sollie wrote:
>> Hello everyone,
> Please ensure you Cc: the correct Maintainers.
>
> ./scripts/get_maintainer.pl drivers/net/phy/sfp.c
> Russell King <linux@...linux.org.uk> (maintainer:SFF/SFP/SFP+ MODULE SUPPORT)
> Andrew Lunn <andrew@...n.ch> (maintainer:ETHERNET PHY LIBRARY)
> Heiner Kallweit <hkallweit1@...il.com> (maintainer:ETHERNET PHY LIBRARY)
> "David S. Miller" <davem@...emloft.net> (maintainer:NETWORKING DRIVERS)
> Eric Dumazet <edumazet@...gle.com> (maintainer:NETWORKING DRIVERS)
> Jakub Kicinski <kuba@...nel.org> (maintainer:NETWORKING DRIVERS)
> Paolo Abeni <pabeni@...hat.com> (maintainer:NETWORKING DRIVERS)
> netdev@...r.kernel.org (open list:SFF/SFP/SFP+ MODULE SUPPORT)
> linux-kernel@...r.kernel.org (open list)
Done, sorry, this is my first post here
>
>> I tested a SFP module where the i2c bus is "unstable" at best.
> Please tell us more about the hardware.
>
> Also, what speed do you have the I2C bus running at? Have you tried
> different clock-frequency values to slow down the I2C bus? Have you
> checked the pull-up resistors? I2C problems are sometimes due to too
> strong pull-ups.
The hardware is a bananapi R4 2xSFP using a MT7988a SoC.
The SFP+ module is a RJ45 rollball module using a AQR113C phy, but needs a quirk in sfp.c (added 
below)
I'm not a i2c expert at all,
but about the i2c bus speed, the SFP cage seems to be behind a muxer, not a i2c root.
I could not find anything about i2c bus speed in /proc or /sys, maybe it's impossible to tell?

The dtsi or dtso files do not mention anything about bus speeds, so I honestly do not know.

>
>> A good question may be: is this approach sufficient to close the gap between
>> "high performance" equipment having a stable i2c bus and they do not want to wait,
>> and embedded equipment (the device I tested on was a BPI-R4) where every milliwatt counts?
> Does your board actually confirm to the standards? I2C busses should
> be able to run at 100KHz, as defined by the standard. Also, the SFP
> standards define modules should work at 100KHz. And counting every
> milliwatt makes no sense when you are supposed to be able to deliver
> 3.3V at 300mA, i.e. 1 Watt, to the module.
Sorry, I thought the issue here might be the SFP cage limited to 3W.
While it should be enough to feed the RJ45 short range module, maybe it needs more during 
initalization.
Is there a way to tell?
>
>> Should this be fixed at another point in the initialization process (eg: not
>> probing ridiculously all phy ids)?
> Unfortunately, MDIO over I2C is not standardised. So we have no idea
> what address the PHY will be using, so we need to look at them all. If
> you have an SFF, not an SFP, it might be possible to do some
> optimisation.
>
> 	Andrew
>
Well, that's a bummer.

is it possible to perform stress testing on the bus by randomly reading those phy registers and 
check
whether  the muxer is the cause of the instability, or the target device itself?

Janpieter Sollie


--- a/drivers/net/phy/sfp.c     2025-06-21 15:06:02.086163322 +0200
+++ b/drivers/net/phy/sfp.c     2025-06-21 15:59:41.836883438 +0200
@@ -422,6 +422,13 @@
         sfp->id.base.extended_cc = SFF8024_ECC_10GBASE_T_SFI;
  }

+static void sfp_fixup_oem_10gt(struct sfp *sfp)
+{
+       sfp_fixup_10gbaset_30m(sfp);
+       sfp_fixup_rollball_wait4s(sfp);
+       //sfp->module_t_wait = msecs_to_jiffies(10000);
+}
+
  static void sfp_quirk_2500basex(const struct sfp_eeprom_id *id,
                                 unsigned long *modes,
                                 unsigned long *interfaces)
@@ -516,6 +523,7 @@
         SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),

         SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
+       SFP_QUIRK_F("OEM", "ZK-10G-TX", sfp_fixup_oem_10gt),
         SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
         SFP_QUIRK_M("OEM", "SFP-2.5G", sfp_quirk_oem_2_5g),
         SFP_QUIRK_M("OEM", "SFP-2.5G-BX10-D", sfp_quirk_2500basex),