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

["Michael Walle" <mwalle@kernel.org>]

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