Re: [PATCH V2] net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Fri, Jun 06, 2025 at 01:54:27PM -0500, Chris Morgan wrote:
> 	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.

> 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.

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