It depends what os you are using. Openwrt may have all commits build in.
I am planning to use Debian or Ubuntu so I am more interested in which kernel release I will need to wait for before bothering to use them - or I might just patch up the kernel module until it hits a release
It is in 6.10
Fixups for vendor OEM are not mainlined, as we do not know beforehand which phy chip is on the module, only looking at vendor/product strings.
Also no commit mainline for handling 2500base-x inband negotiation for mediatek mac.
You will find these commits in Frank and my linux forks for debian/ubuntu and archlinuxarm.
Thanks, at this stage I will be happy if it just connects. Don’t need autonegotiation etc to get the basic functionality working.
Where do I find your Linux fork?
My 6.9 kernel should work
Contains the 2g5 phylink fix
If your module is rollball, you can also edit eeprom to match existing quirk or fixup. I have a tool for it called i2csfp.The one from bpi store was reported as rollball by a user on the forum
The modules turned up. Shows up as “SFP-2.5G-T-R-RM” in the kernel boot log.
I will try the kernels later in the week.
It looks like I’ve added that to the bpir-rolling-stable branch:
https://github.com/ericwoud/linux/commit/76d617875f2a4849bc2f3bf03358ff7f23fda339
Thanks I will try that out.
I have a SFP-2.5G-T-R-RM module and it’s working properly on mainline OpenWrt, except that after a soft reboot it would sometimes lose link unless reseated in the SFP cage.
Looking in build root of OpenWrt, I couldn’t find any patches for the SFP-2.5G-T and its variants. There is only a single line from ./build-dir/…/linux/drivers/net/phy/sfp.c:
SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g)
I wonder if your fix would resolve my issue, or is it completely unrelated? If it’s worth trying, could someone make a patch to drop into /target/linux/...? I imagine that outright replacing sfp.c in build-dir with a fixed version would not be the right way to do it.
Does it help to do:
ip link set eth1 down
ip link set eth1 up
When you lost the link?
Otherwisre I do not know which quirk/fixup/patch applies to your module in the openwrt image you use.
ethtool -m eth1
Will help you to identify the string that is matched in the fixup/quirk.
My tool can let you change it on the module, to match the code in sfp.c
Yes, setting it down and up helps too (eth2 in my case).
The module name shows up in dmesg:
[ 12.490570] sfp sfp1: module OEM SFP-2.5G-T-R-RM rev 1.0 sn 2405070065 dc 240507
But running ethtool -m eth2 returns a bunch of hex data:
root@router:~# ethtool -m eth2
Offset Values
------ ------
0x0000: 03 04 07 00 01 00 00 00 00 02 00 05 19 00 00 00
0x0010: 1e 14 00 00 4f 45 4d 20 20 20 20 20 20 20 20 20
0x0020: 20 20 20 20 00 00 00 00 53 46 50 2d 32 2e 35 47
0x0030: 2d 54 2d 52 2d 52 4d 20 31 2e 30 20 03 52 00 c4
0x0040: 00 1a 00 00 32 34 30 35 30 37 30 30 36 35 20 20
0x0050: 20 20 20 20 32 34 30 35 30 37 20 20 68 f0 01 a2
0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 5f 00 ce 00 5a 00 d3 00 8c a0 75 30 88 b8 79 18
0x0110: 1d 4c 01 f4 19 64 03 e8 4d f0 06 30 3d e8 06 f2
0x0120: 2b d4 00 c7 27 10 00 df 00 00 00 00 00 00 00 00
0x0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0140: 00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00
0x0150: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 f1
0x0160: 2d 1f 84 df 0b b8 13 88 0f a0 ff ff ff ff 80 ff
0x0170: 00 00 ff ff 00 00 ff ff 02 ff ff ff ff ff ff 00
0x0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I can only assume there is no patch/quirk applied, since I didn’t find any references to SFP-2.5G-T-R-RM in source files for my build (which is a near-stock snapshot).
As for editing the EEPROM, that could be one way to try fixing the issue. But I’d rather approach it from the kernel side to let the fix be eventually pushed to OpenWrt so that everything works out of the box for more users.
You could edit instead:
To match the module, just to try out first.
You will have more info on what might be going wrong (mac setup) when you execute this first, before the first time setting the link up.
echo "file drivers/net/ethernet/ti/* +p" > /sys/kernel/debug/dynamic_debug/control
But, if openwrt has dynamic debug enabled, I don’t know.
I’ve added SFP_QUIRK_M(“OEM”, “SFP-2.5G-T-R-RM”, sfp_quirk_oem_2_5g) to sfp.c to match the module name, but the issue persists. Sometimes setting eth2 down and up helps, sometimes not, just as you described in one of the earlier posts.
Kernel log didn’t show any differences between successful and failed attempts of setting link up (with dynamic debug enabled on drivers/net/*). It’s always like this:
[ 5057.945299] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/2500base-x link mode
[ 5057.953717] mtk_soc_eth 15100000.ethernet eth2: major config 2500base-x
[ 5057.960330] mtk_soc_eth 15100000.ethernet eth2: phylink_mac_config: mode=inband/2500base-x/none adv=00,00000000,00008000,0000e400>
[ 5057.976190] sfp sfp1: SM: enter present:down:down event dev_up
[ 5057.982017] sfp sfp1: tx disable 1 -> 0
[ 5057.985888] sfp sfp1: SM: exit present:up:wait
[ 5058.036171] sfp sfp1: SM: enter present:up:wait event timeout
[ 5058.041933] sfp sfp1: SM: exit present:up:wait_los
[ 5061.674933] sfp sfp1: los 1 -> 0
[ 5061.678180] sfp sfp1: SM: enter present:up:wait_los event los_low
[ 5061.684273] sfp sfp1: SM: exit present:up:link_up
[ 5061.686562] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 2.5Gbps/Full - flow control rx
I’d like to try your patch set next. Would you mind pointing out where I could find the necessary changes? I’m kinda lost between multiple branches of your repo, unrelated SFP modules and gist snippets in this thread.
My patches for rtl8221b are mainlined
Do not know if they are included in the openwrt you are using.
So only need a fixup , not quirk, to have my patches active for your module, if not already there.
Thank you. I only had to add the fixup, the rest of the patches were already there. I have also confirmed the PHY is matched to one from Realtek (RTL8221B-VB-CG). However, the module was no longer working.
[ 1263.978037] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/sgmii link mode
[ 1263.985986] mtk_soc_eth 15100000.ethernet eth2: major config sgmii
[ 1263.992168] mtk_soc_eth 15100000.ethernet eth2: phylink_mac_config: mode=inband/sgmii/none adv=00,00000000,00000000,000060ef pause=01
[ 1264.007331] sfp sfp1: SM: enter present:down:down event dev_up
[ 1264.013165] sfp sfp1: tx disable 1 -> 0
[ 1264.017019] sfp sfp1: SM: exit present:up:wait
[ 1267.731616] sfp sfp1: los 1 -> 0
[ 1267.734861] sfp sfp1: SM: enter present:up:wait event los_low
[ 1267.740605] sfp sfp1: SM: exit present:up:wait
[ 1289.183300] sfp sfp1: SM: enter present:up:wait event timeout
[ 1289.189871] mdio_bus i2c:sfp1: probed
[ 1289.896408] mtk_soc_eth 15100000.ethernet eth2: interface 2 (mii) rate match none supports 0-3,6-7,13-14
[ 1289.906040] mtk_soc_eth 15100000.ethernet eth2: interface 3 (gmii) rate match none supports 0-3,5-7,13-14
[ 1289.915692] mtk_soc_eth 15100000.ethernet eth2: interface 4 (sgmii) rate match none supports 0-3,5-7,13-14
[ 1289.925428] mtk_soc_eth 15100000.ethernet eth2: interface 22 (1000base-x) rate match none supports 5-7,13-14
[ 1289.935331] mtk_soc_eth 15100000.ethernet eth2: interface 23 (2500base-x) rate match none supports 6-7,13-14,47
[ 1289.945538] mtk_soc_eth 15100000.ethernet eth2: interface 29 (usxgmii) rate match none supports 0-3,5-7,13-14,47
[ 1289.955798] mtk_soc_eth 15100000.ethernet eth2: requesting link mode inband/sgmii with support 00,00000000,00008000,000060ef
[ 1290.043974] sfp sfp1: sfp_add_phy failed: -EOPNOTSUPP
[ 1290.049036] sfp sfp1: SM: exit present:up:fail
[ 1290.053499] sfp sfp1: los 0 -> 1
[ 1290.056725] sfp sfp1: SM: enter present:up:fail event los_high
[ 1290.062551] sfp sfp1: SM: exit present:up:fail
OpenWrt has a bunch of patches that change realtek.c. I looked into one that stood out to me to check if it broke compatibility with your code: generic: disable SGMII in-band AN for RealTek 2.5G PHYs. But reverting it didn’t help. Hopefully, something else can be done on your or OpenWrt’s end.
Another usefull addition upstream:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
HWMON support.
2 Likes
I moved some disscussion here:
Since kernel 6.14:
For when a phy attaches it is fixed it does not need any patches. Inband capabilities are examined on both mac and phy and sorted out.
I’m not so sure when a sfp module is inserted and phy not recognized. It is the treated as optical. Then the mac may still be setup with inband enabled perhaps… But I did not test or look in to that yet. So still may need to set autoneg off with ethtool in this case. But ideally this should also respect mac inband capabilities. But anyway, I haven’t really checked out this part yet. Perhapse it is ok, perhapse not.
Edit: Looking at the code, it should also be ok, should test this without the quirk
SFP_QUIRK_M(“OEM”, “SFP-2.5G-T”, sfp_quirk_oem_2_5g),
So any module that uses 2500base-x that does not match these strings. But does have the eeprom extended_cc byte set to SFF8024_ECC_2_5GBASE_T (0x1e) It should then work without any patch.
They should not need the negotiation switched off manually or by a quirk.
Edit 2: some of the modules also do not have the extended_cc field set set and need a quirk anyway, for setting the correct interface mode. Can check with i2cdump address 0x50 the byte at offset 36 (0x24). Some have this byte set to 0. For a module that is fixed at 2500base-x (on the cage side) this should be set to 0x1e.
See for example:
It is 00.