drivers/net/phy/sfp.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
TP-Link TL-SM410U modules are single-rate 2.5GBase-T RJ45 SFP modules.
The EEPROM data is lying about connector and extended cc,
reporting 25Gbps fiber.
Add fixup for these specific modules forcing RJ45 @ 2.5Gbase-T.
For reference original eeprom data dump from ethtool:
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0x00
Transceiver type : FC: Twisted Pair (TP)
Encoding : 0x01 (8B/10B)
BR, Nominal : 3100MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 0nm
Vendor name : TP-LINK
Vendor OUI : 00:00:00
Vendor PN : TL-SM410U
Vendor rev : 1.0
Option values : 0x00 0x18
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : 12154J6001608
Date code : 210611
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
drivers/net/phy/sfp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 5468bd209fab..a5bb9d569381 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -340,6 +340,12 @@ static const struct of_device_id sfp_of_match[] = {
};
MODULE_DEVICE_TABLE(of, sfp_of_match);
+static void sfp_fixup_2500baset(struct sfp *sfp)
+{
+ sfp->id.base.connector = SFF8024_CONNECTOR_RJ45;
+ sfp->id.base.extended_cc = SFF8024_ECC_2_5GBASE_T;
+}
+
static void sfp_fixup_long_startup(struct sfp *sfp)
{
sfp->module_t_start_up = T_START_UP_BAD_GPON;
@@ -503,6 +509,10 @@ static const struct sfp_quirk sfp_quirks[] = {
SFP_QUIRK_F("OEM", "RTSFP-10G", sfp_fixup_rollball_cc),
SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
+
+ // tp-link 2.5Gbase-T modules wrongly report 25Gbps fiber connector
+ // in their EEPROM
+ SFP_QUIRK_F("TP-LINK", "TL-SM410U", sfp_fixup_2500baset),
};
static size_t sfp_strlen(const char *str, size_t maxlen)
---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20240106-tplink-25gbaset-sfp-fixup-0eca2f8f7530
Sincerely,
--
Josua Mayer <josua@solid-run.com>On Sat, Jan 06, 2024 at 05:29:56PM +0100, Josua Mayer wrote: > TP-Link TL-SM410U modules are single-rate 2.5GBase-T RJ45 SFP modules. > The EEPROM data is lying about connector and extended cc, > reporting 25Gbps fiber. > > Add fixup for these specific modules forcing RJ45 @ 2.5Gbase-T. > > For reference original eeprom data dump from ethtool: > > Identifier : 0x03 (SFP) > Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) > Connector : 0x07 (LC) > Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0x00 > Transceiver type : FC: Twisted Pair (TP) > Encoding : 0x01 (8B/10B) > BR, Nominal : 3100MBd This isn't 25Gbps - it's 2.5Gbps! So what actually happens with this module without the quirk? We should end up marking it for use as a 2500base-X fibre module which should result in it working. (Please include in the commit message how it works or not without the patch.) Also, patches to netdev need to have "net" (for -rc) or "net-next" (for the next merge window) in the "[PATCH ...]" n the subject line. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Russell, Am 07.01.24 um 17:10 schrieb Russell King (Oracle): > On Sat, Jan 06, 2024 at 05:29:56PM +0100, Josua Mayer wrote: >> TP-Link TL-SM410U modules are single-rate 2.5GBase-T RJ45 SFP modules. >> The EEPROM data is lying about connector and extended cc, >> reporting 25Gbps fiber. >> >> Add fixup for these specific modules forcing RJ45 @ 2.5Gbase-T. >> >> For reference original eeprom data dump from ethtool: >> >> Identifier : 0x03 (SFP) >> Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) >> Connector : 0x07 (LC) >> Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0x00 >> Transceiver type : FC: Twisted Pair (TP) >> Encoding : 0x01 (8B/10B) >> BR, Nominal : 3100MBd > This isn't 25Gbps - it's 2.5Gbps! oh :( I misread a header-file not being careful that day ... sorry > > So what actually happens with this module without the quirk? In summary it looks like on armada-385 it is working fine except for reporting wrong port and link-mode (fiber), but on cn9130 it is not working either way. 1. On CN9130 Clearfog Base, linux v6.1.69 without this patch: Module is detected - ethtool reports a 2500 fiber, no link detected, comphy configured for 2500basex [ 51.465237] sfp sfp: module TP-LINK TL-SM410U rev 1.0 sn 12154J6000039 dc 210605 [ 51.474699] mvpp2 f2000000.ethernet eth0: switched to inband/2500base-x link mode root@localhost:~# ifconfig eth0 up [ 88.156486] mvpp2 f2000000.ethernet eth0: configuring for inband/2500base-x link mode root@localhost:~# ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 2500baseX/Full Speed: 2500Mb/s Port: FIBRE Link detected: no 2. On Armada 385 Clearfog GTR, linux 6.1.69 without this patch - but many openwrt patches: [ 54.290627] sfp sfp-0: module TP-LINK TL-SM410U rev 1.0 sn 12154J6000039 dc 210605 [ 54.300164] mvneta f1034000.ethernet eth2: switched to inband/2500base-x link mode root@OpenWrt:/# ifconfig eth2 up [ 199.689326] mvneta f1034000.ethernet eth2: configuring for inband/2500base-x link mode [ 265.892986] mvneta f1034000.ethernet eth2: Link is Up - 2.5Gbps/Full - flow control rx/tx root@OpenWrt:/# ethtool eth2 Settings for eth2: Supported ports: [ FIBRE ] Supported link modes: 2500baseX/Full Speed: 2500Mb/s Port: FIBRE Link detected: yes I would have yet to try the exact same sources between the two platforms - but it seems the problem addressed by my submitted patch is cosmetic. > We should > end up marking it for use as a 2500base-X fibre module Yes > which should > result in it working. conceptually - if the problem was purely cosmetic it will not be worth adding a fixup? > > (Please include in the commit message how it works or not without the > patch.) okay - I will outline it here first before potential v2 or dropping the patch: > Also, patches to netdev need to have "net" (for -rc) or "net-next" > (for the next merge window) in the "[PATCH ...]" n the subject line. Ack. > > Thanks.
© 2016 - 2025 Red Hat, Inc.