[PATCH net-next] net: sfp: add quirk for ZOERAX SFP-2.5G-T

[PATCH net-next] net: sfp: add quirk for ZOERAX SFP-2.5G-T

[Jan Hoffmann]

This is a 2.5G copper module which appears to be based on a Motorcomm
YT8821 PHY. There doesn't seem to be a usable way to to access the PHY
(I2C address 0x56 provides only read-only C22 access, and Rollball is
also not working).

The module does not report the correct extended compliance code for
2.5GBase-T, and instead claims to support SONET OC-48 and Fibre Channel:

  Identifier          : 0x03 (SFP)
  Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
  Connector           : 0x07 (LC)
  Transceiver codes   : 0x00 0x01 0x00 0x00 0x40 0x40 0x04 0x00 0x00
  Transceiver type    : FC: Multimode, 50um (M5)
  Encoding            : 0x05 (SONET Scrambled)
  BR Nominal          : 2500MBd

Despite this, the kernel still sets 2500Base-X as interface mode based
on the (incorrect) nominal signaling rate.

However, it is also necessary to disable auto-negotiation for the module
to actually work. Thus, create a SFP quirk to do this.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
---
Note: I'm not quite sure "sfp_quirk_disable_autoneg" is enough here, or
if it would be appropriate to use the full "sfp_quirk_oem_2_5g" quirk
due to the not really correct compliance code / nominal signaling rate.

 drivers/net/phy/sfp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 5db841377199..2e2fad79b221 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -567,6 +567,8 @@ static const struct sfp_quirk sfp_quirks[] = {
 	SFP_QUIRK_F("Turris", "RTSFP-2.5G", sfp_fixup_rollball),
 	SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
 	SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
+
+	SFP_QUIRK_S("ZOERAX", "SFP-2.5G-T", sfp_quirk_disable_autoneg),
 };
 
 static size_t sfp_strlen(const char *str, size_t maxlen)
-- 
2.53.0

Re: [PATCH net-next] net: sfp: add quirk for ZOERAX SFP-2.5G-T

[Jakub Kicinski]

On Wed, 25 Mar 2026 17:35:58 +0100 Jan Hoffmann wrote:
> This is a 2.5G copper module which appears to be based on a Motorcomm
> YT8821 PHY. There doesn't seem to be a usable way to to access the PHY
> (I2C address 0x56 provides only read-only C22 access, and Rollball is
> also not working).
> 
> The module does not report the correct extended compliance code for
> 2.5GBase-T, and instead claims to support SONET OC-48 and Fibre Channel:
> 
>   Identifier          : 0x03 (SFP)
>   Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
>   Connector           : 0x07 (LC)
>   Transceiver codes   : 0x00 0x01 0x00 0x00 0x40 0x40 0x04 0x00 0x00
>   Transceiver type    : FC: Multimode, 50um (M5)
>   Encoding            : 0x05 (SONET Scrambled)
>   BR Nominal          : 2500MBd
> 
> Despite this, the kernel still sets 2500Base-X as interface mode based
> on the (incorrect) nominal signaling rate.
> 
> However, it is also necessary to disable auto-negotiation for the module
> to actually work. Thus, create a SFP quirk to do this.
> 
> Signed-off-by: Jan Hoffmann <jan@3e8.eu>
> ---
> Note: I'm not quite sure "sfp_quirk_disable_autoneg" is enough here, or
> if it would be appropriate to use the full "sfp_quirk_oem_2_5g" quirk
> due to the not really correct compliance code / nominal signaling rate.

I'm no SFP expert but just going by the naming I strongly suspect that
the module is the same hardware as "SFP-2.5G-T" from "FS", so keeping
quirks consistent makes sense?