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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <01ce4d48-6f64-4d90-9f87-ed1382fa57cf@bootlin.com>
Date: Thu, 15 Jan 2026 08:49:23 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: davem@...emloft.net, Andrew Lunn <andrew@...n.ch>,
 Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Jonas Jelonek <jelonek.jonas@...il.com>,
 Florian Fainelli <f.fainelli@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
 Simon Horman <horms@...nel.org>, Romain Gantois
 <romain.gantois@...tlin.com>, Marek Behún
 <kabel@...nel.org>, bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH net-next 2/6] net: phylink: Allow more interfaces in SFP
 interface selection

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