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

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

On Tue, Jun 10, 2025 at 10:43:31PM -0500, Chris Morgan wrote:
> On Fri, Jun 06, 2025 at 11:47:00PM +0100, Russell King (Oracle) wrote:
> > 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?
> 
> 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).

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

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

Yes, please update sfp_fixup_halny_gsfp() as well.

Thanks.

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