SFP+ tx_disable locked on

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:

https://archive.traverse.com.au/pub/traverse/debian-experimental/pool/main/l/linux-traverse/linux-image-5.19.0-rc3-traverse-torvalds+76-00005-g125e6080fe72_5.19.0-rc3-traverse-torvalds+76-00005-g125e6080fe72-1_arm64.deb
Configuration and patches from here: traversetech / traverse-kernel-patches · GitLab

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?)

# ethtool -m eth9
	Identifier                                : 0x03 (SFP)
	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
	Connector                                 : 0x07 (LC)
	Transceiver codes                         : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Transceiver type                          : 10G Ethernet: 10G Base-SR
	Encoding                                  : 0x06 (64B/66B)
	BR, Nominal                               : 10300MBd
	Rate identifier                           : 0x00 (unspecified)
	Length (SMF,km)                           : 0km
	Length (SMF)                              : 0m
	Length (50um)                             : 0m
	Length (62.5um)                           : 0m
	Length (Copper)                           : 0m
	Length (OM3)                              : 0m
	Laser wavelength                          : 0nm
	Vendor name                               : TP-Link
	Vendor OUI                                : 00:00:00
	Vendor PN                                 : TL-SM5310-T(UN)
	Vendor rev                                : 1.0
	Option values                             : 0x00 0x1a
	Option                                    : RX_LOS implemented
	Option                                    : TX_FAULT implemented
	Option                                    : TX_DISABLE implemented
	BR margin, max                            : 0%
	BR margin, min                            : 0%
	Vendor SN                                 : 22234A2000194
	Date code                                 : 220412
# ethtool eth9
Settings for eth9:
	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: Unknown!
	Duplex: Unknown! (255)
	Auto-negotiation: on
	Port: FIBRE
	PHYAD: 0
	Transceiver: internal
	Link detected: no

Oh, errrr, this is embarrassing, apparently it does work in the above state, its just that ethtool -m's output is completely nonsense.

ethtool -m prints out the contents of the modules EEPROM.
The module is just pretending to be a fiber SFP for backwards compatibility.

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…)

Just out of interest, can you try this 5.19-rc4 build?
https://archive.traverse.com.au/pub/traverse/debian-experimental/pool/main/l/linux-traverse/linux-image-5.19.0-rc4-traverse-torvalds+77-00005-g2d74f7feba38_5.19.0-rc4-traverse-torvalds+77-00005-g2d74f7feba38-1_arm64.deb
I turned on a few Netfilter and ipset options that were disabled.

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.