netdev - Re: [PATCH net-next 03/13] net: phy: Introduce PHY ports representation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250211151723.22a922b0@fedora.home>
Date: Tue, 11 Feb 2025 15:17:23 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Kory Maincent <kory.maincent@...tlin.com>, davem@...emloft.net,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, thomas.petazzoni@...tlin.com, 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 15:04:27 +0100
Andrew Lunn <andrew@...n.ch> wrote:

> > With net drivers having PHY managed by the firmware or DSA, there is no linux
> > description of their PHYs.  
> 
> DSA should not be special, Linux is driving the PHY so it has to exist
> as a linux device.
> 
> Firmware is a different case. If the firmware has decided to hide the
> PHY, the MAC driver is using a higher level API, generally just
> ksetting_set etc. It would be up to the MAC driver to export its PHY
> topology and provide whatever other firmware calls are needed. We
> should keep this in mind when designing the kAPI, but don't need to
> actually implement it. The kAPI should not directly reference a
> phydev/phylink instance, but an abstract object which represents a
> PHY.

That's fine by me for the port representation, and I'm on the same page
here. In the end, the ways for a NIC to register its interfaces would
be :

 - phylib, as done in this series. The port is controlled by the PHY,
the phy_port_ops are implemented in the PHY driver + phylib, we
discover the ports based on what the PHY reports, the new port binding
and the presence of an SFP phandle under the PHY.

 - phylink, and what I mean by phylink is actually SFP (phylink is the
SFP upstream in PHY-less SFP setups, so it would create the phy_port,
nothing more). what we cover here are MACs that are connected directly
to an SFP cage. This is simply because phylink parses the sfp phandle,
so it's an easy spot to make sure we create the NIC's port without
rewriting all drivers.

 - NIC drivers themselves, for drivers that don't use phylink/phylib.

For now this series only has the "phy_add_port" kAPI, which only really
covers case 1. But netdev_add_port() can clearly be implemented as well.

I'm having a hard time splitting that work in digestable chunks :(
I've focused on PHY as a reference use for ports, but the end-goal
clearly is a generic way to expose what interfaces a netdev has, either
through PHY, SFP or firmware.

Thanks,

Maxime