[BPI-R4] and SFP

tbh i dont think that caused an issue but ill try openwrt forum

Then what else changed?

not sure tbh, my optical SFP works fine, just the copper one

@ericwoud : to be sure it’s not the modules but truly a software problem: I borrowed from another switch (I returned those, it was just for this experiment) another SFP SR RJ45 trainsciver and did the eeprom dump, do you also see the eeprom problem? or is it working fine here, it’s simply because I do not have proper phy drivers installed (no clue what they are in the first place)

root@APBureau4:~# i2cdump -y 4 0x50
     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 44 65 6c 6f 63 6b 20 20 20 20 20 20    ??.?Delock
20: 20 20 20 20 00 00 00 00 38 36 34 36 30 20 20 20        ....86460
30: 20 20 20 20 20 20 20 20 31 20 20 20 03 52 00 93            1   ?R.?
40: 00 1a 00 00 38 36 34 36 30 32 32 34 39 33 39 39    .?..864602249399
50: 20 20 20 20 32 32 31 31 32 38 20 20 68 f0 03 e3        221128  h???
60: 9f 00 11 46 22 5e c3 2e 6d 0e d2 32 ff 11 d1 00    ?.?F"^?.m??2.??.
70: 1c 6c bb 00 00 00 00 00 00 00 00 00 ee 55 16 d0    ?l?.........?U??
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@APBureau4:~# i2cdump -y 4 0x51
     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 45 76 06 f2    ?L???d??M??0Ev??
20: 3d e8 00 c7 31 2d 00 fb 00 00 00 00 00 00 00 00    =?.?1-.?........
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 f0    ?...?...?......?
60: 2f f4 82 be 00 00 00 00 00 00 00 00 00 00 82 00    /???..........?.
70: 05 40 00 00 05 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@APBureau4:~# i2cdump -y 4 0x56
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
root@APBureau4:~# 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 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --

EDIT added i2cdetect output, apparently forgot to C/P it

i have the exact same thing happening

root@bpi:~# i2cdump -y 4 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 06 00 03 67 00 00 00    ????.....?.?g...
10: 1e 1e 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 2d 31 30 47 2d        ....SFP-10G-
30: 54 20 20 20 20 20 20 20 42 20 20 20 03 52 00 7f    T       B   ?R.?
40: 00 1a 00 00 32 34 30 38 32 32 30 30 39 35 20 20    .?..2408220095
50: 20 20 20 20 32 34 30 38 32 32 20 20 68 f0 03 a7        240822  h???
60: 00 00 11 f7 8a 14 52 c1 32 db a6 5e 61 20 6b 63    ..????R?2??^a kc
70: bf 1b 53 00 00 00 00 00 00 00 00 00 c2 03 15 b0    ??S.........????
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@bpi:~# i2cdump -y 4 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: 16 00 83 27 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: 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 ff ff ff ff 00 00 00 00    ................
root@bpi:~# i2cdump -y 4 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: a0 XX 31 XX 60 XX e0 XX b3 XX 00 XX 00 XX 31 XX    ?X1X`X?X?X.X.X1X
10: 00 XX 00 XX 00 XX 00 XX 00 XX 00 XX 00 XX 00 XX    .X.X.X.X.X.X.X.X
20: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
30: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
40: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
50: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
60: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
70: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
80: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
90: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
a0: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
b0: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
c0: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
d0: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
e0: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
f0: ff XX ff XX ff XX ff XX ff XX ff XX ff XX ff XX    .X.X.X.X.X.X.X.X
root@bpi:~# 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 -- -- -- -- -- -- --

my sfp also seems to be stuck in 10mbps mode

ok, so this seems not related to my specific setup. Somehow, I’m happy to hear. Does anybody know a way to force disable the parallel driver loading at kernel boot? As it seemed to work at my side when enabling i2c core debug, it may be useful to disable parallel driver loading

@ericwoud : sorry to revive this old discussion, but your statement “there seems to be an i2c problem”: is it possible this rollball initialization is causing the issue? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/mdio/mdio-i2c.c?h=v6.12.47#L355 I accidentally came by while trying to debug a 2.5gbps phy

edit: link target did not work: the i2c_mii_init_rollball function initialized everything using a 0xFFFFFFFF password. this seems hardcoded. May this be the bug I’m looking for?

This is the correct password to initialize the rollball protocol.

I have ODI DFP-34G-2C2 and runs the board with frank-w 6.12-main kernel. I edited the stick eeprom to allow 2500baseX/Full. Link is not up unless fiber is inserted in stick. I tried to hack kernel to be always up, using device tree overlay:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
/ {
    // Compatible with the Banana Pi R4 board
    compatible = "bananapi,bpi-r4", "mediatek,mt7988a";

    // Target the specific SFP node for the overlay
    fragment@0 {
        target = <&sfp1>; // This is the node for the first SFP cage
        __overlay__ {
            // Re-assign the Loss-of-Signal GPIO to an unused header pin.
            // We are changing it from <&pio 54 GPIO_ACTIVE_HIGH> to <&pio 43 GPIO_ACTIVE_HIGH>.
            // Pin 36 on the 40-pin header corresponds to GPIO43.
            los-gpios = <&pio 43 GPIO_ACTIVE_LOW>;
        };
    };
};

And it work… half of the time.

[Thu Dec 19 21:28:35 2024] mtk_soc_eth 15100000.ethernet end2: configuring for inband/2500base-x link mode
[Thu Dec 19 21:28:35 2024] mtk_soc_eth 15100000.ethernet end2: Link is Up - 2.5Gbps/Full - flow control off
[Thu Dec 19 21:28:38 2024] mtk_soc_eth 15100000.ethernet end2: Link is Down
[Thu Dec 19 21:29:14 2024] mtk_soc_eth 15100000.ethernet end2: Link is Up - 2.5Gbps/Full - flow control off
[Thu Dec 19 21:29:44 2024] mtk_soc_eth 15100000.ethernet end2: Link is Down
[Thu Dec 19 21:30:21 2024] mtk_soc_eth 15100000.ethernet end2: Link is Up - 2.5Gbps/Full - flow control off
[Thu Dec 19 21:30:51 2024] mtk_soc_eth 15100000.ethernet end2: Link is Down

Any idea how to force a stable link up?

# cat /sys/kernel/debug/sfp1/state 
Module state: present
Module probe attempts: 0 0
Device state: up
Main state: link_up
Fault recovery remaining retries: 5
PHY probe remaining retries: 25
Signalling rate: 3125 kBd
Rate select threshold: 0 kBd
moddef0: 1
rx_los: 0
tx_fault: 0
tx_disable: 0
rs0: 0
rs1: 0

# ethtool end2
Settings for end2:
	Supported ports: [ FIBRE ]
	Supported link modes:   2500baseX/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  2500baseX/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: No
	Advertised FEC modes: Not reported
	Speed: 2500Mb/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
	Link detected: yes

I don’t get it:

The password is ‘csww’ :wink: you do not need i2csfp or any brute force attack.

??

That is the password to change eeprom data of the rollball sfp module. It does not initialize the rollball protocol

Allright, gotcha.

I’m still convinced I’m pretty close though: MDIO tool exposes the OUI when reading the correct registers.

Do you know some kind of manual which I can read to debug the i2c initialization using i2c tools? If I could read the correct i2c registers step by step, I’m pretty much convinced I can say: ‘this is why the phy detection failed, I need that thing to be modified to fix it’

There is no official documentation about rollball i2c access. You can check who wrote the original patch that added it to the kernel. I believe that was Marek Perhaps he has more info.

Please remember this is the correct way of re+initializing the module. Use of i2csfp for this I do not recommend, it is never meant for that, it is a hacking tool that can cause serious damage also, messing up eeprom data…

Rebooting or reinserting would also be ok.

rmmod sfp && insmod sfp seems to work as well, I suppose that’s the same as ip lik set down/up as well, as it reinitalizes the whole module?

To rule out the cause of your problems, you may want to avoid using this method.

It’s at least promising to use that way indeed:

root@APBureau4:~# ip link set sfp-lan up
[107061.974391] mtk_soc_eth 15100000.ethernet sfp-lan: configuring for inband/10gbase-r link mode
root@APBureau4:~# [107069.729109] mtk_soc_eth 15100000.ethernet sfp-lan: validation with support 00,00000000,00000000,00000000 failed: -EINVAL
[107069.740153] sfp sfp2: sfp_add_phy failed: -EINVAL
root@APBureau4:~# ip link set sfp-lan down
[107129.871946] br-lan: port 4(sfp-lan) entered disabled state
root@APBureau4:~# ip link set sfp-lan down
[107129.871946] br-lan: port 4(sfp-lan) entered disabled state
root@APBureau4:~# echo "file drivers/i2c/* +p; file drivers/net/mdio/* +p; file
drivers/net/phy/* +p" > /sys/kernel/debug/dynamic_debug/control
root@APBureau4:~# ip link set sfp-lan up
[107154.367372] mtk_soc_eth 15100000.ethernet sfp-lan: configuring for inband/10gbase-r link mode
[107154.376028] mtk_soc_eth 15100000.ethernet sfp-lan: major config, requested inband/10gbase-r
[107154.384468] mtk_soc_eth 15100000.ethernet sfp-lan: major config, active inband/none/10gbase-r
[107154.393076] mtk_soc_eth 15100000.ethernet sfp-lan: phylink_mac_config: mode=inband/10gbase-r/none adv=00,00000000,00000800,00006440 pause=04
[107154.418017] sfp sfp2: SM: enter present:down:down event dev_up
[107154.423930] sfp sfp2: tx disable 1 -> 0
[107154.427862] sfp sfp2: SM: exit present:up:wait
[107154.477991] sfp sfp2: SM: enter present:up:wait event timeout
[107154.483849] i2c-core: using bounce buffer for addr=0x51, len=5
[107154.490600] mdio_bus i2c:sfp2: probed
[107154.494356] i2c-core: using bounce buffer for addr=0x51, len=1
[107154.500287] i2c-core: using bounce buffer for addr=0x51, len=1
[107154.506657] i2c-core: using bounce buffer for addr=0x51, len=2
...
[107155.190266] i2c-core: using bounce buffer for addr=0x51, len=2
[107155.196511] i2c-core: using bounce buffer for addr=0x51, len=1
[107155.202428] i2c-core: using bounce buffer for addr=0x51, len=6
[107155.209254] i2c-core: using bounce buffer for addr=0x51, len=2
[107155.215496] mdio_bus i2c:sfp2: poll timed out
[107155.219944] i2c-core: using bounce buffer for addr=0x51, len=1
[107155.225853] i2c-core: using bounce buffer for addr=0x51, len=1
[107155.232218] i2c-core: using bounce buffer for addr=0x51, len=2
[107155.238470] i2c-core: using bounce buffer for addr=0x51, len=4
...
[107170.649258] i2c-core: using bounce buffer for addr=0x51, len=2
[107170.655531] Aquantia AQR113C i2c:sfp2:11: no of_node; not parsing pinctrl DT
[107170.662703] i2c-core: using bounce buffer for addr=0x51, len=1
[107170.668620] i2c-core: using bounce buffer for addr=0x51, len=1
...
[107170.986514] i2c-core: using bounce buffer for addr=0x51, len=1
[107170.992428] i2c-core: using bounce buffer for addr=0x51, len=6
[107170.999254] i2c-core: using bounce buffer for addr=0x51, len=2
[107171.005709] hwmon hwmon6: temp1_input not attached to any thermal zone
[107171.012343] i2c-core: using bounce buffer for addr=0x51, len=1
...
[107175.006515] i2c-core: using bounce buffer for addr=0x51, len=1
[107175.012430] i2c-core: using bounce buffer for addr=0x51, len=6
[107175.019257] i2c-core: using bounce buffer for addr=0x51, len=2
[107175.025570] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 1 (internal) rate match none supports 2-3,5,12-14,17-19,47-48
[107175.036789] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 2 (mii) rate match none supports 2-3,13-14
[107175.046351] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 3 (gmii) rate match none supports 2-3,5,13-14,17
[107175.056434] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 4 (sgmii) rate match none supports 2-3,5,13-14,17
[107175.066601] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 22 (1000base-x) rate match none supports 5,13-14,17
[107175.076941] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 23 (2500base-x) rate match none supports 13-14,47
[107175.087108] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 24 (5gbase-r) rate match none supports 13-14,48
[107175.097103] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 27 (10gbase-r) rate match none supports 12-14,18-19
[107175.107444] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 29 (usxgmii) rate match none supports 2-3,5,12-14,17-19,47-48
[107175.118652] mtk_soc_eth 15100000.ethernet sfp-lan: requesting link mode inband/10gbase-r with support 00,00000000,00018000,000e702c
[107175.130555] mtk_soc_eth 15100000.ethernet sfp-lan: major config, requested inband/10gbase-r
[107175.138984] mtk_soc_eth 15100000.ethernet sfp-lan: major config, active inband/none/10gbase-r
[107175.147584] mtk_soc_eth 15100000.ethernet sfp-lan: phylink_mac_config: mode=inband/10gbase-r/none adv=00,00000000,00000000,000c7000 pause=00
[107175.172746] i2c-core: using bounce buffer for addr=0x51, len=1
[107175.178664] i2c-core: using bounce buffer for addr=0x51, len=1
[107176.056511] i2c-core: using bounce buffer for addr=0x51, len=1
[107176.062426] i2c-core: using bounce buffer for addr=0x51, len=6
[107176.069253] i2c-core: using bounce buffer for addr=0x51, len=2
[107176.075494] Aquantia AQR113C i2c:sfp2:11: FW 5.5, Build 6, Provisioning 3
[107176.082373] i2c-core: using bounce buffer for addr=0x51, len=1
[107176.088287] i2c-core: using bounce buffer for addr=0x51, len=1
[107182.222431] i2c-core: using bounce buffer for addr=0x51, len=6
[107182.229257] i2c-core: using bounce buffer for addr=0x51, len=2
[107182.235610] mtk_soc_eth 15100000.ethernet sfp-lan: PHY i2c:sfp2:11 uses interfaces 27, validating 27
[107182.244841] mtk_soc_eth 15100000.ethernet sfp-lan:  interface 27 (10gbase-r) rate match pause supports 3,5,12-14,17-19,47-48
[107182.256141] mtk_soc_eth 15100000.ethernet sfp-lan: PHY [i2c:sfp2:11] driver [Aquantia AQR113C] (irq=POLL)
[107182.265788] mtk_soc_eth 15100000.ethernet sfp-lan: phy: 10gbase-r setting supported 00,00000000,00018000,000e7028 advertising 00,00000000,00018000,000e7028
[107182.279785] i2c-core: using bounce buffer for addr=0x51, len=1
[107182.889273] i2c-core: using bounce buffer for addr=0x51, len=2
...
[107182.959261] i2c-core: using bounce buffer for addr=0x51, len=2
[107182.965512] sfp sfp2: SM: exit present:up:wait_los
[107182.965526] i2c-core: using bounce buffer for addr=0x51, len=1
...
[107186.579260] i2c-core: using bounce buffer for addr=0x51, len=2
[107186.585507] mtk_soc_eth 15100000.ethernet sfp-lan: phy link down 10gbase-r/10Gbps/Full/none/off
[107186.594291] Aquantia AQR113C i2c:sfp2:11: PHY state change UP -> NOLINK

Maybe I’m missing some firmware thing or something alike, I’ll look for it in the linux firmware archive. Nonetherless, why would it work when enabling dynamic debug, and not when disabling it? It makes no sense, right? There’s clearly some timeout issue… scratches head I’ll indeed hope Marek has some info about how he did it

No i2c errors as your log earlier, so the rollball protocal seems to function correctly, as does i2c. So you won’t be needing documentation for rollball from Marek.