SFP OEM SFP-2.5G-T kernel PHY?

Banana Pi Router design
126

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.

127

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

128

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).

129

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.

130

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.

131

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.

132

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.

133

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.

134

Another usefull addition upstream:

https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

HWMON support.

2 Likes