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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Thu, Mar 05, 2026 at 05:35:50PM +0100, Maxime Chevallier wrote:
> 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@broadcom.com/

If they don't come up configured correctly, then how do commercial off
the shelf switches work with these modules?

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

Note that there is base.e100_base_fx and base.e100_base_lx, but also
base.e_base_px and base.e_base_bx10 which can also require 100BASE-X
provided the bitrate is for 100. It would be good to know what
capabilities your modules report.

(side note, I'm looking at:
        if ((id->base.e_base_px || id->base.e_base_bx10) && br_nom == 100) {
and wondering whether that should be 1.25x 100.)

I have some EEPROM dumps in my database for:

        Transceiver codes                         : 0x00 0x00 0x01 0x20 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : SONET: OC-3, short reach
        Transceiver type                          : Ethernet: 100BASE-FX
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x10 0x02 0x10 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : SONET: SONET reach specifier bit 1
        Transceiver type                          : SONET: OC-3, single mode, inter. reach
        Transceiver type                          : Ethernet: 100BASE-LX/LX10
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x00 0x01 0x10 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : SONET: OC-3, short reach
        Transceiver type                          : Ethernet: 100BASE-LX/LX10
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x00 0x00 0x40 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : Ethernet: BASE-BX10
        Encoding                                  : 0x02 (4B/5B)
        BR, Nominal                               : 100MBd

I don't have the actual modules though. I think all of these are
ones which require 100BASE-X rather than having a PHY.

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