Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP interface selection

[Maxime Chevallier]

Hi Russell,

On 05/03/2026 16:05, Russell King (Oracle) wrote:
> On Fri, Feb 13, 2026 at 09:41:43AM +0100, Maxime Chevallier wrote:
>> Hi Russell,
>>
>> On 15/01/2026 00:30, Russell King (Oracle) wrote:
>>> On Wed, Jan 14, 2026 at 11:57:24PM +0100, Maxime Chevallier wrote:
>>>> When phylink handles an SFP module that contains a PHY, it selects a
>>>> phy_interface to use to communicate with it. This selection ensures that
>>>> the highest speed gets achieved, based on the linkmodes we want to
>>>> support in the module.
>>>>
>>>> This approach doesn't take into account the supported interfaces
>>>> reported by the module
>>>
>>> This is intentional by design, because the capabilities of the PHY
>>> override in this case. Unfortunately, as I've said previously, the
>>> rush to throw in a regurgitated version of my obsoleted
>>> "host_interfaces" rather messed up my replacement patch set which
>>> had the PHY driver advertising the interface capabilities of the
>>> PHY, which were then going to be used to make the PHY interface
>>> selection when attaching the PHY.
>>>
>>> I've still got the code, but I can't now push it into mainline
>>> because, with the obsolete host_interfaces stuff merged, we will end
>>> up with two competing solutions.
>>>
>>> In any case, I really would appreciate people looking through
>>> http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
>>>
>>> before doing development on SFP and phylink to see whether I've
>>> already something that solves their issue. Quite simply, I don't have
>>> the time to push every patch out that I have, especially as I'm up to
>>> my eyeballs with the crappy stmmac driver now, but also because I
>>> have work items from Oracle that reduce the time I can work on
>>> mainline.
>>
>> net-next being closed, I was going through my backlog and I was thinking
>> about giving this series another go after net-next re-opens, I'd like to
>> sync with you about the way forward.
>>
>> In your tree there's :
>>
>> net: phylink: use phy interface mode bitmaps for SFP PHYs	
>> net: phy: add supported_interfaces to Aquantia AQR113C
>> net: phy: add supported_interfaces to marvell10g PHYs
>> net: phy: add supported_interfaces to marvell PHYs
>> net: phy: add supported_interfaces to bcm84881
>> net: phy: add supported_interfaces to phylib
>>
>> These would be pre-requisites for the 100FX-SGMII SFP support, as the
>> interface resolution currently doesn't elect SGMII for 100FX modules.
>>
>> That would require some changes to the current host_interfaces API as
>> well, potentially replacing it altogether.
>>
>> Is this something you can do, or can I get your permission to submit
>> these (ofc maybe with more stuff to deal with host_interfaces)
> 
> One of the issues that will need to be solved is how to tell
> 100FX-SGMII (e.g. https://www.fs.com/uk/products/37770.html) which need
> SGMII apart from 100FX modules that don't (e.g.
> https://www.fs.com/uk/products/37324.html)
> 
> host_interfaces don't satisfy that, because this has nothing to do with
> what the host can do. Either the module has a PHY and uses SGMII on
> the host side, or it doesn't have a PHY in which case 100BASE-X needs
> to be used. If we have a PHY, then we will work out using what we
> already have.
> 
> Given that 100FX-SGMII, the PHY _should_ be coming up in SGMII mode,
> so that's what we need to use to talk to them.

_should_ indeed. All modules I got required some level of configuration
of the internal PHY for it to work, and without Florian's help [1] on
how to setup the broadcom PHY in SGMII to 100FX mode, all the modules I
tried were just fancy paperweights :(

[1] : https://lore.kernel.org/netdev/24146e10-5e9c-42f5-9bbe-fe69ddb01d95@xxxxxxxxxxxx/

> If we change the PHY's
> mode to something else, we get into the horrid problems that is rate
> matching, which gives us the problem that we don't have very good
> support for that (e.g. PHYs that require the MAC to pace the transmit
> rate.)
> 
> I suspect there is no way to tell these SFPs apart using the EEPROM,
> which means we're left with the "does this module that looks like a
> optical module have a PHY?" problem that we already use for copper
> SFPs. If there's no detectable PHY, then we'd likely have to assume
> that the SFP requires 100BASE-X.
> 

I agree with that completely. From the few such modules I have, we don't
have much to work with in the eeprom to come-up with a proper generic
support for these.

I see no way around that other than probing for a PHY for every 100FX
module, and see what we get. Alternatively, we could rely on fixups
and have that internal hardcoded database of supported modules ?

Maxime