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: <cb217bf8-763e-4c48-9233-e577b32b14a8@lunn.ch>
Date: Wed, 22 Oct 2025 23:42:24 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
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

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?

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'?

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 :-)

       Andrew