Message-ID: <8015ec3f-778f-43e9-b91d-fe76b814157f@broadcom.com>
Date: Wed, 10 Sep 2025 15:19:28 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>, davem@...emloft.net
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, thomas.petazzoni@...tlin.com,
 Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Russell King <linux@...linux.org.uk>, linux-arm-kernel@...ts.infradead.org,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Herve Codina <herve.codina@...tlin.com>,
 Heiner Kallweit <hkallweit1@...il.com>,
 Vladimir Oltean <vladimir.oltean@....com>,
 Köry Maincent <kory.maincent@...tlin.com>,
 Marek Behún <kabel@...nel.org>,
 Oleksij Rempel <o.rempel@...gutronix.de>,
 Nicolò Veronese <nicveronese@...il.com>,
 Simon Horman <horms@...nel.org>, mwojtas@...omium.org,
 Antoine Tenart <atenart@...nel.org>, devicetree@...r.kernel.org,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 Romain Gantois <romain.gantois@...tlin.com>,
 Daniel Golle <daniel@...rotopia.org>,
 Dimitri Fedrau <dimitri.fedrau@...bherr.com>
Subject: Re: [PATCH net-next v12 00/18] net: phy: Introduce PHY ports
 representation

On 9/9/25 08:25, Maxime Chevallier wrote:
> Hi everyone,
> 
> Here is a V12 for the phy_port work, aiming at representing the
> connectors and outputs of PHY devices.
> 
> Last round was 16 patches, and now 18, if needed I can split some
> patches out such as the 2 phylink ones.
> 
> this V12 address the SFP interface selection for PHY driver SFPs, as
> commented by Russell on v10.
> 
> This and Rob's review on the dp83822 patch are the only changes.
> 
> As a remainder, a few important notes :
> 
>   - This is only a first phase. It instantiates the port, and leverage
>     that to make the MAC <-> PHY <-> SFP usecase simpler.
> 
>   - Next phase will deal with controlling the port state, as well as the
>     netlink uAPI for that.
> 
>   - The end-goal is to enable support for complex port MUX. This
>     preliminary work focuses on PHY-driven ports, but this will be
>     extended to support muxing at the MII level (Multi-phy, or compo PHY
>     + SFP as found on Turris Omnia for example).
> 
>   - The naming is definitely not set in stone. I named that "phy_port",
>     but this may convey the false sense that this is phylib-specific.
>     Even the word "port" is not that great, as it already has several
>     different meanings in the net world (switch port, devlink port,
>     etc.). I used the term "connector" in the binding.
> 
> A bit of history on that work :
> 
> The end goal that I personnaly want to achieve is :
> 
>              + PHY - RJ45
>              |
>   MAC - MUX -+ PHY - RJ45
> 
> After many discussions here on netdev@, but also at netdevconf[1] and
> LPC[2], there appears to be several analoguous designs that exist out
> there.
> 
> [1] : https://netdevconf.info/0x17/sessions/talk/improving-multi-phy-and-multi-port-interfaces.html
> [2] : https://lpc.events/event/18/contributions/1964/ (video isn't the
> right one)
> 
> Take the MAchiatobin, it has 2 interfaces that looks like this :
> 
>   MAC - PHY -+ RJ45
>              |
> 	    + SFP - Whatever the module does
> 
> Now, looking at the Turris Omnia, we have :
> 
> 
>   MAC - MUX -+ PHY - RJ45
>              |
> 	    + SFP - Whatever the module does
> 
> We can find more example of this kind of designs, the common part is
> that we expose multiple front-facing media ports. This is what this
> current work aims at supporting. As of right now, it does'nt add any
> support for muxing, but this will come later on.
> 
> This first phase focuses on phy-driven ports only, but there are already
> quite some challenges already. For one, we can't really autodetect how
> many ports are sitting behind a PHY. That's why this series introduces a
> new binding. Describing ports in DT should however be a last-resort
> thing when we need to clear some ambiguity about the PHY media-side.
> 
> The only use-cases that we have today for multi-port PHYs are combo PHYs
> that drive both a Copper port and an SFP (the Macchiatobin case). This
> in itself is challenging and this series only addresses part of this
> support, by registering a phy_port for the PHY <-> SFP connection. The
> SFP module should in the end be considered as a port as well, but that's
> not yet the case.
> 
> However, because now PHYs can register phy_ports for every media-side
> interface they have, they can register the capabilities of their ports,
> which allows making the PHY-driver SFP case much more generic.
> 
> Let me know what you think, I'm all in for discussions :)
> 
> Regards,

Tested-by: Florian Fainelli <florian.fainelli@...adcom.com>

Tested with bcmgenet which is single MAC + PHY using phylib.

Tested with bcm_sf2 which uses phylink and has a combination of internal 
and external PHYs.
--
Florian
-- 
Florian

Powered by blists - more mailing lists