netdev - Re: [REGRESSION] net: pcs-lynx: 10G SFP no longer links up

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: <aJtvE_yDGDyAfA5s@shell.armlinux.org.uk>
Date: Tue, 12 Aug 2025 17:42:59 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: Mathew McBride <matt@...verse.com.au>, netdev@...r.kernel.org,
	regressions@...ts.linux.dev
Subject: Re: [REGRESSION] net: pcs-lynx: 10G SFP no longer links up

On Tue, Aug 12, 2025 at 02:17:39PM +0200, Thorsten Leemhuis wrote:
> Lo!
> 
> On 10.07.25 07:29, Mathew McBride wrote:
> > Hi Russell,
> > 
> > On Wed, Apr 23, 2025, at 7:01 PM, Mathew McBride wrote:
> >>
> > [snip]
> > 
> > Just following up on this issue where directly connected SFP+ modules stopped linking up after the introduction of in-band capabilities.
> > 
> > The diff you provided below[1] resolved the issue. 
> > Were you planning on submitting it as a patch? If not, I'd be happy to send it in.
> 
> I might be missing something, but from here it looks like it fall
> through the cracks on Russell's side. This is nothing bad, this can
> happen, especially during summer and thus vacation time. I'd thus say:
> wait two or three days if this reminds him of the patch, otherwise go
> ahead and submit it yourself to get the regression fixed.

Yes, the reminder was sent during July when I wasn't looking at email,
and as you can imagine, if I spend three weeks on vacation, I am _not_
going to catch up with that pile of email - if I were, there'd be no
point taking vacation because the mental effort would be just the same
as having no vacation.

I have been debating whether we should actually do something like this,
especially given the issues with 2500base-X:

-       if (!phylink_validate_pcs_inband_autoneg(pl, interface,
-                                                config.advertising)) {
-               phylink_err(pl, "autoneg setting not compatible with PCS");
-               return -EINVAL;
+       while (!phylink_validate_pcs_inband_autoneg(pl, interface,
+                                                   config.advertising)) {
+               if (!test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
+                             config.advertising)) {
+                       phylink_err(pl, "autoneg setting is not compatible with PCS");
+                       return -EINVAL;
+               }
+
+               __clear_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, config.advertising);
        }

which turns it into something generic - but my problem with that is..
what if the module (e.g. a GPON module immitating a fibre module)
requires Autoneg but the PCS doesn't support Autoneg for the selected
interface mode.

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