Message-ID: <aXDreiHjK06lHY9h@shell.armlinux.org.uk>
Date: Wed, 21 Jan 2026 15:06:34 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Josua Mayer <josua@...id-run.com>, Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next v2 1/2] net: phy: marvell: 88e1111: define
 gigabit features

On Mon, Jan 19, 2026 at 10:27:52AM +0100, Maxime Chevallier wrote:
> Hi Russell, Josua,
> 
> On 02/01/2026 13:47, Russell King (Oracle) wrote:
> 
> > If the operational mode of the PHY is reconfigured at runtime, then I
> > think it would be reasonable to re-read the supported linkmodes.
> > However, I think this will cause issues for phylink, as currently it
> > wants to know the link modes that are supported so it can choose an
> > appropriate interface mode.
> 
> Russell, I agree that your patches for phydev->supported_interfaces
> are required, but I also think we need another piece of the puzzle to
> solve Josua's issue.

I haven't had the time to respond until now, sorry (it's been total
chaos over the last few days.)

> From what I get, it's impossible from the PHY driver's perspective only,
> to know which configuration the PHY is in, i.e. is it in :
> 
>  1000X to 1000T
>  SGMII to 1000T
>  SGMII to something else ?

Note that phydev->supported_interfaces is only about the host side
interface.

> This is one of the issues I was facing with the SGMII to 100FX adapters.
> 
> Selecting the right phy_interface, is one thing, but it doesn't address
> the fact that whe don't know which linkmodes to put in phydev->supported.
> 
> The approach I took to address that is in patch 3 of this series [1] :
> 
>  - The SFP's eeprom should ideally store information about the MDI of the
>   module, is it outputing fiber at 1G, at 100M, is it BaseT, etc.

While they do, it's the EEPROM is horrendously unreliable. I had hoped
that Fibrestore would do better, but sadly not - it's the same rubbish
I've come to expect from SFP vendors.

>From my database, for copper RJ45 SFPs, the majority specify their
connector as LC. Then, the next is RJ45 (correct) and finally "unknown".

I don't have enough 100FX SFPs to base any data upon.

Cabled SFPs seem to do well, 100% of those I have are "Copper pigtail".

Fibre SFPs seem to all state LC as well.

xPON SFPs... are basically a total mess.

For the transceiver codes, it's even worse.

Cabled SFPs again do well, 100% indicate that they're some kind of
cable, but not all of them provide all the capabilities you'd expect.

Fibre SFPs... yea, random.

Copper RJ45 SFPs... can look like fibre, fibrechannel, but may also
state a copper based type.

xPON... total trainwreck, Some gives some kind of random fibre types,
some even give copper types. Some basically state they support every
transceiver type out there.

If you want to try and work out what the media side should be, then
I think we're basically going to end up needing our own database for
every transceiver out there... which leads us towards the model that
vendors use: only accepting transceivers we know about (which leads
to claims of "vendor lock-in" for this technology.)

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

Powered by blists - more mailing lists