netdev - Re: [PATCH ethtool-next] sff-8636: report LOL / LOS / Tx Fault

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: <ZINQ02Qrh/X+/Evy@shell.armlinux.org.uk>
Date: Fri, 9 Jun 2023 17:18:27 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jakub Kicinski <kuba@...nel.org>, mkubecek@...e.cz,
	danieller@...dia.com, idosch@...dia.com, netdev@...r.kernel.org,
	vladyslavt@...dia.com
Subject: Re: [PATCH ethtool-next] sff-8636: report LOL / LOS / Tx Fault

On Fri, Jun 09, 2023 at 05:31:42PM +0200, Andrew Lunn wrote:
> > I was asked if "Linux reports" this information.
> 
> Linux does, in /sys/kernel/debug/sfpX/status. It gives your the GPIOs
> value.

That's for SFPs, but I didn't work out a sane way to drive QSFPs. I did
make a start on the basic bare bones, and it would be nice to put more
time into it, but I need a greater understanding of how setups with
quad interfaces are modelled in the kernel - and that's something I
very little experience of.

My mental stumbling block is that quad interfaces seem to act as either
four separate network interfaces, or I think the lanes can be combined
to double or quadruple the data bandwidth. How this looks from the
firmware description perspective (in either DT or elsewhere) I don't
know. Can they be dynamically changed too?

It's relevant because QSFPs give status per individual lanes, so
anything bridging between the QSFP and a set of MACs needs to know
which lanes are associated with which MACs.

One of the SolidRun platforms I have does have a QSFP cage, and that's
where I made a start, but I very much feel that the canvas is blank
about how this should be modelled.

Now, as for SFPs, there's... the hardware signal state and software
signal state. The debugfs file you point at is merely for debug, it's
not an API (it's in debugfs!) We do report there the hardware and
software state. Whether we should have a proper API for that
information, and whether we should be able to reset the tx fault
state once it's happened too many times and we've locked out...
so far I don't think anyone has got to that point though.

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