Message-ID: <aENv5BI2Amtqui4v@shell.armlinux.org.uk>
Date: Fri, 6 Jun 2025 23:47:00 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Chris Morgan <macromorgan@...mail.com>
Cc: Andrew Lunn <andrew@...n.ch>, Chris Morgan <macroalpha82@...il.com>,
	netdev@...r.kernel.org, hkallweit1@...il.com, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Subject: Re: [PATCH V2] net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick

On Fri, Jun 06, 2025 at 05:32:43PM -0500, Chris Morgan wrote:
> On Fri, Jun 06, 2025 at 10:21:37PM +0100, Russell King (Oracle) wrote:
> > 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?
> > 
> 
> That is correct.

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

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

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)

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

Powered by blists - more mailing lists