linux-kernel - Re: [PATCH net-next 01/13] net: phy: Extract the speed/duplex to linkmode conversion from phylink

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: <20250224151330.2e0d95e4@fedora>
Date: Mon, 24 Feb 2025 15:13:30 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: davem@...emloft.net, Andrew Lunn <andrew@...n.ch>, Jakub Kicinski
 <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Heiner Kallweit <hkallweit1@...il.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 thomas.petazzoni@...tlin.com, linux-arm-kernel@...ts.infradead.org,
 Christophe Leroy <christophe.leroy@...roup.eu>, Herve Codina
 <herve.codina@...tlin.com>, Florian Fainelli <f.fainelli@...il.com>,
 Vladimir Oltean <vladimir.oltean@....com>, Köry Maincent
 <kory.maincent@...tlin.com>, Oleksij Rempel <o.rempel@...gutronix.de>,
 Simon Horman <horms@...nel.org>, Romain Gantois
 <romain.gantois@...tlin.com>
Subject: Re: [PATCH net-next 01/13] net: phy: Extract the speed/duplex to
 linkmode conversion from phylink

On Mon, 24 Feb 2025 14:01:11 +0000
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> On Sat, Feb 22, 2025 at 03:27:13PM +0100, Maxime Chevallier wrote:
> > Phylink uses MAC capabilities to represent the Pause, AsymPause, Speed
> > and Duplex capabilities of a given MAC device. These capabilities are
> > used internally by phylink for link validation and get a coherent set of
> > linkmodes that we can effectively use on a given interface.
> > 
> > The conversion from MAC capabilities to linkmodes is done in a dedicated
> > function, that associates speed/duplex to linkmodes.
> > 
> > As preparation work for phy_port, extract this logic away from phylink
> > and have it in a dedicated file that will deal with all the conversions
> > between capabilities, linkmodes and interfaces.  
> 
> Fundamental question: why do you want to extract MAC capabilities from
> phylink?
> 
> At the moment, only phylink uses the MAC capabilities (they're a phylink
> thing.) Why should they be made generic, and what use will they be
> applied to as something generic?
> 
> If there's no answer for that, then I worry that they'll get abused.
> 

I only have a blurry answer for you, so that probably wont cut it, but
for phy_port (which I have ready) and stackable PHY support (which I
have not), I foresee that we may need to specify what can the PHY do on
its MII serdes port.

TBH the only real stuff that will be needed is "Given a set of
phy_interface_t supported by a PHY downstream port, what linkmodes can
we get out of these". The phylink code uses the mac_capabilities as an
intermediate between phylink_get_capabilities and
phylink_caps_to_linkmodes(). Given that this series introduces very very
similar enums in the form of the LINK_CAPA_XXX, we might be able to
keep the MAC_CAPABILITIES a phylink-specific set of values. I can
include that in V2.

Maxime