Afaik you cannot patch it in general because los detection some kind of security feature. If there is no rx signal the sfp should disable tx to avoid accidents when people looking into the transmitter.
But this can be manually and temprary changed (because linux requires a pin assigned to los property in dts) using devicetree overlay. I thought you have already done that…
Correct, we helped a user here to do that. But I would have thought openwrt may have some setting for this by now, but maybe not,
That overlay looks right to me. I didn’t make the overlay the other time.
Use overlay, or rebuild the dtb, both should work.
Edit:
Any reason why you add compatible to the overlay? It doesn’t change…
Edit2:
Any reason not to use labels (and dtb’s build with symbols)? I see you use absolute paths in all overlays.
&sfp1 {
los-gpios = <&pio 52 GPIO_ACTIVE_HIGH>; /* map to gpio header pin 26 */
};
Afair it was a requirement for mainline to match the board with compatibles…here i just copied the emmc one.
Same here,i use symbols in dtb,but mainline required the path for target (previous version of afair r3 sata overlay with fragment and target was rejected).
Not sure if the gpio for los should be active low or active high here to fix the issue when gpio not connected. Imho now it has to be connected to gnd (pin 25) to have los not set.
I guess just try it out, connecting to GND or 3.3V. And anybody trying this, do not connect to 5V !!!
I have no gpon sfp to try out. Maybe fibre sfp can be used too (and just read sfp pins somehow),but not sure.
Edit: remembered that state of these pins was also shown in ethtool -m
Or maybe
cat /sys/kernel/debug/sfp*/state
mhm, seems that sfp does not come up when pin is set to gnd after boot
# cat /sys/kernel/debug/sfp1/state
Module state: waitdev
Module probe attempts: 0 0
Device state: detached
Main state: down
Fault recovery remaining retries: 0
PHY probe remaining retries: 0
Signalling rate: 0 kBd
Rate select threshold: 0 kBd
moddef0: 1
rx_los: 0
tx_fault: 0
tx_disable: 1
rs0: 1
rs1: 0
when rebooting without the overlay i see this (no fibre connected):
# cat /sys/kernel/debug/sfp1/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
Signalling rate: 0 kBd
Rate select threshold: 0 kBd
moddef0: 1
rx_los: 1
tx_fault: 0
tx_disable: 1
rs0: 1
rs1: 0
But the eth1 up is a combo of things, so that needs more. For the problem above, it should be enough
But when i remap the gpio i get the waitdev for sfp…the module probe seems not complete.so i guess a possible webinterface will not be available for gpon sfp. As i already said i have no gpon sfp so i can test only with my fibre sfp. Not sure why mac is important here (later of course,but not for module parameters).
In case of the gpon, the mac will report link up, because there is always a signal when the module is powered up. But the LOS signal did not report a signal. After the gpio swap and applying the correct level at the gpio pin, the LOS signals link up also and eth1 should go link up.
I think in your test, there is no valid signal for the mac to report link up.
I do not look on link state,only on sfp state. It looks like sfp probing does not work with los-gpio 52 (pin 26) also if bridged to gnd (pin 25).
It is clear that i do not get a link-up…imho eth1/2 was disabled too,but this should not affect sfp state.
And if you change GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW?
It should not matter either i have rx_los 0 or rx_los 1.
May it does not go up because tx_disable is set?
Anyway, it looks the los pin is changed by the overlay, so it should be enough for the gpon. In that case, it was the only condition missing.
Hello Has anyone had any luck with LEOX LXT-010S-H recently or it’s a lost cause ?
Thanks
this change seems to break the SFPs on my R4. I have tried branch 6.15-rc (commit 29454660bdbb1c254eba96600ec444596fbcf9bb, from https://github.com/frank-w/BPI-Router-Linux) with the 804a1c85b82dc9168de3db015567edcb00343a40 patch, and with it reversed, and and in both cases I get:
Module state: waitdev
Module probe attempts: 0 0
Device state: detached
Main state: down
Fault recovery remaining retries: 0
PHY probe remaining retries: 0
Signalling rate: 0 kBd
Rate select threshold: 0 kBd
moddef0: 1
rx_los: 1
tx_fault: 0
tx_disable: 1
rs0: 1
rs1: 0
and the net devs are not populated.
This is the quirk in mainline:
SFP_QUIRK("ALCATELLUCENT", "3FE46541AA", sfp_quirk_2500basex,
sfp_fixup_nokia),
static void sfp_fixup_nokia(struct sfp *sfp)
{
sfp_fixup_long_startup(sfp);
sfp_fixup_ignore_los(sfp);
}
static void sfp_fixup_long_startup(struct sfp *sfp)
{
sfp->module_t_start_up = T_START_UP_BAD_GPON;
}
static void sfp_fixup_ignore_los(struct sfp *sfp)
{
/* This forces LOS to zero, so we ignore transitions */
sfp->state_ignore_mask |= SFP_F_LOS;
/* Make sure that LOS options are clear */
sfp->id.ext.options &= ~cpu_to_be16(SFP_OPTIONS_LOS_INVERTED |
SFP_OPTIONS_LOS_NORMAL);
}
So the module also has a problem with long startup.
Which openwrt version are you using? Doesn’t openwrt have this quirk? It may help disabling autonegotiotion with ethtool also…
I’m going to need some advice here on how to debug the SFP modules here: Although the link is OK, the bandwidth on the ports are limited to 100mbps only.
Ethtool shows the link speed is 2500 and the other side reports 2500 als link speed. But testing the connection it seems to be limited to 100mbit/s.
I tried @ericwoud 's i2csfp tool to see whether there would be something wrong with the sfp module, but I could not find anything useful.
It looks like all the quirks for SFP 2.5G modules actually pamper over the issue instead of fixing it.
Has anybody any idea how a 2.5G RJ45 SFP module is limited to 100mbit even though it specifies 2.5G to the host OS and other side reports link speed being 2.5G? how do I see what goes wrong?
Is it the issue that all lan (dsa) ports are 100mbps when a 100mbps client is attached to one of the dsa ports?
Sfp on r4 is not connected to mt753x switch. Sfp is not related to dsa (unlike bpi-r3 where sfp lan is connected to switch). Afaik the issue also shows 100mbit link with ethtool and not only a throughput issue.
Interesting would be test-setup (which devices are connected how - especially using routing,switching or traffic to/from r4) and maybe try different sfps.