On Mon, 24 Feb 2025 14:01:11 +0000
"Russell King (Oracle)" [off-list ref] wrote:

On Sat, Feb 22, 2025 at 03:27:13PM +0100, Maxime Chevallier wrote:

quoted

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