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

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

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.

OK makes sense. Just to summarize my understanding, let me know if
I'm wrong there :

 - The interfaces list we have in sfp_module_caps is to be used when we 
   don't have a PHY in the module (there may be one, but we don't
   know/care about it).

 - When we do have a PHY, we _should_ select the interface based on what
   the MAC (+ PCS + Serdes etc.) can output on this sfp-bus and what
   the SFP PHY can take as an input. We ignore the sfp_module_caps
   interfaces list.

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

So what's the plan there ? This work here is kinda low priority
for me, I wanted to get this out there before continuing with
phy_port followup. Without this patch though, this whole series
is blocked as SGMII will never be selected for 100FX modules.

With your permission, can I pick up your patchs for supported_interfaces
and see what I can do from there ? I also found host_interfaces to be
not enough there.

Knowing that for me, phy_port is the priorty, this is going to be
something I'll do on my free time so don't expect fast progress :(

> 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. BTW, the "age" stated in cgit is based on the commit time
> (which gets reset when rebased) not the initial merge time. You will
> see that the "supported_interfaces" stuff dates from 2019, not 2025.

Besides that part, will you take a look at the rest of the series ? I'm
not saying that to rush you, but this whole SGMII to 100Fx journey seemed
to me that a lot of hacky stuff, I'd like to get your opinion on the rest
before iterating and facing anther blocking problem down the line on
another part of that series.

I know you have a lot on your plate, but as I said, this series is probably
going to move slowly anyways :)

Maxime