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