Message-ID: <aM6xwq6Ns_LGxl4o@shell.armlinux.org.uk>
Date: Sat, 20 Sep 2025 14:53:06 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Janpieter Sollie <janpieter.sollie@...elmail.de>
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)

On Sat, Sep 20, 2025 at 02:09:47PM +0200, Janpieter Sollie wrote:
> I tested a SFP module where the i2c bus is "unstable" at best.
> different i2c timeouts occured, resulting in a "phy not detected" error message.

If the I2C bus is so unstable that attempting to read a register from
the PHY, which should take no more than 70ms, takes in excess of 200ms
(which is what it takes for the loop to time out) for just one
register, it seems to me that you're chasing a dead horse.

However, looking at the rest of your message, I don't think you have
a problem with the I2C bus at all.

> I noticed a few hard-coded numbers in i2c_rollball_mii_pol(), which is always suspicious.

Sorry, but I don't follow the same reasoning. If they aren't hard-coded,
but are "knobs" in e.g. sysfs, then how do we teach people how to "tune"
them? When should they "tune" them? No, the less knobs there are, the
better for the user, provided timeouts are sensible - and I think
waiting 200ms for a register to be read is already an excessively long
timeout.

In any case, if we have a module that takes longer, that's new, and the
timeouts need to be adjusted - not on a per-module basis, and not by
users having to tinker with stuff in sysfs.

> In order to lower the stress on the i2c bus, I made the following patch.
> is it the best way to "not-stress-sensitive-devices"?
> Will it cause a performance regression on some other SFP cages?
> 
> Eric Woudstra told me another option was to add a few tries, increasing i = 10,
> If the issue isn't the device itself, but the stress on the i2c bus is too
> high, it may not be a real solution.

Why are you concerned about "stress" on the I2C bus? What kind of
stress? The bus is 5V or 3.3V signalling, running at 100kHz (so slow)
with resistive pull-ups. Apart from the bus transitions (which cause
CMOS to take a pulse of power) the energy from that will be nothing
compared to the energy required to run the CPU, which is operating
much faster with many more CMOS transistors switching.

> 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,

None of this has been written for "high performance" equipment. It was
developed on a SolidRun clearfog platform (Armada 388 based) which is
hardly "high performance". It's been used with bit-banged I2C as well
on Macchiatobin platforms.

I'm guessing that the problem is not an I2C bus problem (which would
cause i2c_transfer_rollball() to return an error, and the loop to quit),
but yet another cheap and nasty SFP module that takes much longer
than 70ms to respond under the "Rollball" protocol.

So, what we need you to do is to work out how long it takes this module
to respond, and whether it always takes a long time to respond. Please
add some debugging to i2c_rollball_mii_poll() to measure the amount of
time it takes for the module to respond - and please measure it for
several transactions.

You can use jiffies, and convert to msecs using jiffies_to_msecs(),
or you could use ktime_get_ns().

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists