linux-kernel - Re: [PATCH net-next v15 03/15] 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: <33bad77f-8468-4e4a-a60d-adf9e1145816@bootlin.com>
Date: Wed, 12 Nov 2025 09:23:21 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: 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>,
 Köry Maincent <kory.maincent@...tlin.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>,
 Daniel Golle <daniel@...rotopia.org>,
 Dimitri Fedrau <dimitri.fedrau@...bherr.com>
Subject: Re: [PATCH net-next v15 03/15] net: phy: Introduce PHY ports
 representation



On 11/11/2025 04:53, Andrew Lunn wrote:
>> +/**
>> + * phy_caps_medium_get_supported() - Returns linkmodes supported on a given medium
>> + * @supported: After this call, contains all possible linkmodes on a given medium,
>> + *	       and with the given number of lanes, or less.
> 
> lanes -> pairs?

indeed :(

> 
>> +	/* The PHY driver might have added, removed or set medium/lanes info,
>> +	 * so update the port supported accordingly.
> 
> lanes -> pairs?

yes true :(
> 
>> +struct phy_port *phy_of_parse_port(struct device_node *dn)
>> +{
>> +	struct fwnode_handle *fwnode = of_fwnode_handle(dn);
>> +	enum ethtool_link_medium medium;
>> +	struct phy_port *port;
>> +	const char *med_str;
>> +	u32 pairs = 0, mediums = 0;
>> +	int ret;
>> +
>> +	ret = fwnode_property_read_u32(fwnode, "pairs", &pairs);
>> +	if (ret)
>> +		return ERR_PTR(ret);
>> +
> 
> I think this needs to come later. It is not critical now, but when we
> come to add other medium, it will need moving. If we add say -K, and
> need lanes, we don't want to error out here because pairs is missing.

Ack, I'll relax the check

> 
>> +	ret = fwnode_property_read_string(fwnode, "media", &med_str);
>> +	if (ret)
>> +		return ERR_PTR(ret);
>> +
>> +	medium = ethtool_str_to_medium(med_str);
>> +	if (medium == ETHTOOL_LINK_MEDIUM_NONE)
>> +		return ERR_PTR(-EINVAL);
> 
>> +	if (pairs && medium != ETHTOOL_LINK_MEDIUM_BASET) {
>> +		pr_err("pairs property is only compatible with BaseT medium\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
> 
> This i think needs changing, if medium == ETHTOOL_LINK_MEDIUM_BASET
> then get pairs, and validate it. I would probably also test it is 1,
> 2, or 4.

That's fine by me :) I'll update the binding as well then, as having 3
pairs will never be correct.

Thanks a lot for looking at this !

Maxime

> 
> 	Andrew