maybe a quirk or the phy driver needs to be patched to give more time?
hmm, maybe. I did not share one more detail: it happens when I connect device that is faster than 1Gbit. I have some other network cards or by connecting to w1700k via 10G port (it also have rtl8621) and such issue raises and that’s it. I can wait all retries, but nothing would change
So kernel/phylink does not support > 1G ? On 1g there is no issue with same sfp?
What does ethtool say?
even when I disable autoneg and ser 1 gbit, issue appears. Only connecting to old card that only have 1Gbit seems to work normally. Odd. Tomorrow will bring more details (/sys/class/net/sfp2/statistics/*errors; ethtool; etc.)
Thanks for help Frank.
EDIT: going back to vanilla (would be not sfp2 but sfp-lan), after connecting to w1700k via 10G, on BPi-R4 I have:
Sun Oct 19 21:57:28 2025 kern.info kernel: [ 263.147530] mtk_soc_eth 15100000.ethernet sfp-lan: Link is Down
Sun Oct 19 21:57:28 2025 kern.info kernel: [ 263.153775] br-lan: port 4(sfp-lan) entered disabled state
Sun Oct 19 21:57:28 2025 daemon.notice netifd: Network device 'sfp-lan' link is down
Sun Oct 19 21:57:32 2025 kern.info kernel: [ 267.146473] sfp sfp2: module removed
Sun Oct 19 21:57:35 2025 kern.info kernel: [ 269.730498] sfp sfp2: module OEM SFP-10G-T rev A sn 202503260108 dc 250326
Sun Oct 19 21:57:35 2025 kern.info kernel: [ 269.770402] hwmon hwmon3: temp1_input not attached to any thermal zone
3: sfp-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000
link/ether e2:ae:de:4b:24:cc brd ff:ff:ff:ff:ff:ff
root@BPI-R4-NAND:~# ethtool sfp-lan
Settings for sfp-lan:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
root@BPI-R4-NAND:~# cat /sys/class/net/sfp-lan/statistics/*errors;
0
0
0
0
0
0
0
0
0
0
0
0
0
Interface is down, executing ip link set sfp-lan up does not do anything.
Can not connect via wireless or get ip address via LAN port, only UART says something, but router is not usable.
After reboot, no wireless, no error. Definitely some workaround is needed for that module, but maybe better just to change module to others.
I commented that in PR - phy-realtek: add rtl8251l, rtl8254b, rtl8261be, rtl8261n, rtl8264 and rtl8264b by balika011 · Pull Request #20450 · openwrt/openwrt · GitHub - but even on pure OpenWrt without that change, behavior is same.
tl;dr My SFP uses rtl8261, where not problematic modules uses: rtl8261N
So:
What mtk_soc_eth Expects:
* Fixed-link (no PHY)
* MDIO-connected PHYs (like MT7530)
* SFP modules — only if CONFIG_SFP=y and device tree has sfp {} node
But your RTL8261:
* Is not on MDIO
* Uses I2C only (bus 4, 0x56)
* Has non-standard ID (0xff13ff13)
* No driver support in Linux
So IIUC, it would require some hacks, edit DTS and build image for myself, edit mtk_eth_soc.c.
I just bought wrong module. Hope someone else who also make a mistake will find answer quicker.
Edit: just to ensure, it is not possible to change somehow the phy id to be detected as rtl8261n? Like spoof/trigger somehow quirk responsible for rtl8261n? Kindly ping @ericwoud
So does it have an i2c-mdio bridge built-in?
Where is this info from?
Then you can directly use C22 or C45 on it, no need for rollball. Then 0x56 is the expected address. Do you also have something on 0x50 and 0x51?
I did not have done enough research in this topic, so I tried to get some answers with few AI. In the end, they give me similar summary, that might not be correct, that’s why I’m asking expert ![]()
I added some information
- phy-realtek: add rtl8251l, rtl8254b, rtl8261be, rtl8261n, rtl8264 and rtl8264b by balika011 · Pull Request #20450 · openwrt/openwrt · GitHub (and few comments above)
- SFP module OEM SFP-10G-T based on RTL8261 will not work till dmesg reported "no PHY detected" · Issue #20294 · openwrt/openwrt · GitHub
So does it have an i2c-mdio bridge built-in?
if the value should be like:
root@BPI-R4-NAND:~# i2cdetect -y 4
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
``` than yes.
Did you pop open to see which rtl chip is inside?
If that was info from ai, never mind, it always makes stuff up when it doesn’t know.
I did not open the sfp, but form the seller I know that it is RTL8261 (not RTL8261N). Don’t think he would lie
I never have time to increase knowledge related to SFP, that’s why asked AI…
It is ether BE or N?
Or just ask a refund…
Perhaps an i2cdump of 0x56 gives some more info.
After tear down it is… Rtl8261BE. Dump 0x56 will do tomorrow and share in this issue
Thanks for advice.
EDIT: I have done dump SFP module OEM SFP-10G-T based on RTL8261 will not work till dmesg reported "no PHY detected" · Issue #20294 · openwrt/openwrt · GitHub Wondering if correct channel or I miss something?
First set the interface (eth0/1/2) up, wait some time, then dump 0x56. Then you could see more then just FF.
If it is rollball similar to the other rollball modules.
So if rollball doesn’t work, try removing the fixup that recognizes this module and sets up rollball.
You may be able to use it, without phy register access.