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