drivers/net/phy/sfp.c | 2 ++ 1 file changed, 2 insertions(+)
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.0On 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?
On 2026-03-28 at 04:50, Jakub Kicinski wrote:
> 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?
Based on commit e27aca3760c0 ("net: sfp: enhance quirk for Fibrestore
2.5G copper SFP module"), the FS module uses an RTL8221B PHY, so it is
different hardware. And it also supports the Rollball protocol for PHY
access, unlike this Zoerax module.
From the existing quirks, the only valid alternative I see for the
Zoerax module would be "sfp_quirk_oem_2_5g" (which also sets the
additional bits for 2500Base-T link mode and explicitly enables
2500Base-X interface mode). But as that is not strictly necessary for
making this particular module work, I am unsure if using this quirk
would be appropriate.
Thanks,
Jan
On Sat, Mar 28, 2026 at 09:02:34PM +0100, Jan Hoffmann wrote:
> On 2026-03-28 at 04:50, Jakub Kicinski wrote:
> > 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?
> Based on commit e27aca3760c0 ("net: sfp: enhance quirk for Fibrestore 2.5G
> copper SFP module"), the FS module uses an RTL8221B PHY, so it is different
> hardware. And it also supports the Rollball protocol for PHY access, unlike
> this Zoerax module.
>
> From the existing quirks, the only valid alternative I see for the Zoerax
> module would be "sfp_quirk_oem_2_5g" (which also sets the additional bits
> for 2500Base-T link mode and explicitly enables 2500Base-X interface mode).
> But as that is not strictly necessary for making this particular module
> work, I am unsure if using this quirk would be appropriate.
See commit 50e96acbe11667b6fe9d99e1348c6c224b2f11dd which added this
function. This was for an OEM SFP-2.5G-T where the PHY was similarly
inaccessible, can only run at 2500base-X without inband and offers
2500Base-T connectivity.
This is basically the same as your Zoerax module.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
© 2016 - 2026 Red Hat, Inc.