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

[Petr Wozniak]

On 2026-05-20 at 23:19, Jan wrote:
> The patch seems to be malformed. I had to do some manual changes to get
> it applied.

Thanks for testing and for taking the time to apply it manually. v6 has
been sent just now with the formatting fixed.

> Using this patch, the module works right away, without waiting several
> minutes for the PHY probing retry loop to finish.

Great to hear it works on your ATS SFP-10G-T module as well.

> 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".

v6 replaces the fixed 70 ms sleep with a 10 x 20 ms polling loop
(200 ms total), matching the tolerance used by the existing
i2c_rollball_mii_poll(). This should give slow RollBall bridges a
better chance to assert CMD_DONE in time.

The XikeStor module is not yet in the quirk table so it won't be
affected by this patch. When support for it is added later, an
appropriate module_t_wait can be set in the quirk entry if needed.

> I am a bit confused by this change. This is the same model name which
> is used by my non-Rollball ATS module when it is linked at 1G on the
> copper side. Are there other modules actually supporting Rollball which
> also use the model name including "-I"?

The "OEM"/"SFP-10G-T-I" quirk uses sfp_fixup_rollball (not
sfp_fixup_rollball_cc), which routes the module through the new probe
path rather than forcing MDIO_I2C_ROLLBALL unconditionally. If the
module has no RollBall bridge -- as is the case for your ATS module --
i2c_mii_probe_rollball() returns -ENODEV and sfp_sm_add_mdio_bus()
transitions mdio_protocol back to MDIO_I2C_NONE, so PHY probing is
skipped entirely. Non-bridge modules are handled correctly regardless
of whether they respond at 1G or 10G.

Thanks again for the detailed feedback.

Petr