[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAMvbhHpj+HzmxnGfj_dKFq6nmnAr2C9v__1Ptkd19bnPCxd1w@mail.gmail.com>
Date: Fri, 10 May 2024 15:10:06 +0100
From: James Dutton <james.dutton@...il.com>
To: netdev@...r.kernel.org
Subject: SFP and SFP+
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?
Kind Regards
James
Powered by blists - more mailing lists