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

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

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!