After a quick test, the OpenWRT settings mentioned here in the documentation do not matter here.
lower_sfp_txidsable and lower_sfp_txidsable both on zero and one, give one result.
root@OpenWrt:~# 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: 1
tx_fault: 0
tx_disable: 1
And with 1:
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: 1
tx_fault: 0
tx_disable: 1
Context:
root@OpenWrt:~# ethtool -m eth9
...
Laser wavelength : 1490nm
Vendor name : CTS INC.
Vendor OUI : 00:90:65
Vendor PN : SFP-31W2BahSM-10
I have not tried those FS modules, but I do have both 1 and 10G BiDis from 10Gtek which I have tested successfully:
Thank you, these look nice; sadly, I’m dealing with a single-mode on my ISP’s side, not sure if these modules will be applicable.
It could be that a ‘qurik’ needs to be implemented in the Linux SFP code for some of your modules.
With some probably meaning “most” here, given how much Chinese devices I have. ![]()
The docs mention the extender cable. Is there any chance to add a pull-down resistor on TX_DISABLE at such a cable by replacing one side with my custom board and test whether the issue is only with one GPIO pin? I think it’s better to try someday, given the kernel may change regularly…