netdev - Re: SFP and SFP+

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: <d1cd49e5-c2e4-4457-ad47-eb10e7044284@lunn.ch>
Date: Fri, 10 May 2024 22:37:59 +0200
From: Andrew Lunn <andrew@...n.ch>
To: James Dutton <james.dutton@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: SFP and SFP+

On Fri, May 10, 2024 at 03:10:06PM +0100, James Dutton wrote:
> Hi,
> 
> Linux kernel handling of SFP and SFP+ Ethernet transceivers does not
> seem to be very reliable.
> I.e. Very few SFP / SFP+ transceivers actually work in Linux, even if
> they work in a COTS network switch.
> For example, there are more and more Wireless access points appearing
> with SFP/SFP+ ports and run the Linux kernel.
> I think the main stumbling point is that the SFP/SFP+ quirks are based
> on the Name fields of the transceiver.
> I have seen two different SFP+ transceivers with exactly the same
> name, one supporting ROLLBALL and C46 and one supporting neither.
> Maybe it would be more reliable if one first assumed that the SFP does
> not do negotiation, C22, C46, ROLLBALL protocols and instead only
> reports link up / link down. One then implements methods to detect
> whether the transceiver does anything more feature rich, such as
> support for C22, C46 or ROLLBALL and if so, then uses those also.
> It seems like a majority of the problem ones are the ones that have
> one rate for the SERDES and another rate for the Link itself, with the
> transceiver doing rate adaption. This is most common for the RJ45
> SFP/SFP+ transceivers in the 10/100/1000/10000 speed range.
> It might also be helpful to report with ethtool the PHY Link rate as
> well as the SERDES rate and also report the link status of the PHY
> Link and SERDES link separately.
> 
> What is the view of people more expert than me on this list?

First step would be to Cc: the SFP Maintainer:

SFF/SFP/SFP+ MODULE SUPPORT
M:      Russell King <linux@...linux.org.uk>
L:      netdev@...r.kernel.org
S:      Maintained
F:      Documentation/devicetree/bindings/net/sff,sfp.yaml
F:      drivers/net/phy/phylink.c
F:      drivers/net/phy/sfp*
F:      include/linux/mdio/mdio-i2c.h
F:      include/linux/phylink.h
F:      include/linux/sfp.h
K:      phylink\.h|struct\s+phylink|\.phylink|>phylink_|phylink_(autoneg|clear|connect|create|destroy|disconnect|ethtool|helper|mac|mii|of|set|start|stop|test|validate)

Also, do you mean C45 instead of C46?

One part of the problem is that BaseT is simply not defined for
SFPs. Hence OEMs are doing whatever they want when it comes to
allowing access to the PHYs, and trying to make it as hard as possible
for interoperability, since they want vendor lock-in. So maybe you
should also be reaching out the people who write the multi-source
agreement and ask them to write a document about this?

	Andrew