[PATCH net-next v4] net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c

[Jan Hoffmann]

On 2026-05-29 at 12:13, Maxime Chevallier wrote:
> Hi Petr,
> 
> On 5/19/26 06:32, Petr Wozniak wrote:
>> The "OEM"/"SFP-10G-T" quirk entry in sfp_fixup_rollball_cc()
>> unconditionally forces MDIO_I2C_ROLLBALL for all modules matching that
>> vendor/part-number combination.  This works for modules that genuinely
>> implement a RollBall I2C-to-MDIO bridge, but silently breaks modules
>> that share the same EEPROM strings without having such a bridge.
>>
>> The Realtek RTL8261BE-CG is one such module: a pure copper 10G SFP+
>> media converter with no I2C-to-MDIO bridge.  Its EEPROM reports
>> vendor="OEM", part="SFP-10G-T-I", and -- critically -- Vendor OUI
>> 00:00:00, making OUI-based differentiation impossible.  With
>> MDIO_I2C_ROLLBALL the kernel stalls waiting for a PHY that never
>> appears:
>>
>>    sfp sfp2: probing phy device through the [MDIO_I2C_ROLLBALL] protocol
> 
> Is it really stalling, or are you facing the 25 seconds retry loop for 
> rollball ?

The retry loop unfortunately takes much longer than 25 seconds if the 
controller in the module is not responding to the Rollball protocol:

- The ".read_c45" method of the Rollball implementation returns 0xffff 
on timeout (which happens after 10 tries, sleeping 20 ms for each).

- When all reads return 0xffff, "get_phy_c45_ids" reads 62 registers 
("MDIO_DEVS1" and "MDIO_DEVS2" for MMD devices 0-29, plus "MDIO_STAT2" 
for MMD 30 and 31).

Considering the 25 attempts for probing, this means the actual retry 
loop is at least 5.5 minutes long. In practice it is even worse, as the 
I2C transfers also take some time.

It seems to me like this is the core of the issue here. If the timeout 
was just 25 seconds, it would be a bit annoying, but still usable.

Jan