[RFC net-next] net: sfp: add quirk for OEM SFP-2.5G-T-C

[RFC net-next] net: sfp: add quirk for OEM SFP-2.5G-T-C

[David Mestre]

The OEM SFP-2.5G-T-C module needs the same fixed 2500BASE-X host link
as the existing OEM SFP-2.5G-T entry. On a ZBT Z8803BE (MT7988),
the module has no carrier with in-band autonegotiation enabled.
Forcing 2500 Mbit/s, full duplex and autonegotiation off restores
the link.

The existing OEM SFP-2.5G-T entry requires an exact part-name match,
so it does not match the -C variant. Reuse its quirk for the exact
additional part name.

Signed-off-by: David Mestre <dev@davidmestre.net>
---
  drivers/net/phy/sfp.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 85e57a1..ef87687 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -631,6 +631,7 @@ static const struct sfp_quirk sfp_quirks[] = {
  
  	SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
  	SFP_QUIRK_S("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
+	SFP_QUIRK_S("OEM", "SFP-2.5G-T-C", sfp_quirk_oem_2_5g),
  	SFP_QUIRK_S("OEM", "SFP-2.5G-BX10-D", sfp_quirk_2500basex),
  	SFP_QUIRK_S("OEM", "SFP-2.5G-BX10-U", sfp_quirk_2500basex),
  	SFP_QUIRK_S("OEM", "SFP-2.5G-LH03-B", sfp_quirk_2500basex),
base-commit: 734bef548a96e8774d6eef5dfa2026c6edc4e80b
-- 
2.56.0.windows.1

Re: [RFC net-next] net: sfp: add quirk for OEM SFP-2.5G-T-C

[Andrew Lunn]

On Fri, Oct 23, 2026 at 07:49:29PM +0200, David Mestre wrote:
> The OEM SFP-2.5G-T-C module needs the same fixed 2500BASE-X host link
> as the existing OEM SFP-2.5G-T entry. On a ZBT Z8803BE (MT7988),
> the module has no carrier with in-band autonegotiation enabled.
> Forcing 2500 Mbit/s, full duplex and autonegotiation off restores
> the link.
> 
> The existing OEM SFP-2.5G-T entry requires an exact part-name match,
> so it does not match the -C variant. Reuse its quirk for the exact
> additional part name.
> 
> Signed-off-by: David Mestre <dev@davidmestre.net>

This is something which could go via net, rather than net-next.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew