linux-kernel - Re: [PATCH net-next v2 09/13] net: phy: phylink: Use phy_caps

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: <20250226161637.58597e28@fedora.home>
Date: Wed, 26 Feb 2025 16:16:37 +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 v2 09/13] net: phy: phylink: Use
 phy_caps_lookup for fixed-link configuration

Hi Russell,

On Wed, 26 Feb 2025 14:01:57 +0000
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> Please use a subject line of "net: phylink: " for phylink patches, not
> "net: phy: " which is for phylib.

Sure thing, I wasn't sure about the subject line for this one.

> On Wed, Feb 26, 2025 at 11:09:24AM +0100, Maxime Chevallier wrote:
> > When phylink creates a fixed-link configuration, it finds a matching
> > linkmode to set as the advertised, lp_advertising and supported modes
> > based on the speed and duplex of the fixed link.
> > 
> > Use the newly introduced phy_caps_lookup to get these modes instead of
> > phy_lookup_settings(). This has the side effect that the matched
> > settings and configured linkmodes may now contain several linkmodes (the
> > intersection of supported linkmodes from the phylink settings and the
> > linkmodes that match speed/duplex) instead of the one from
> > phy_lookup_settings().
> > 
> > Signed-off-by: Maxime Chevallier <maxime.chevallier@...tlin.com>

[...]

> > @@ -879,8 +880,10 @@ static int phylink_parse_fixedlink(struct phylink *pl,
> >  	linkmode_copy(pl->link_config.advertising, pl->supported);
> >  	phylink_validate(pl, pl->supported, &pl->link_config);
> >  
> > -	s = phy_lookup_setting(pl->link_config.speed, pl->link_config.duplex,
> > -			       pl->supported, true);
> > +	c = phy_caps_lookup(pl->link_config.speed, pl->link_config.duplex,
> > +			    pl->supported, true);
> > +	if (c)
> > +		linkmode_and(match, pl->supported, c->linkmodes);  
> 
> What's this for? Surely phy_caps_lookup() should not return a link mode
> that wasn't in phy_caps_lookup()'s 3rd argument.

The new lookup may return a linkmode that wasn't in the 3rd argument,
as it will return ALL linkmodes that matched speed and duplex, provided
that at least one of said linkmodes matched the 3rd parameter.

Say you pass SPEED_1000, DUPLEX_FULL and a bitset containing only
1000BaseTFull, you'll get :

 - 1000BaseTFull, 1000BaseKX, 1000BaseT1, etc. in c->linkmodes.

That's the reason for re-andf'ing the modes afterwards.

If that API is too convoluted or error-prone, I can come up with an API
returning only what matched.

Maxime