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

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

On Mon, 24 Feb 2025 14:01:11 +0000
"Russell King (Oracle)" <linux@armlinux.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