Message-ID: <20250211145228.06408469@kmaincent-XPS-13-7390>
Date: Tue, 11 Feb 2025 14:52:28 +0100
From: Kory Maincent <kory.maincent@...tlin.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: davem@...emloft.net, 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>,
 Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit
 <hkallweit1@...il.com>, Vladimir Oltean <vladimir.oltean@....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>
Subject: Re: [PATCH net-next 03/13] net: phy: Introduce PHY ports
 representation

On Tue, 11 Feb 2025 14:42:43 +0100
Maxime Chevallier <maxime.chevallier@...tlin.com> wrote:

> Hi Köry,
> 
> On Tue, 11 Feb 2025 14:32:09 +0100
> Kory Maincent <kory.maincent@...tlin.com> wrote:
> 
> > On Fri,  7 Feb 2025 23:36:22 +0100
> > Maxime Chevallier <maxime.chevallier@...tlin.com> wrote:
> >   
> > > Ethernet provides a wide variety of layer 1 protocols and standards for
> > > data transmission. The front-facing ports of an interface have their own
> > > complexity and configurability.
> > > 
> > > Introduce a representation of these front-facing ports. The current code
> > > is minimalistic and only support ports controlled by PHY devices, but
> > > the plan is to extend that to SFP as well as raw Ethernet MACs that
> > > don't use PHY devices.
> > > 
> > > This minimal port representation allows describing the media and number
> > > of lanes of a port. From that information, we can derive the linkmodes
> > > usable on the port, which can be used to limit the capabilities of an
> > > interface.
> > > 
> > > For now, the port lanes and medium is derived from devicetree, defined
> > > by the PHY driver, or populated with default values (as we assume that
> > > all PHYs expose at least one port).
> > > 
> > > The typical example is 100M ethernet. 100BaseT can work using only 2
> > > lanes on a Cat 5 cables. However, in the situation where a 10/100/1000
> > > capable PHY is wired to its RJ45 port through 2 lanes only, we have no
> > > way of detecting that. The "max-speed" DT property can be used, but a
> > > more accurate representation can be used :
> > > 
> > > mdi {
> > > 	port@0 {
> > > 		media = "BaseT";
> > > 		lanes = <2>;
> > > 	};
> > > };
> > > 
> > > From that information, we can derive the max speed reachable on the
> > > port.
> > > 
> > > Another benefit of having that is to avoid vendor-specific DT properties
> > > (micrel,fiber-mode or ti,fiber-mode).
> > > 
> > > This basic representation is meant to be expanded, by the introduction
> > > of port ops, userspace listing of ports, and support for multi-port
> > > devices.    
> > 
> > This patch is tackling the support of ports only for the PHY API. Keeping in
> > mind that this port abstraction support will also be of interest to the
> > NICs. Isn't it preferable to handle port in a standalone API?  
> 
> The way I see it, nothing prevents from using the port definition in
> ethernet-port.yml in DSA/raw nics.
> 
> > With net drivers having PHY managed by the firmware or DSA, there is no
> > linux description of their PHYs. On that case, if we want to use port
> > abstraction, what is the best? Register a virtual phy_device to use the
> > abstraction port or use the port abstraction API directly which meant that
> > it is not related to any PHY?  
> 
> I think the next steps will be to have net_device have a list of ports
> (maintained in the phy_link_topology) that aggregates ports from all
> its PHYs/SFPs/raw interfaces. in that case net_device will be the
> direct parent. I haven't worked on the bindings for that though,
> especially for DSA :'(

Having it under phy_link_topology is a great idea!
 
> I don't think the virtual phydev is going to be helpful. I'm hitting
> the 15 patches limit, but a possible extension is to make so that
> phylink also creates a port when it finds an SFP (hence, when upstream
> is a MAC).

I would say not only for SFP but phylink should create a port when it can find
a mdi description in the devicetree. Port with PoE, leds or whatever future
supported features should be created by phylink. 

> This is why phy_port has these fields :
> 
> 
> enum phy_port_parent {
> 	PHY_PORT_PHY,
> };
> 
> struct phy_port {
> 	...
> 	enum phy_port_parent parent_type;
> 	union {
> 		struct phy_device *phy;
> 	};
> 
> };
> 
> The parent type may (will) be extended with PORT_PHY_MAC, and that's
> also why the parent pointer is in a union :)

Ok for me!
 
> I'm trying hard to make so that phy_port doesn't depend on phylib
> (altough, phylib depends on phy_port). There's a dependency on some
> core stuff (converting from medium => linkmodes) and phylink
> (converting the interfaces list to linkmodes), but we can extract these
> fairly easily.
> 
> You're correct in that for now, the integration is with phylib only
> though, but let's make sure this will also work for phy-less devices.
> 
> Thanks a lot for your input,

Thanks for your work, it will be really helpful to add support for PoE in DSA. 

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Powered by blists - more mailing lists