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

[Jan Hoffmann]

Hi Petr,

The patch seems to be malformed. I had to do some manual changes to get 
it applied.

On 2026-05-19 at 18:20, 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 forced, the module silently ACKs the unlock password
> write, the MDIO bus is created, but no PHY responds; the SFP state
> machine cycles through the RollBall PHY-probe retry window before
> reporting no PHY.
> 
> Move the probe into i2c_mii_init_rollball() in mdio-i2c.c, where the
> RollBall protocol constants are already defined.  After sending the
> unlock password, issue a CMD_READ and wait ~70 ms for CMD_DONE.  A
> genuine RollBall bridge asserts CMD_DONE within that window; modules
> without a bridge never do, so i2c_mii_init_rollball() returns -ENODEV.
> mdio_i2c_alloc() propagates -ENODEV to the caller to signal that no
> bridge is present and PHY probing should be skipped.
> sfp_sm_add_mdio_bus() catches -ENODEV and transitions
> sfp->mdio_protocol to MDIO_I2C_NONE so the rest of the state machine
> skips PHY probing for this module.

This approach works fine here for a module identifying as "OEM 
SFP-10G-T" / "OEM SFP-10G-T-I", which doesn't support Rollball (the 
label on the outside says "ATS SFP-10G-T", and the PHY inside is also an 
RTL8261BE).

Using this patch, the module works right away, without waiting several 
minutes for the PHY probing retry loop to finish (see my reply to the 
previous patch version for details).

However, I am wondering if this could potentially break PHY access on 
other modules, which do support the Rollball protocol.

I also have a 2.5G module (XikeStor SKT-2.5G-100M). It supports 
Rollball, but does not respond to commands immediately. With this patch, 
it only works with a small delay in "module_t_wait" (one second is 
fine). For that particular module this is not a problem, as it is not 
yet supported. So the necessary delay could be included when an SFP 
quirk is added for it.

But if there are already supported modules behaving similarly it could 
be an issue for those (assuming they don't have a long enough 
"module_t_wait" in the SFP quirk, as it wasn't really needed so far).

> Add "OEM"/"SFP-10G-T-I" to the quirk table so RTL8261BE modules enter
> the probe path; genuine RollBall modules continue to work as before.

I am a bit confused by this change. This is the same model name which is 
used by my non-Rollball ATS module when is linked at 1G on the copper 
side (so it doesn't need to go through the probe path). Are there other 
modules actually supporting Rollball which also use the model name 
including "-I"?

Jan