Thread (14 messages) 14 messages, 2 authors, 2026-03-06

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

From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: 2026-01-15 07:49:32
Also in: lkml

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:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help