netdev - Re: [PATCH net-next v14 03/16] net: ethtool: Introduce ETHTOOL_LINK_MEDIUM

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: <d798cbb4-74f8-47fd-98e8-0d6d6e9f8621@bootlin.com>
Date: Thu, 23 Oct 2025 09:43:23 +0200
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>,
 Florian Fainelli <florian.fainelli@...adcom.com>
Subject: Re: [PATCH net-next v14 03/16] net: ethtool: Introduce
 ETHTOOL_LINK_MEDIUM_* values

Hi Andrew,

On 22/10/2025 23:42, Andrew Lunn wrote:
> On Mon, Oct 13, 2025 at 04:31:29PM +0200, Maxime Chevallier wrote:
>> In an effort to have a better representation of Ethernet ports,
>> introduce enumeration values representing the various ethernet Mediums.
>>
>> This is part of the 802.3 naming convention, for example :
>>
>> 1000 Base T 4
>>  |    |   | |
>>  |    |   | \_ lanes (4)
>>  |    |   \___ Medium (T == Twisted Copper Pairs)
>>  |    \_______ Baseband transmission
>>  \____________ Speed
> 
> Dumb question. Does 802.3 actually use the word lanes here?

Depending on the mode, 802.3 uses either "pair" or "lane" :

1.4.13 1000BASE-T: IEEE 802.3 Physical Layer specification for a
1000 Mb/s CSMA/CD LAN using four pairs of Category 5 balanced
copper cabling.

1.4.26 100GBASE-CR2: IEEE 802.3 Physical Layer specification for
100 Gb/s using 100GBASE-R encoding over two lanes of shielded
balanced copper cabling.

> I'm looking at the commit which added lanes:
> 
> commit 012ce4dd3102a0f4d80167de343e9d44b257c1b8
> 
>     Add 'ETHTOOL_A_LINKMODES_LANES' attribute and expand 'struct
>     ethtool_link_settings' with lanes field in order to implement a new
>     lanes-selector that will enable the user to advertise a specific number
>     of lanes as well.
> 
>     $ ethtool -s swp1 lanes 4
>     $ ethtool swp1
>       Settings for swp1:
>             Supported ports: [ FIBRE ]
>             Supported link modes:   1000baseKX/Full
>                                     10000baseKR/Full
>                                     40000baseCR4/Full
>                                     40000baseSR4/Full
>                                     40000baseLR4/Full
>                                     25000baseCR/Full
>                                     25000baseSR/Full
>                                     50000baseCR2/Full
>                                     100000baseSR4/Full
>                                     100000baseCR4/Full
>             Supported pause frame use: Symmetric Receive-only
>             Supports auto-negotiation: Yes
>             Supported FEC modes: Not reported
>             Advertised link modes:  40000baseCR4/Full
>                                     40000baseSR4/Full
>                                     40000baseLR4/Full
>                                     100000baseSR4/Full
>                                     100000baseCR4/Full
> 
> 
> For these link modes we are talking about 4 PCS outputs feeding an
> SFP module. The module when has one fibre pair, the media.
> 
> For baseT4 what you call a lane is a twisted pair, the media.
> 
> These two definitions seem to contradict each other.
> 
> For SGMII, 1000BaseX, we have 1 PCS lane, feeding a PHY with 4 pairs.
> 
> It gets more confusing at 10G, where the MAC might have 4 lanes
> feeding 4 pairs, or 1 lane feeding 4 pairs.
> 
> Also, looking at the example above, if i have a MAC/PHY combination
> which can do 10/100/1G and i did:
> 
>     $ ethtool -s swp1 lanes 2
> 
> would it then only advertise 10 and 100, since 1G need four 'lanes'?

Ah right ! Yeah so lanes isn't about the MDI directly then, so
clearly this won't work :(
> 
> Is reusing lanes going to cause us problems in the future, and maybe
> we should add a pairs member, to represent the media? And we can
> ignore bidi fibre modules for the moment :-)

That's a very good point, I think this makes more sense. I've also
seen the word "channel" around, but Pair would be more explicit.

thanks for the feedback !

Maxime
> 
>        Andrew