I can’t seem ton convince Debian Linux 5.16.12-1~bpo11+1 to turn tx_disable off on the SFP+ module (or show the EEPROM of it). For some reason kernel/debug/gpio shows the tx-disable gpio pin, but its set to “in” instead of “out”?
Sadly 5.18 crashes on boot, and there isn’t another 5.16+ kernel readily available.
Sadly I couldn’t find any of the explicitly supported modules available with reasonable shipping times, so I got what I could find - a TP-Link 10G Copper cage. Is this just a matter of that not being supported?
[ 706.757878] sfp dpmac1_sfp: module TP-Link TL-SM5310-T(UN) rev 1.0 sn 22234A2000194 dc 220412
# cat /sys/kernel/debug/dpmac1_sfp/state
Module state: present
Module probe attempts: 0 0
Device state: down
Main state: down
Fault recovery remaining retries: 0
PHY probe remaining retries: 0
moddef0: 1
rx_los: 0
tx_fault: 0
tx_disable: 1
# cat /sys/kernel/debug/gpio
gpiochip4: GPIOs 368-383, parent: i2c/0-0076, 0-0076, can sleep:
gpio-368 ( |tx-fault ) in hi
gpio-369 ( |tx-disable ) in hi
gpio-370 ( |mod-def0 ) in hi ACTIVE LOW
gpio-371 ( |los ) in hi
gpio-372 ( |tx-fault ) in lo
gpio-373 ( |tx-disable ) out hi
gpio-374 ( |mod-def0 ) in lo ACTIVE LOW
gpio-375 ( |los ) in lo
gpio-380 ( |ten64:admin ) out lo
gpio-381 ( |admin_led_lower ) out lo
gpiochip3: GPIOs 384-415, parent: platform/2330000.gpio, 2330000.gpio:
gpio-392 ( |ADMIN button ) in lo
gpio-395 ( |ten64:green:sfp1:dow) out lo
gpio-396 ( |ten64:green:sfp2:up ) out lo
gpiochip2: GPIOs 416-447, parent: platform/2320000.gpio, 2320000.gpio:
gpiochip1: GPIOs 448-479, parent: platform/2310000.gpio, 2310000.gpio:
gpio-465 ( |External Power Down ) in hi ACTIVE LOW
gpiochip0: GPIOs 480-511, parent: platform/2300000.gpio, 2300000.gpio:
# echo 369 > /sys/class/gpio/export # okay, obviously wont work
-bash: echo: write error: Device or resource busy
# ethtool -m eth8
Cannot get Module EEPROM data: No such device or address
It looks like you inserted the SFP into the top slot, which is eth9, but it’s routed to the CPU MAC 1 (dpmac1). The bottom slot (eth8) is routed to CPU MAC 2 (dpmac2). (Yes, it’s a little confusing!)
The tx disable (GPIO373) for the top slot is being driven as an output.
gpio-373 ( |tx-disable ) out hi
The bottom slot is empty so the SFP driver sets it as input to allow the pull-ups on the board to work:
gpio-369 ( |tx-disable ) in hi
gpio-370 ( |mod-def0 ) in hi ACTIVE LOW
If you need a working >=5.16 kernel, this 5.19-rc3 build works:
Ah, right, that is confusing. I wasn’t able to try your 5.19-rc3 build (because it doesn’t have ip rule support?) but I did try the debian-testing 5.18.5 (which has the fix for 215886 – dpaa2: TSO offload on lx2160a causes fatal exception in interrupt in it so it doesn’t crash). Sadly that too didn’t (fully) recognize the module, but it did see something. Note that this is a 10G-BASET module, so its indeed being mis-recognized here (is that lack of driver?)
Oh…that’s annoying and also very confusing. Also annoying it doesn’t get temperature information (which the datasheet lists “Support DDM (Temperature and Voltage)”, though of course who knows, this is TP-Link…)
Can you do an i2c scan on the module? Just curious if it provides access to the Ethernet PHY inside
(Make sure you bring the interface up first)
sudo i2cdetect 4 # (use 3 for the top/XG1 slot)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-4.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
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 -- -- -- -- -- -- --
If it only answers on 0x50 than it doesn’t.
If it does, it’s a possibility that Linux will be able to ‘see through’ the SFP and be able to report the 10GBase-T status directly.