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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SN6PR1901MB4654B995FBAFAC7298C7C6A3A575A@SN6PR1901MB4654.namprd19.prod.outlook.com>
Date: Tue, 10 Jun 2025 22:43:31 -0500
From: Chris Morgan <macromorgan@...mail.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 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.

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

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

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