[PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL

[PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL

[Michael Walle]

The FCLF8521P2BTL is marketed as a drop in replacement for fiber
modules using 1000Base-X autoneg towards the host as default. See the
referenced application note, esp. question #11. Drop the 1000baseT
capability, so 1000Base-X will eventually be used.

This is esp. important if the TX_DISABLE pin is not connected on a
board. Usually, pin is used as a reset line to the PHY on the copper
SFP. If a bootloader expects the default mode and doesn't do any
reconfiguration of the SFP module, a link might not be established.

Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
I'm not sure, this is the correct place for the fix, nor if it goes in
the right direction. There is a comment in

/*
 * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
 * negotiation enabled, but some may be in 1000base-X - which is for the
 * PHY driver to determine.
 */

I haven't found any traces of that though. So any pointers, what flags
have to be modified is appreciated (phydev->supported?
phydev->possible_interfaces?).

I also compared the EEPROMs of both a FCLF-8520-3 and a FCLF-8521-3 (I
don't have a FCLF8520P2BTL) and they are the same except for the P/N and
the serial number. So they both advertise the same capabilites. Although
I'd suspect that the power-on strapping is different and could be read
by the PHY driver.
---
 drivers/net/phy/sfp.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index b9d84612ac6f..387753cb5c62 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -478,6 +478,16 @@ static void sfp_quirk_2500basex(const struct sfp_eeprom_id *id,
 	__set_bit(PHY_INTERFACE_MODE_2500BASEX, caps->interfaces);
 }
 
+static void sfp_quirk_no_sgmii(const struct sfp_eeprom_id *id,
+			       struct sfp_module_caps *caps)
+{
+	linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
+			   caps->link_modes);
+	linkmode_clear_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+			   caps->link_modes);
+	__clear_bit(PHY_INTERFACE_MODE_SGMII, caps->interfaces);
+}
+
 static void sfp_quirk_disable_autoneg(const struct sfp_eeprom_id *id,
 				      struct sfp_module_caps *caps)
 {
@@ -539,6 +549,10 @@ static const struct sfp_quirk sfp_quirks[] = {
 	// PHY.
 	SFP_QUIRK_F("FS", "SFP-10G-T", sfp_fixup_fs_10gt),
 
+	// These are sold as 1000base-X compatible. Thus, make sure we don't
+	// use SGMII.
+	SFP_QUIRK_S("FINISAR CORP.", "FCLF8521P2BTL", sfp_quirk_no_sgmii),
+
 	// Fiberstore SFP-2.5G-T and SFP-10GM-T uses Rollball protocol to talk
 	// to the PHY and needs 4 sec wait before probing the PHY.
 	SFP_QUIRK_F("FS", "SFP-2.5G-T", sfp_fixup_rollball_wait4s),
-- 
2.47.3

Re: [PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL

[Andrew Lunn]

On Tue, Jul 14, 2026 at 02:49:34PM +0200, Michael Walle wrote:
> The FCLF8521P2BTL is marketed as a drop in replacement for fiber
> modules using 1000Base-X autoneg towards the host as default. See the
> referenced application note, esp. question #11. Drop the 1000baseT
> capability, so 1000Base-X will eventually be used.
> 
> This is esp. important if the TX_DISABLE pin is not connected on a
> board. Usually, pin is used as a reset line to the PHY on the copper
> SFP. If a bootloader expects the default mode and doesn't do any
> reconfiguration of the SFP module, a link might not be established.
> 
> Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> I'm not sure, this is the correct place for the fix, nor if it goes in
> the right direction. There is a comment in
> 
> /*
>  * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
>  * negotiation enabled, but some may be in 1000base-X - which is for the
>  * PHY driver to determine.
>  */

The reason Cisco SGMII is used is so you can support 10Mbps and
100Mbps, as well as 1G. If all you can do ix 1000BaseX, supporting
10/100 becomes harder. If the PHY is clever enough, it can send pause
frames to slow down the MAC. But that requires the PHY actually
converting the bitstream from the MAC back into packets, performing
packet buffering, and then creating the new bitstream at a lower
rate. Some multi-gigi PHYs do this, especially if they implement
MACSEC, but few 1G PHYs do.

Normally, if the PHY is in 1000BaseX, the PHY driver will try to
reconfigure it to SGMII. However, There are some SFPs which are stuck
in 1000BaseX, and there is no access to the PHY registers, so there is
nothing we can do.

Looking at the link you provided, this SFP has a Marvell 88E1111, and
its registers are available. So the Marvell PHY driver should
reconfigure it into SGMII mode.

Maybe look at the marvell PHY driver, and snoop what it does when it
configures the PHY.

	    Andrew

Re: [PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL

[Michael Walle]

Hi Andrew,

On Wed Jul 15, 2026 at 12:04 AM CEST, Andrew Lunn wrote:
> On Tue, Jul 14, 2026 at 02:49:34PM +0200, Michael Walle wrote:
>> The FCLF8521P2BTL is marketed as a drop in replacement for fiber
>> modules using 1000Base-X autoneg towards the host as default. See the
>> referenced application note, esp. question #11. Drop the 1000baseT
>> capability, so 1000Base-X will eventually be used.
>> 
>> This is esp. important if the TX_DISABLE pin is not connected on a
>> board. Usually, pin is used as a reset line to the PHY on the copper
>> SFP. If a bootloader expects the default mode and doesn't do any
>> reconfiguration of the SFP module, a link might not be established.
>> 
>> Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>> ---
>> I'm not sure, this is the correct place for the fix, nor if it goes in
>> the right direction. There is a comment in
>> 
>> /*
>>  * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
>>  * negotiation enabled, but some may be in 1000base-X - which is for the
>>  * PHY driver to determine.
>>  */
>
> The reason Cisco SGMII is used is so you can support 10Mbps and
> 100Mbps, as well as 1G. If all you can do ix 1000BaseX, supporting
> 10/100 becomes harder. If the PHY is clever enough, it can send pause
> frames to slow down the MAC. But that requires the PHY actually
> converting the bitstream from the MAC back into packets, performing
> packet buffering, and then creating the new bitstream at a lower
> rate. Some multi-gigi PHYs do this, especially if they implement
> MACSEC, but few 1G PHYs do.
>
> Normally, if the PHY is in 1000BaseX, the PHY driver will try to
> reconfigure it to SGMII. However, There are some SFPs which are stuck
> in 1000BaseX, and there is no access to the PHY registers, so there is
> nothing we can do.
>
> Looking at the link you provided, this SFP has a Marvell 88E1111, and
> its registers are available. So the Marvell PHY driver should
> reconfigure it into SGMII mode.

I figured that, but have a look at the commit message, the problem
is the non-existent TX_DISABLE line. So if linux would reconfigure
the PHY, the bootloader won't be able to use it anymore if it's not
doing a hardware reset (or reconfigure it on it's own).

I don't know what's the netdev position on that issue. You could
blame it on bad hardware. Or we could just reconfigure it if the
DT has a gpio phandle for the TX_DISABLE line, though that doesn't
mean that it is actually used to reset the module on a board reset,
or that the bootloader will do a reset.

-michael

>
> Maybe look at the marvell PHY driver, and snoop what it does when it
> configures the PHY.
>
> 	    Andrew

Re: [PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL

[Maxime Chevallier]

On 7/14/26 14:49, Michael Walle wrote:
> The FCLF8521P2BTL is marketed as a drop in replacement for fiber
> modules using 1000Base-X autoneg towards the host as default. See the
> referenced application note, esp. question #11. Drop the 1000baseT
> capability, so 1000Base-X will eventually be used.
> 
> This is esp. important if the TX_DISABLE pin is not connected on a
> board. Usually, pin is used as a reset line to the PHY on the copper
> SFP. If a bootloader expects the default mode and doesn't do any
> reconfiguration of the SFP module, a link might not be established.
> 
> Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> I'm not sure, this is the correct place for the fix, nor if it goes in
> the right direction. There is a comment in
> 
> /*
>  * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
>  * negotiation enabled, but some may be in 1000base-X - which is for the
>  * PHY driver to determine.
>  */
> 
> I haven't found any traces of that though. So any pointers, what flags
> have to be modified is appreciated (phydev->supported?
> phydev->possible_interfaces?).

Well I've tried in the past to change the resolution of the phy_interface_t
for a module, possible_interfaces won't work as this is populated too late
(at config init time), and we do the SFP interface resolution before that.

What we need is for PHYs to expose the list of interfaces they support at
drive-probe time.

Thing is, Russell has code for that :

http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue

but that code isn't upstream. I've tried to ask multiple times how we should
go forward with that, but with no reply :

https://lore.kernel.org/netdev/20260114225731.811993-3-maxime.chevallier@bootlin.com/

Russell's supported_interfaces approach works, I'm using that for SGMII to 100FX
modules, but the question is "how do we upstream that", especially with Russell
being away at the time :(

Maxime