Yep, maybe use pcs->ops->supports_inband(interface) or something.
Check state->link from phylink_mac_pcs_get_state() I guess…
1 Like
thanks eric very much for this info…noticed the pcs driver (CONFIG_PCS_MTK_USXGMII) was not enabled (though i had looked for it already, but seems not)…
root@bpi-r4-v11:~# ip link set eth2 up
[ 20.646238] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
root@bpi-r4-v11:~# [ 20.751857] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 10Gbps/Full - flow control off
root@bpi-r4-v11:~# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseSR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10000baseSR/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
it seems i fall into this (which not nice without error-message btw):
will make some basic tests with my other r4 and then continue work on RSS/LRO
basicly it works this is speedtest without RSS/LRO:
root@bpi-r4-v11:~# iperf3 -bidir -c 192.168.90.10
Connecting to host 192.168.90.10, port 5201
[ 5] local 192.168.90.11 port 43602 connected to 192.168.90.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 541 MBytes 4.54 Gbits/sec 38 706 KBytes
[ 5] 1.00-2.00 sec 539 MBytes 4.52 Gbits/sec 11 936 KBytes
[ 5] 2.00-3.00 sec 541 MBytes 4.54 Gbits/sec 53 867 KBytes
[ 5] 3.00-4.00 sec 541 MBytes 4.54 Gbits/sec 30 1015 KBytes
[ 5] 4.00-5.00 sec 541 MBytes 4.54 Gbits/sec 43 943 KBytes
[ 5] 5.00-6.00 sec 540 MBytes 4.53 Gbits/sec 33 813 KBytes
[ 5] 6.00-7.00 sec 542 MBytes 4.55 Gbits/sec 36 731 KBytes
[ 5] 7.00-8.00 sec 540 MBytes 4.53 Gbits/sec 28 977 KBytes
[ 5] 8.00-9.00 sec 540 MBytes 4.53 Gbits/sec 45 865 KBytes
[ 5] 9.00-10.00 sec 540 MBytes 4.53 Gbits/sec 66 764 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.28 GBytes 4.54 Gbits/sec 383 sender
[ 5] 0.00-10.00 sec 5.28 GBytes 4.53 Gbits/sec receiver
iperf Done.
i guess retransmitts are caused by cpu overload due to missing rss/lro
with RSS+LRO patches link takes ~1min to get up and after it is up throughput is same (but not enabled with ethtool yet) - so not working yet
Thanks for sharing, I also needed that for my defconfig.
I can’t start MIKROTIK S+RJ10. It seems to me that he is not receiving power.
Can I force power on SFP1 SFP2 is it controlled by GPIO82-83?
root@OpenWrt:/sys/devices/platform/1001f000.pinctrl/gpio/gpiochip428/power# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 428-511, parent: platform/1001f000.pinctrl, pinctrl_moore:
gpio-428 ( |tx-disable ) in lo
gpio-430 ( |los ) in hi IRQ
gpio-432 ( |asm_sel ) in hi
gpio-433 ( |pca9545_rst ) in hi
gpio-441 ( |reset ) in lo IRQ ACTIVE LOW
gpio-442 ( |wps ) in hi IRQ ACTIVE LOW
gpio-482 ( |los ) in hi IRQ
gpio-491 ( |bpi-r4:pio:blue ) out lo
gpio-498 ( |tx-disable ) in lo
gpio-507 ( |bpi-r4:pio:green ) out lo
gpio-510 ( |mod-def0 ) in hi IRQ ACTIVE LOW
gpio-511 ( |mod-def0 ) in hi IRQ ACTIVE LOW
Here I see that both GPIOs (mod-def0) are occupied for control. Is it possible to free them?
These are bound by dts,but afaik they are needed by driver. You can assign different gpio (e.g. from 26pin header) to the moddef0.
Are you sure the moddef-pins are used for powering your sfp? The 3v3 is fixed passed to the sfp.
Can you read the i2c of the sfp? What do you see with ethtool? I guess you need a quirk (e.g. for disabling the tx-disable or adding more modes) instead of changing the moddef0 gpio.
What says dmesg? Can you read sfp data with ethtool -m?
Nothing happens when I install the module.
According to the diagram, power appears on the module after the mod-def0 signal changes to LO. The module needs power to switch this signal.
Above you can see its installed state and it is HI.
I have to run this module every time, bypassing Q12. I need a power boost on the module for it to start. After this, the module changes mod-def0 to LO and the BPI circuit continues to power it.
root@OpenWrt:~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 428-511, parent: platform/1001f000.pinctrl, pinctrl_moore:
gpio-428 ( |tx-disable ) out lo
gpio-430 ( |los ) in lo IRQ
gpio-432 ( |asm_sel ) in hi
gpio-433 ( |pca9545_rst ) in hi
gpio-441 ( |reset ) in lo IRQ ACTIVE LOW
gpio-442 ( |wps ) in hi IRQ ACTIVE LOW
gpio-482 ( |los ) in hi IRQ
gpio-491 ( |bpi-r4:pio:blue ) out lo
gpio-498 ( |tx-disable ) out lo
gpio-507 ( |bpi-r4:pio:green ) out lo
gpio-510 ( |mod-def0 ) in lo IRQ ACTIVE LOW
gpio-511 ( |mod-def0 ) in lo IRQ ACTIVE LOW
A vicious circle, the module cannot change the mod-def0 signal from HI to LO because there is no power. BPI-R4 cannot supply power because mod-def0 HI.
[ 86.268015] sfp sfp@1: SM: enter empty:up:down event insert
[ 86.273596] sfp sfp@1: SM: exit probe:up:down
[ 86.603175] sfp sfp@1: SM: enter probe:up:down event timeout
[ 86.619969] sfp sfp@1: module MikroTik S+RJ10 rev 2.16 sn XXXXXXXX dc 210425
[ 86.629444] sfp sfp@1: sfp: support mode 00,00000400,00006040
[ 86.635194] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/10gbase-kr with support 00,00000400,000060c0
[ 86.659622] sfp sfp@1: Module switched to 1.5W power level
[ 86.665102] sfp sfp@1: SM: exit waitpwr:up:down
[ 86.987178] sfp sfp@1: SM: enter waitpwr:up:down event timeout
[ 86.993006] sfp sfp@1: tx disable 1 -> 0
[ 86.996943] sfp sfp@1: SM: exit present:up:wait
[ 87.051174] sfp sfp@1: SM: enter present:up:wait event timeout
[ 87.056998] sfp sfp@1: probing phy device through the [MDIO_I2C_NONE] protocol
[ 87.064215] sfp sfp@1: SM: exit present:up:link_up
[ 87.095191] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 10Gbps/Full - flow control off
[ 87.114504] br-lan: port 4(eth1) entered blocking state
[ 87.119721] br-lan: port 4(eth1) entered forwarding state
[ 91.771718] sfp sfp@0: SM: enter empty:up:down event insert
[ 91.777297] sfp sfp@0: SM: exit probe:up:down
[ 92.107173] sfp sfp@0: SM: enter probe:up:down event timeout
[ 92.123970] sfp sfp@0: module MikroTik S+RJ10 rev 2.16 sn XXXXXXXXX dc 210319
[ 92.133446] sfp sfp@0: sfp: support mode 00,00000400,00006040
[ 92.139195] mtk_soc_eth 15100000.ethernet eth2: requesting link mode inband/10gbase-kr with support 00,00000400,000060c0
[ 92.163627] sfp sfp@0: Module switched to 1.5W power level
[ 92.169105] sfp sfp@0: SM: exit waitpwr:up:down
[ 92.491175] sfp sfp@0: SM: enter waitpwr:up:down event timeout
[ 92.496998] sfp sfp@0: tx disable 1 -> 0
[ 92.500929] sfp sfp@0: SM: exit present:up:wait
[ 92.555173] sfp sfp@0: SM: enter present:up:wait event timeout
[ 92.560996] sfp sfp@0: probing phy device through the [MDIO_I2C_NONE] protocol
[ 92.568211] sfp sfp@0: SM: exit present:up:link_up
[ 92.599187] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 10Gbps/Full - flow control off
[ 92.618504] br-wan: port 2(eth2) entered blocking state
[ 92.623721] br-wan: port 2(eth2) entered forwarding state
[ 117.266056] TCP: br-lan: Driver has suspect GRO implementation, TCP performance may be compromised.
So I would like to return to my S+RJ10 modules. I found out that they are built on Marvell 88X3310P PHY. I even enabled Marvell 10G PHY support when building Openwrt. But I still don’t see this PHY. I know that Aquantia AQR113C has already been added to the assembly. Maybe someone has already done this. Are there any comments on this?
I’m using the build eladwf/openwrt/tree/bpi_r4 I also set irqbalance to balance interrupts on different processor cores from ETH1-2. I don’t see that RSS balances the queues.
You might need to write some quirk for your module. net: sfp: add support for a couple of copper multi-rate modules · torvalds/linux@5859a99 · GitHub
Yes, I’m glad that there might be a solution, but I can’t even imagine how to use it.
The modules work, but I have no idea in what serdes mode. I can connect 100mb-10G but if I connect below 10G I get queue overflow and the transfer speed is limited to 1G. phylink is always 10G. I have the impression that phy does not inform you that you need to slow down, does not send pauses.
I have to enable flow-control on my switch. Although this is not correct, it helps me. It turns out that the queue is controlled by my smart switch.
I got the BPI-R4 now and also have a LuLeey XPON SFP module (LL-XS2510). It was detected out of the box by the OpenWrt version the R4 shipped with. Unfortunately, I can’t test the uplink yet, because my ISP has yet to install the fiber to the building.
Let me know if there is any command I should run with the module or some other information you need to add input to this thread.
I tried but nothing worked with the quirk. The module simply stops starting. Until I give him the command to force MDIX initialization.
I tell him mii-tool -r eth2 and he comes to life.
I stopped fighting with S+RJ10.
I bought XICOM and they are on phy Aquantia AQR113C
They are 10-15 degrees cooler and seem to be fully supported by openwrt.
But there is one peculiarity: in 2024 they changed the name of their modules for DDMI.
In 2023 and earlier they were called
OEM SFP+-T
Now starting in 2024 They are called
OEM SFP-10G-T
Old 2023 and earlier modules did not detect their phy, but this can be fixed.
You just need to add the name of the old module before building. Maybe someone will add this fix to the main build in the future.
[ 19.598863] sfp sfp1: module OEM SFP-10G-T rev 1 sn CI2401130569 dc 240112
[ 19.619594] sfp sfp2: module OEM SFP+-T rev 1 sn C2312180155 dc 231218
[ 19.640098] hwmon hwmon2: temp1_input not attached to any thermal zone
[ 19.666445] hwmon hwmon3: temp1_input not attached to any thermal zone
[ 20.239281] mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead.
[ 20.251394] mtdblock: MTD device 'bl2' is NAND, please consider using UBI block devices instead.
[ 20.268447] md: md0 stopped.
[ 20.307591] md0: detected capacity change from 0 to 1937388544
[ 21.864184] mtk_soc_eth 15100000.ethernet eth0: Link is Down
[ 21.879282] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[ 21.887414] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[ 21.889843] mt7530-mmio 15020000.switch lan1: configuring for phy/internal link mode
[ 21.904051] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 21.911104] br-lan: port 1(lan1) entered blocking state
[ 21.916362] br-lan: port 1(lan1) entered disabled state
[ 21.921827] device lan1 entered promiscuous mode
[ 21.930157] mt7530-mmio 15020000.switch lan2: configuring for phy/internal link mode
[ 21.938625] br-lan: port 2(lan2) entered blocking state
[ 21.943863] br-lan: port 2(lan2) entered disabled state
[ 21.949339] device lan2 entered promiscuous mode
[ 21.956305] mt7530-mmio 15020000.switch lan3: configuring for phy/internal link mode
[ 21.964639] br-lan: port 3(lan3) entered blocking state
[ 21.969912] br-lan: port 3(lan3) entered disabled state
[ 21.975367] device lan3 entered promiscuous mode
[ 21.982319] mt7530-mmio 15020000.switch wan: configuring for phy/internal link mode
[ 21.990730] br-lan: port 4(wan) entered blocking state
[ 21.995876] br-lan: port 4(wan) entered disabled state
[ 22.001567] device wan entered promiscuous mode
[ 22.007351] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/10gbase-r link mode
[ 22.030559] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
[ 23.549413] EXT4-fs (md0): recovery complete
[ 23.553708] EXT4-fs (md0): mounted filesystem with ordered data mode. Quota mode: disabled.
[ 48.129729] hwmon hwmon4: temp1_input not attached to any thermal zone
[ 48.909538] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [Aquantia AQR113C] (irq=POLL)
[ 49.919770] hwmon hwmon5: temp1_input not attached to any thermal zone
[ 50.699779] mtk_soc_eth 15100000.ethernet eth1: PHY [i2c:sfp2:11] driver [Aquantia AQR113C] (irq=POLL)
[ 56.561973] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control rx/tx
[ 56.570624] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 57.281984] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 2.5Gbps/Full - flow control rx/tx
[ 57.290634] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
finally got flow control working on 2.5G and now he understands that this is not 10G
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
1000baseKX/Full
10000baseKX4/Full
10000baseKR/Full
2500baseT/Full
5000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
1000baseKX/Full
10000baseKX4/Full
10000baseKR/Full
2500baseT/Full
5000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 17
Transceiver: external
MDI-X: Unknown
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
UPD: I changed the name on the module now I don’t need the quirk. Old name
OEM+-T
I changed its name to
OEM-10G-T
and now it works normally.
[ 2627.204270] sfp sfp1: module OEM SFP-10G-T rev 1 sn C2312180155 dc 231218
[ 2627.244145] hwmon hwmon2: temp1_input not attached to any thermal zone
[ 2653.565434] hwmon hwmon3: temp1_input not attached to any thermal zone
[ 2654.355229] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [Aquantia AQR113C] (irq=POLL)
[ 2683.518830] sfp sfp1: module removed
All information is in this post. https://forum.banana-pi.org/t/i2csfp-sfp-debugging-via-i2c/17761?u=vasya
Here is the executable file you can run directly on the BPI-R4
i2csfp.tar.gz (298,4 КБ)
root@OpenWrt:/tmp$ ./i2csfp /dev/i2c-3 eepromfix -V OEM -N SFP-10G-T
Hi, Can you share i2cdetect and i2cdump result of your stick? I also have a aqr113c stick but not sure if it is supported by rollball protocol.
root@OpenWrt:~# i2cdetect -y 3
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 -- -- -- -- -- -- --
root@OpenWrt:~# i2cdump -y 3 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 03 04 07 10 00 00 00 00 00 00 00 06 67 00 00 00 ????.......?g...
10: 08 02 00 1e 4f 45 4d 20 20 20 20 20 20 20 20 20 ??.?OEM
20: 20 20 20 20 00 00 00 00 53 46 50 2b 2d 54 20 20 ....SFP+-T
30: 20 20 20 20 20 20 20 20 31 20 20 20 03 52 00 ef 1 ?R.?
40: 00 1a 00 00 43 32 33 31 32 31 38 30 31 35 35 20 .?..C2312180155
50: 20 20 20 20 32 33 31 32 31 38 20 20 68 f0 03 c5 231218 h???
60: 9f 00 11 8b 92 9a 79 ea 33 1c 5b 64 fd 3f 03 53 ?.????y?3?[d???S
70: 31 e2 d9 00 00 00 00 00 00 00 00 00 49 8a 37 2e 1??.........I?7.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
root@OpenWrt:~# i2cdump -y 3 0x51
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 5f 00 ce 00 5a 00 d3 00 8c a0 75 30 88 b8 79 18 _.?.Z.?.??u0??y?
10: 1d 4c 01 f4 19 64 03 e8 4d f0 06 30 3d e8 06 f2 ?L???d??M??0=???
20: 2b d4 00 c7 27 10 00 df 00 00 00 00 00 00 00 00 +?.?'?.?........
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00 ....??......?...
50: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 f1 ?...?...?......?
60: 1d f3 82 b3 0b b8 13 88 00 00 00 00 00 00 02 00 ????????......?.
70: 00 40 00 00 00 40 00 00 00 00 00 ff ff ff ff 00 .@...@..........
80: 43 4f 55 49 41 38 4e 43 41 41 31 30 2d 32 34 31 COUIA8NCAA10-241
90: 35 2d 30 33 56 30 33 20 01 00 46 00 00 00 00 c6 5-03V03 ?.F....?
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa aa ..............??
c0: 53 46 50 2d 31 30 47 2d 53 52 20 20 20 20 20 20 SFP-10G-SR
d0: 20 20 20 20 33 32 00 00 00 00 00 00 00 00 00 35 32.........5
e0: 1e 28 2e 2e 31 34 29 36 00 00 00 00 00 00 00 00 ?(..14)6........
f0: 00 00 00 00 00 66 00 00 ff ff ff ff 00 00 00 00 .....f..........
root@OpenWrt:~# i2cdump -y 3 0x56
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 20 40 00 02 31 c3 1c 12 60 31 00 9a e0 00 00 09 @.?1???`1.??..?
10: b3 01 00 00 00 00 40 fc 00 00 00 00 31 c3 1c 12 ??....@?....1???
20: 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 00 ...........?....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
root@OpenWrt:~#
Thanks, seems my stick doesn’t support rollball protocol.
This does not depend on the module, if phy AQR113C everything should work. Repeat the steps that I described above, add your module to the assembly. My old
XICOM OEM SFP+-T
module also did not work with rollball until I added it.
I’m using the official openwrt. GitHub - openwrt/openwrt: This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
[ 104.599519] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [Aquantia AQR113C] (irq=POLL)
[ 2096.301865] sfp sfp1: module removed
Removing a module no longer causes a bunch of errors.
I’m having also a BPI R4 issue with SFP, but kinda specific:
I’m using 2.5G RJ45 SFP modules, as they are less power-hungry compared to SFP+ modules. On Openwrt master based on kernel 6.1, everything is fine. But, as I saw @dangowrt implemented many tricks in later kernel versions, I thought moving to 6.6 (the experimental kernel) was a good thing. Unfortunately, this doesn’t seem to be the case:
[ 17.713196] sfp sfp2: module OEM SFP-2G5 rev 1.0 sn 2G522112324218 dc 220801
[ 17.722600] mtk_soc_eth 15100000.ethernet eth1: unsupported SFP module: no common interface modes
[ 17.742752] sfp sfp1: module OEM SFP-2G5 rev 1.0 sn 2G522112324218 dc 220801
[ 17.752156] mtk_soc_eth 15100000.ethernet eth2: unsupported SFP module: no common interface modes
and the SFP modules no longer work 
using 6.1 kernel, there is no issue:
[ 17.390409] sfp sfp1: module OEM SFP-2G5 rev 1.0 sn 2G522112324218 dc 220801
[ 17.399828] mtk_soc_eth 15100000.ethernet eth2: switched to inband/2500base-x link mode
[ 17.419104] sfp sfp2: module OEM SFP-2G5 rev 1.0 sn 2G522112324218 dc 220801
[ 17.428526] mtk_soc_eth 15100000.ethernet eth1: switched to inband/2500base-x link mode
Has anyone heard of something like this?
I compiled the vanilla openwrt 6.6 kernel with debug and driver debug options, and booted it with “debug ignore_loglevel”. The result is here: verbose_dmesg.txt (259,4 KB)
Anybody who sees what’s going wrong on 6.6 kernels?
I know on R3, inband does not work at 2500base-x. I’m not sure if this is the same for R4.
If so, then it needs to be disabled, using some patch. There are different versions of patches for this problem. So you may want to check if appropriate patches are present in the fork you are using, if R4 also needs inband disabled…