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: <57aa6516-ae7d-4d8d-9ae4-70bd6557547f@bootlin.com>
Date: Wed, 19 Nov 2025 14:29:09 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 thomas.petazzoni@...tlin.com, Andrew Lunn <andrew@...n.ch>,
 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 v16 02/15] net: ethtool: Introduce
 ETHTOOL_LINK_MEDIUM_* values

Hi Jakub,

On 19/11/2025 04:15, Jakub Kicinski wrote:
> On Thu, 13 Nov 2025 09:14:04 +0100 Maxime Chevallier wrote:
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index c2d8b4ec62eb..ad2b5ed9522b 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -216,13 +216,26 @@ static inline u8 *ethtool_rxfh_context_key(struct ethtool_rxfh_context *ctx)
>>  void ethtool_rxfh_context_lost(struct net_device *dev, u32 context_id);
>>  
>>  struct link_mode_info {
>> -	int                             speed;
>> -	u8                              lanes;
>> -	u8                              duplex;
>> +	int	speed;
>> +	u8	lanes;
>> +	u8	min_pairs;
>> +	u8	pairs;
>> +	u8	duplex;
>> +	u16	mediums;
>>  };
>>  
>>  extern const struct link_mode_info link_mode_params[];
>>  
>> +extern const char ethtool_link_medium_names[][ETH_GSTRING_LEN];
>> +
>> +static inline const char *phy_mediums(enum ethtool_link_medium medium)
>> +{
>> +	if (medium >= __ETHTOOL_LINK_MEDIUM_LAST)
>> +		return "unknown";
>> +
>> +	return ethtool_link_medium_names[medium];
>> +}
> 
> Will this function be called by a lot of drivers? Would be great to
> find a more suitable place for it, ethtool.h is included by thousands
> of objects :(

I expect this to be mostly used by the current DT parsing code, as well
as a few print statements in the core. So indeed let's move this
somewhere more specific.

> 
>>  /* declare a link mode bitmap */
>>  #define __ETHTOOL_DECLARE_LINK_MODE_MASK(name)		\
>>  	DECLARE_BITMAP(name, __ETHTOOL_LINK_MODE_MASK_NBITS)
>> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
>> index 8bd5ea5469d9..6ed235053aed 100644
>> --- a/include/uapi/linux/ethtool.h
>> +++ b/include/uapi/linux/ethtool.h
>> @@ -2587,4 +2587,24 @@ enum phy_upstream {
>>  	PHY_UPSTREAM_PHY,
>>  };
>>  
>> +enum ethtool_link_medium {
>> +	ETHTOOL_LINK_MEDIUM_BASET = 0,
>> +	ETHTOOL_LINK_MEDIUM_BASEK,
>> +	ETHTOOL_LINK_MEDIUM_BASES,
>> +	ETHTOOL_LINK_MEDIUM_BASEC,
>> +	ETHTOOL_LINK_MEDIUM_BASEL,
>> +	ETHTOOL_LINK_MEDIUM_BASED,
>> +	ETHTOOL_LINK_MEDIUM_BASEE,
>> +	ETHTOOL_LINK_MEDIUM_BASEF,
>> +	ETHTOOL_LINK_MEDIUM_BASEV,
>> +	ETHTOOL_LINK_MEDIUM_BASEMLD,
>> +	ETHTOOL_LINK_MEDIUM_NONE,
>> +
>> +	__ETHTOOL_LINK_MEDIUM_LAST,
>> +};
> 
> Why is this in uAPI? I'd have expected it to either exist in the YAML
> spec if there's a new uAPI that needs it, or in kernel headers.
> Let's move it out for now to be safe, we can always move it in.

I originally planned to report that in linkmodes et.al. but changed my
mind, let me move that out as well.

> 
>> +#define ETHTOOL_MEDIUM_FIBER_BITS (BIT(ETHTOOL_LINK_MEDIUM_BASES) | \
>> +				   BIT(ETHTOOL_LINK_MEDIUM_BASEL) | \
>> +				   BIT(ETHTOOL_LINK_MEDIUM_BASEF))
> 
> Ditto.

Thanks for taking a look,

Maxime

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ