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

[Russell King (Oracle)]

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. 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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!