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] [day] [month] [year] [list]

Message-ID: <aEk-zY0gfGx-PPa6@shell.armlinux.org.uk>
Date: Wed, 11 Jun 2025 09:31:09 +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 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!