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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ae41811-e16b-4e64-9fc4-9cb4ea1da697@lunn.ch>
Date: Tue, 11 Feb 2025 15:04:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: Maxime Chevallier <maxime.chevallier@...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

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

	Andrew