Skip to contentSkip to conversation

net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick

PATCH Superseded Chris Morgan 4 participants 12 messages Jun 6, 2025 – Jun 11, 2025

Subsystems (4)
Networking Network drivers Ethernet PHY SFF/SFP/SFP+ module support

v2 of 4 Superseded Latest is v4 →

lore
Share & tools
lore

Chris Morgan

author
#0 lore raw

PATCH v2 1/1 net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick

From: Chris Morgan <[email protected]>

Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON).

This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it.

https://www.potrontec.com/index/index/list/cat_id/2.html#11-83
https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/

Signed-off-by Chris Morgan <[email protected]>

---

Changes since V1:
- Call sfp_fixup_ignore_tx_fault() and sfp_fixup_ignore_los() instead of setting the state_hw_mask.

---
 drivers/net/phy/sfp.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
drivers/net/phy/sfp.c +15 -0
index 347c1e0e94d9..a7fee449fa92 100644
@@ -412,6 +412,19 @@ static void sfp_fixup_halny_gsfp(struct sfp *sfp)
 	sfp->state_hw_mask &= ~(SFP_F_TX_FAULT | SFP_F_LOS);
 }
 
+static void sfp_fixup_potron(struct sfp *sfp)
+{
+	/*
+	 * The TX_FAULT and LOS pins on this device are used for serial
+	 * communication, so ignore them. Additionally, provide extra
+	 * time for this device to fully start up.
+	 */
+
+	sfp_fixup_long_startup(sfp);
+	sfp_fixup_ignore_tx_fault(sfp);
+	sfp_fixup_ignore_los(sfp);
+}
+
 static void sfp_fixup_rollball_cc(struct sfp *sfp)
 {
 	sfp_fixup_rollball(sfp);

@@ -512,6 +525,8 @@ static const struct sfp_quirk sfp_quirks[] = {
 	SFP_QUIRK_F("Walsun", "HXSX-ATRC-1", sfp_fixup_fs_10gt),
 	SFP_QUIRK_F("Walsun", "HXSX-ATRI-1", sfp_fixup_fs_10gt),
 
+	SFP_QUIRK_F("YV", "SFP+ONU-XGSPON", sfp_fixup_potron),
+
 	// OEM SFP-GE-T is a 1000Base-T module with broken TX_FAULT indicator
 	SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
Signature · 1 line
2.43.0
maintainer
#1 lore raw
Quoted 12 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON).

This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it.

https://www.potrontec.com/index/index/list/cat_id/2.html#11-83
https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/

Quoted 6 lines
Signed-off-by Chris Morgan <[email protected]>

---

Changes since V1:
- Call sfp_fixup_ignore_tx_fault() and sfp_fixup_ignore_los() instead of setting the state_hw_mask.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

You are supposed to wait 24 hours before posting a new version. We are also in the merge window at the moment, so please post patches as RFC.

Russell asked the question, what does the SFP report about soft LOS in its EEPROM? Does it correctly indicate it supports soft LOS? Does it actually support soft LOS? Do we need to force on soft LOS? Maybe we need a helper sfp_fixup_force_soft_los()?

Andrew

---
pw-bot: cr

#2 lore raw
Quoted 16 lines · Andrew Lunn
Quoted 15 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON).

This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it.

https://www.potrontec.com/index/index/list/cat_id/2.html#11-83
https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/

Signed-off-by Chris Morgan <[email protected]>

---

Quoted 8 lines
Quoted 3 lines

Changes since V1:
- Call sfp_fixup_ignore_tx_fault() and sfp_fixup_ignore_los() instead of setting the state_hw_mask.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

You are supposed to wait 24 hours before posting a new version. We are also in the merge window at the moment, so please post patches as RFC.

Sorry, I'll make sure to slow down the commits moving forward.

Quoted 5 lines

Russell asked the question, what does the SFP report about soft LOS in its EEPROM? Does it correctly indicate it supports soft LOS? Does it actually support soft LOS? Do we need to force on soft LOS? Maybe we need a helper sfp_fixup_force_soft_los()?

So I'm a bit out of my element here and not sure how to check that. I bought this module and had a hell of a time getting it to work on my Banana Pi R4 because of the UART triggering repeated tx faults. After applying these updates I was able to get it to work, so I figured it would be a courtesy to upstream these for others not to suffer. I was going to get this upstreamed, then request OpenWRT backport the fix, then move this device to replace my current router (which might be why I am guilty of rushing, sorry again). That said, I'm not sure how to check if the module supports soft LOS or not. I did a dump with ethtool -m but didn't see any references to LOS. Is there a bit on the EEPROM I can check?

Thank you,
Chris

Quoted 5 lines

Andrew

---
pw-bot: cr

maintainer
#3 lore raw
Quoted 1 line

So I'm a bit out of my element here and not sure how to check that.

No problems.

Please show us the output from ethtool -m, both the pretty printed and the raw hex.

The relevant code is:

https://elixir.bootlin.com/linux/v6.15/source/drivers/net/phy/sfp.c#L872
https://elixir.bootlin.com/linux/v6.15/source/include/linux/sfp.h#L400

I don't think the pritty printed ethtool output shows it, but we should be able to decode the raw hex, byte 83, bit 4. A lot depends on how broken the SFP is.

Or you can put a printk() in sfp_soft_start_poll().

You might also want to add #define DEBUG at the
very top of sfp.c, so you get debug prints with state changes. And then pull the cable out/plug it in and see what gets reported.

Andrew

#4 lore raw
Quoted 16 lines · Andrew Lunn
Quoted 1 line

So I'm a bit out of my element here and not sure how to check that.

No problems.

Please show us the output from ethtool -m, both the pretty printed and the raw hex.

The relevant code is:

https://elixir.bootlin.com/linux/v6.15/source/drivers/net/phy/sfp.c#L872
https://elixir.bootlin.com/linux/v6.15/source/include/linux/sfp.h#L400

I don't think the pritty printed ethtool output shows it, but we should be able to decode the raw hex, byte 83, bit 4. A lot depends on how broken the SFP is.

Quoted 5 lines

Or you can put a printk() in sfp_soft_start_poll().

You might also want to add #define DEBUG at the
very top of sfp.c, so you get debug prints with state changes. And then pull the cable out/plug it in and see what gets reported.

Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Transceiver type : 10G Ethernet: 10G Base-LR
Encoding : 0x03 (NRZ)
BR, Nominal : 10000MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 20km
Length (SMF) : 20000m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1270nm
Vendor name : YV
Vendor OUI : 00:00:00
Vendor PN : SFP+ONU-XGSPON
Vendor rev : A-01
Option values : 0x00 0x00
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : 202504250094
Date code : 250425
Optical diagnostics support : Yes
Laser bias current : 0.000 mA
Laser output power : 0.0000 mW / -inf dBm
Receiver signal average optical power : 0.0000 mW / -inf dBm
Module temperature : 52.47 degrees C / 126.44 degrees F
Module voltage : 3.3912 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : On
Laser bias current high warning : Off
Laser bias current low warning : On
Laser output power high alarm : Off
Laser output power low alarm : On
Laser output power high warning : Off
Laser output power low warning : On
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : On
Laser rx power high warning : Off
Laser rx power low warning : On
Laser bias current high alarm threshold : 60.000 mA
Laser bias current low alarm threshold : 0.000 mA
Laser bias current high warning threshold : 55.000 mA
Laser bias current low warning threshold : 0.000 mA
Laser output power high alarm threshold : 6.5535 mW / 8.16 dBm
Laser output power low alarm threshold : 1.5848 mW / 2.00 dBm
Laser output power high warning threshold : 6.5535 mW / 8.16 dBm
Laser output power low warning threshold : 1.9952 mW / 3.00 dBm
Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold : -50.00 degrees C / -58.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -45.00 degrees C / -49.00 degrees F
Module voltage high alarm threshold : 3.6000 V
Module voltage low alarm threshold : 3.0000 V
Module voltage high warning threshold : 3.4700 V
Module voltage low warning threshold : 3.1300 V
Laser rx power high alarm threshold : 0.1995 mW / -7.00 dBm
Laser rx power low alarm threshold : 0.0011 mW / -29.59 dBm
Laser rx power high warning threshold : 0.1584 mW / -8.00 dBm
Laser rx power low warning threshold : 0.0014 mW / -28.54 dBm

I'll send the bin dump in another message (privately). Since the OUI is 00:00:00 and the serial number appears to be a datestamp, I'm not seeing anything on here that's sensitive.

Thank you,
Chris

Quoted 2 lines

Andrew

maintainer
#5 lore raw
Quoted 1 line · Chris Morgan
	Option values					: 0x00 0x00

This suggests that LOS is not supported, nor any of the other hardware signals. However, because early revisions of the SFP MSA didn't have an option byte, and thus was zero, but did have the hardware signals, we can't simply take this to mean the signals aren't implemented, except for RX_LOS.

Quoted 3 lines

I'll send the bin dump in another message (privately). Since the OUI is 00:00:00 and the serial number appears to be a datestamp, I'm not seeing anything on here that's sensitive.

I have augmented tools which can parse the binary dump, so I get a bit more decode:

        Enhanced Options                          : soft TX_DISABLE
        Enhanced Options                          : soft TX_FAULT
        Enhanced Options                          : soft RX_LOS

So, this tells sfp.c that the status bits in the diagnostics address offset 110 (SFP_STATUS) are supported.

Digging into your binary dump, SFP_STATUS has the value 0x02, which indicates RX_LOS is set (signal lost), but TX_FAULT is clear (no transmit fault.)

I'm guessing the SFP didn't have link at the time you took this dump given that SFP_STATUS indicates RX_LOS was set?

Now, the problem with clearing bits in ->state_hw_mask is that leads the SFP code to think "this hardware signal isn't implemented, so I'll use the software specified signal instead where the module indicates support via the enhanced options."

Setting bits in ->state_ignore_mask means that *both* the hardware and software signals will be ignored, and if RX_LOS is ignored, then the "Options" word needs to be updated to ensure that neither inverted or normal LOS is reported there to avoid the state machines waiting indefinitely for LOS to change. That is handled by sfp_fixup_ignore_los().

If the soft bits in SFP_STATUS is reliable, then clearing the appropriate flags in ->state_hw_mask for the hardware signals is fine.

However, we have seen modules where this is not the case, and the software bits seem to follow the wiggling of the hardware lines.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
#6 lore raw
Quoted 23 lines · Russell King (Oracle)
Quoted 1 line · Chris Morgan
	Option values					: 0x00 0x00

This suggests that LOS is not supported, nor any of the other hardware signals. However, because early revisions of the SFP MSA didn't have an option byte, and thus was zero, but did have the hardware signals, we can't simply take this to mean the signals aren't implemented, except for RX_LOS.

Quoted 3 lines

I'll send the bin dump in another message (privately). Since the OUI is 00:00:00 and the serial number appears to be a datestamp, I'm not seeing anything on here that's sensitive.

I have augmented tools which can parse the binary dump, so I get a bit more decode:

        Enhanced Options                          : soft TX_DISABLE
        Enhanced Options                          : soft TX_FAULT
        Enhanced Options                          : soft RX_LOS

So, this tells sfp.c that the status bits in the diagnostics address offset 110 (SFP_STATUS) are supported.

Quoted 7 lines

Digging into your binary dump, SFP_STATUS has the value 0x02, which indicates RX_LOS is set (signal lost), but TX_FAULT is clear (no transmit fault.)

I'm guessing the SFP didn't have link at the time you took this dump given that SFP_STATUS indicates RX_LOS was set?

That is correct.

Quoted 12 lines

Now, the problem with clearing bits in ->state_hw_mask is that leads the SFP code to think "this hardware signal isn't implemented, so I'll use the software specified signal instead where the module indicates support via the enhanced options."

Setting bits in ->state_ignore_mask means that *both* the hardware and software signals will be ignored, and if RX_LOS is ignored, then the "Options" word needs to be updated to ensure that neither inverted or normal LOS is reported there to avoid the state machines waiting indefinitely for LOS to change. That is handled by sfp_fixup_ignore_los().

Quoted 3 lines

If the soft bits in SFP_STATUS is reliable, then clearing the appropriate flags in ->state_hw_mask for the hardware signals is fine.

I'll test this out more and resubmit once I confirm that simply setting state_hw_mask (which means we don't do it in hardware) works just the same on my device as state_ignore_mask. So if I understand correctly that means we're doing the following:

sfp_fixup_long_startup(sfp); sfp->state_hw_mask &= ~(SFP_F_TX_FAULT | SFP_F_LOS);

The long startup solves for the problem that the SFP+ device has to boot up; and the state_hw_mask solves for the TX and LOS hardware pins being used for UART but software TX fault and LOS still working.

Quoted 7 lines

However, we have seen modules where this is not the case, and the software bits seem to follow the wiggling of the hardware lines.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Thank you for all your help,
Chris

maintainer
#7 lore raw
Quoted 28 lines · Chris Morgan
Quoted 27 lines · Russell King (Oracle)
Quoted 1 line · Chris Morgan
	Option values					: 0x00 0x00

This suggests that LOS is not supported, nor any of the other hardware signals. However, because early revisions of the SFP MSA didn't have an option byte, and thus was zero, but did have the hardware signals, we can't simply take this to mean the signals aren't implemented, except for RX_LOS.

Quoted 3 lines

I'll send the bin dump in another message (privately). Since the OUI is 00:00:00 and the serial number appears to be a datestamp, I'm not seeing anything on here that's sensitive.

I have augmented tools which can parse the binary dump, so I get a bit more decode:

        Enhanced Options                          : soft TX_DISABLE
        Enhanced Options                          : soft TX_FAULT
        Enhanced Options                          : soft RX_LOS

So, this tells sfp.c that the status bits in the diagnostics address offset 110 (SFP_STATUS) are supported.

Digging into your binary dump, SFP_STATUS has the value 0x02, which indicates RX_LOS is set (signal lost), but TX_FAULT is clear (no transmit fault.)

Quoted 5 lines
Quoted 3 lines

I'm guessing the SFP didn't have link at the time you took this dump given that SFP_STATUS indicates RX_LOS was set?

That is correct.

Are you able to confirm that SFP_STATUS RX_LOS clears when the module has link?

Quoted 21 lines
Quoted 12 lines

Now, the problem with clearing bits in ->state_hw_mask is that leads the SFP code to think "this hardware signal isn't implemented, so I'll use the software specified signal instead where the module indicates support via the enhanced options."

Setting bits in ->state_ignore_mask means that *both* the hardware and software signals will be ignored, and if RX_LOS is ignored, then the "Options" word needs to be updated to ensure that neither inverted or normal LOS is reported there to avoid the state machines waiting indefinitely for LOS to change. That is handled by sfp_fixup_ignore_los().

Quoted 3 lines

If the soft bits in SFP_STATUS is reliable, then clearing the appropriate flags in ->state_hw_mask for the hardware signals is fine.

I'll test this out more and resubmit once I confirm that simply setting state_hw_mask (which means we don't do it in hardware) works just the same on my device as state_ignore_mask. So if I understand correctly that means we're doing the following:

Quoted 6 lines

sfp_fixup_long_startup(sfp); sfp->state_hw_mask &= ~(SFP_F_TX_FAULT | SFP_F_LOS);

The long startup solves for the problem that the SFP+ device has to boot up; and the state_hw_mask solves for the TX and LOS hardware pins being used for UART but software TX fault and LOS still working.

I'd prefer to have an additional couple of functions:

sfp_fixup_ignore_hw_tx_fault()
sfp_fixup_ignore_hw_los()

or possibly:

sfp_fixup_ignore_hw(struct sfp *sfp, unsigned int mask)

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
#8 lore raw
Quoted 29 lines · Russell King (Oracle)
Quoted 28 lines · Chris Morgan
Quoted 27 lines · Russell King (Oracle)
Quoted 1 line · Chris Morgan
	Option values					: 0x00 0x00

This suggests that LOS is not supported, nor any of the other hardware signals. However, because early revisions of the SFP MSA didn't have an option byte, and thus was zero, but did have the hardware signals, we can't simply take this to mean the signals aren't implemented, except for RX_LOS.

Quoted 3 lines

I'll send the bin dump in another message (privately). Since the OUI is 00:00:00 and the serial number appears to be a datestamp, I'm not seeing anything on here that's sensitive.

I have augmented tools which can parse the binary dump, so I get a bit more decode:

        Enhanced Options                          : soft TX_DISABLE
        Enhanced Options                          : soft TX_FAULT
        Enhanced Options                          : soft RX_LOS

So, this tells sfp.c that the status bits in the diagnostics address offset 110 (SFP_STATUS) are supported.

Digging into your binary dump, SFP_STATUS has the value 0x02, which indicates RX_LOS is set (signal lost), but TX_FAULT is clear (no transmit fault.)

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

I'm guessing the SFP didn't have link at the time you took this dump given that SFP_STATUS indicates RX_LOS was set?

That is correct.

Are you able to confirm that SFP_STATUS RX_LOS clears when the module has link?

I believe this is the case. I've sent you a dump of my EEPROM when the SFP+ is active (it's now powering my internet connection at home) in a private message to confirm.

Quoted 29 lines
Quoted 22 lines
Quoted 13 lines

Now, the problem with clearing bits in ->state_hw_mask is that leads the SFP code to think "this hardware signal isn't implemented, so I'll use the software specified signal instead where the module indicates support via the enhanced options."

Setting bits in ->state_ignore_mask means that *both* the hardware and software signals will be ignored, and if RX_LOS is ignored, then the "Options" word needs to be updated to ensure that neither inverted or normal LOS is reported there to avoid the state machines waiting indefinitely for LOS to change. That is handled by sfp_fixup_ignore_los().

Quoted 3 lines

If the soft bits in SFP_STATUS is reliable, then clearing the appropriate flags in ->state_hw_mask for the hardware signals is fine.

I'll test this out more and resubmit once I confirm that simply setting state_hw_mask (which means we don't do it in hardware) works just the same on my device as state_ignore_mask. So if I understand correctly that means we're doing the following:

Quoted 6 lines

sfp_fixup_long_startup(sfp); sfp->state_hw_mask &= ~(SFP_F_TX_FAULT | SFP_F_LOS);

The long startup solves for the problem that the SFP+ device has to boot up; and the state_hw_mask solves for the TX and LOS hardware pins being used for UART but software TX fault and LOS still working.

Quoted 9 lines

I'd prefer to have an additional couple of functions:

sfp_fixup_ignore_hw_tx_fault()
sfp_fixup_ignore_hw_los()

or possibly:

sfp_fixup_ignore_hw(struct sfp *sfp, unsigned int mask)

Which of these would you prefer? Do you want a function for each scenario or just a generic sfp_fixup_ignore_hw_fault_signal()? I can create functions for each and then apply them to my device (and probably update the sfp_fixup_halny_gsfp() too since it's identical to what I'm trying to do plus the delay bits).

Quoted 3 lines
Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Thank you,
Chris

maintainer
#9 lore raw
Quoted 34 lines · Chris Morgan
Quoted 33 lines · Russell King (Oracle)
Quoted 32 lines · Chris Morgan
Quoted 30 lines · Russell King (Oracle)
Quoted 1 line · Chris Morgan
	Option values					: 0x00 0x00

This suggests that LOS is not supported, nor any of the other hardware signals. However, because early revisions of the SFP MSA didn't have an option byte, and thus was zero, but did have the hardware signals, we can't simply take this to mean the signals aren't implemented, except for RX_LOS.

Quoted 3 lines

I'll send the bin dump in another message (privately). Since the OUI is 00:00:00 and the serial number appears to be a datestamp, I'm not seeing anything on here that's sensitive.

I have augmented tools which can parse the binary dump, so I get a bit more decode:

        Enhanced Options                          : soft TX_DISABLE
        Enhanced Options                          : soft TX_FAULT
        Enhanced Options                          : soft RX_LOS

So, this tells sfp.c that the status bits in the diagnostics address offset 110 (SFP_STATUS) are supported.

Digging into your binary dump, SFP_STATUS has the value 0x02, which indicates RX_LOS is set (signal lost), but TX_FAULT is clear (no transmit fault.)

I'm guessing the SFP didn't have link at the time you took this dump given that SFP_STATUS indicates RX_LOS was set?

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

That is correct.

Are you able to confirm that SFP_STATUS RX_LOS clears when the module has link?

I believe this is the case. I've sent you a dump of my EEPROM when the SFP+ is active (it's now powering my internet connection at home) in a private message to confirm.

Yes, I can confirm this. The RX_LOS bit on SFP_STATUS appears to work correctly, so all we need to do is ignore the hardware signal(s).

Quoted 7 lines
Quoted 7 lines

I'd prefer to have an additional couple of functions:

sfp_fixup_ignore_hw_tx_fault()
sfp_fixup_ignore_hw_los()

or possibly:

Quoted 8 lines
Quoted 2 lines

sfp_fixup_ignore_hw(struct sfp *sfp, unsigned int mask)

Which of these would you prefer? Do you want a function for each scenario or just a generic sfp_fixup_ignore_hw_fault_signal()? I can create functions for each and then apply them to my device (and probably update the sfp_fixup_halny_gsfp() too since it's identical to what I'm trying to do plus the delay bits).

I think the latter as it's more flexible and less code.

Yes, please update sfp_fixup_halny_gsfp() as well.

Thanks.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
maintainer
#10 lore raw
In reply to Chris Morgan
Quoted 34 lines · Chris Morgan
Quoted 16 lines · Andrew Lunn
Quoted 15 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON).

This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it.

https://www.potrontec.com/index/index/list/cat_id/2.html#11-83
https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/

Signed-off-by Chris Morgan <[email protected]>

---

Quoted 8 lines
Quoted 3 lines

Changes since V1:
- Call sfp_fixup_ignore_tx_fault() and sfp_fixup_ignore_los() instead of setting the state_hw_mask.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

You are supposed to wait 24 hours before posting a new version. We are also in the merge window at the moment, so please post patches as RFC.

Sorry, I'll make sure to slow down the commits moving forward.

Quoted 5 lines

Russell asked the question, what does the SFP report about soft LOS in its EEPROM? Does it correctly indicate it supports soft LOS? Does it actually support soft LOS? Do we need to force on soft LOS? Maybe we need a helper sfp_fixup_force_soft_los()?

Quoted 11 lines

So I'm a bit out of my element here and not sure how to check that. I bought this module and had a hell of a time getting it to work on my Banana Pi R4 because of the UART triggering repeated tx faults. After applying these updates I was able to get it to work, so I figured it would be a courtesy to upstream these for others not to suffer. I was going to get this upstreamed, then request OpenWRT backport the fix, then move this device to replace my current router (which might be why I am guilty of rushing, sorry again). That said, I'm not sure how to check if the module supports soft LOS or not. I did a dump with ethtool -m but didn't see any references to LOS. Is there a bit on the EEPROM I can check?

Please send me (privately) the binary of:

ethtool -m ethX raw on > ethX.eeprom.bin

so I can see fully what it's reporting - I should then be able to make further suggestions.

Thanks.

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
maintainer
#11 lore raw
In reply to Andrew Lunn
Quoted 22 lines · Andrew Lunn
Quoted 12 lines · Chris Morgan

From: Chris Morgan <[email protected]>

Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON).

This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it.

https://www.potrontec.com/index/index/list/cat_id/2.html#11-83
https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/

Quoted 6 lines
Signed-off-by Chris Morgan <[email protected]>

---

Changes since V1:
- Call sfp_fixup_ignore_tx_fault() and sfp_fixup_ignore_los() instead of setting the state_hw_mask.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

Quoted 7 lines

You are supposed to wait 24 hours before posting a new version. We are also in the merge window at the moment, so please post patches as RFC.

Russell asked the question, what does the SFP report about soft LOS in its EEPROM? Does it correctly indicate it supports soft LOS? Does it actually support soft LOS? Do we need to force on soft LOS? Maybe we need a helper sfp_fixup_force_soft_los()?

Yep, too many people today seem to ignore questions and think they mean "let's post a new patch". :(

Signature · 2 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!