public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Björn Töpel" <bjorn@kernel.org>,
	"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"Donald Hunter" <donald.hunter@gmail.com>,
	"Eric Dumazet" <edumazet@google.com>,
	"Naveen Mamindlapalli" <naveenm@marvell.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Danielle Ratson" <danieller@nvidia.com>,
	"Hariprasad Kelam" <hkelam@marvell.com>,
	"Ido Schimmel" <idosch@nvidia.com>,
	"Kory Maincent" <kory.maincent@bootlin.com>,
	"Leon Romanovsky" <leon@kernel.org>,
	"Michael Chan" <michael.chan@broadcom.com>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Pavan Chebbi" <pavan.chebbi@broadcom.com>,
	"Piergiorgio Beruto" <piergiorgio.beruto@gmail.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Saeed Mahameed" <saeedm@nvidia.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Tariq Toukan" <tariqt@nvidia.com>,
	"Willem de Bruijn" <willemb@google.com>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next 02/11] ethtool: Add loopback netlink UAPI definitions
Date: Wed, 11 Mar 2026 19:47:16 -0700	[thread overview]
Message-ID: <20260311194716.600704aa@kernel.org> (raw)
In-Reply-To: <ed30934a-4931-40e5-a659-6fc8d12741b5@lunn.ch>

On Wed, 11 Mar 2026 16:30:03 +0100 Andrew Lunn wrote:
> > I like this. The nice thing is that since "name" is a string, we're not
> > locked into an enum -- drivers report what they have using 802.3
> > vocabulary, and we document the recommended names (pcs, pma, pmd, mii)
> > with references? That way it's unambiguous, but not too constrained.  
> 
> It is both good and bad. I expect some vendors will just ignore the
> text and use what their data sheet says, because they don't know
> better. An enum forces more consistency.

enum only enforces using a value from a fixed set. The uAPI itself
cannot enforce functional equivalence. Worst case this may result
in different vendors interpreting the enum differently. With a string
there's a better chance that even if not matching between the vendors
at least a user with a databook in hand will know exactly what the
Linux API will do.

Could someone please explain to me what the use case for
standardization of the enum values would be? I push hard for
standardization of stats, because with standard stats its easy to build
high level standard tools. I don't understand what value standardization
across vendors what the last step of the MAC is called brings us.
Please explain, and if we have a real use case in mind it should be
possible to write a selftest that verifies that use case is met by any
given device.

Which reminds me -- I was suggesting that we add an order / id to the
stages, not just name. Because AFAIU being able to request the loopback
"very last loopback point of MAC" or "first loopback point of PHY" is
something that should be doable without user having to parse the names
/ enums and understanding them.

  parent reply	other threads:[~2026-03-12  2:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 10:47 [PATCH net-next 00/11] ethtool: Generic loopback support Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 01/11] ethtool: Add dump_one_dev callback for per-device sub-iteration Björn Töpel
2026-03-12  2:32   ` Jakub Kicinski
2026-03-13 16:36     ` Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 02/11] ethtool: Add loopback netlink UAPI definitions Björn Töpel
2026-03-11  7:33   ` Maxime Chevallier
2026-03-11 10:39     ` Björn Töpel
2026-03-11 15:30       ` Andrew Lunn
2026-03-11 15:42         ` Maxime Chevallier
2026-03-11 19:37           ` Andrew Lunn
2026-03-12  2:47         ` Jakub Kicinski [this message]
2026-03-12 13:46           ` Andrew Lunn
2026-03-13  0:21             ` Jakub Kicinski
2026-03-11 10:50     ` Oleksij Rempel
2026-03-12  2:49       ` Jakub Kicinski
2026-03-11 15:22     ` Andrew Lunn
2026-03-11 15:35       ` Maxime Chevallier
2026-03-11 19:26         ` Andrew Lunn
2026-03-12  2:50           ` Jakub Kicinski
2026-03-12  5:04             ` Oleksij Rempel
2026-03-12  7:49               ` Maxime Chevallier
2026-03-12  8:46                 ` Oleksij Rempel
2026-03-12 13:34               ` Andrew Lunn
2026-03-12 13:51                 ` Oleksij Rempel
2026-03-12 16:39                 ` Maxime Chevallier
2026-03-13 19:11                   ` Björn Töpel
2026-03-15 15:09                     ` Oleksij Rempel
2026-03-15 16:20                       ` Björn Töpel
2026-03-18 15:59                     ` Andrew Lunn
2026-03-10 10:47 ` [PATCH net-next 03/11] ethtool: Add loopback GET/SET netlink implementation Björn Töpel
2026-03-12  2:51   ` [net-next,03/11] " Jakub Kicinski
2026-03-10 10:47 ` [PATCH net-next 04/11] ethtool: Add CMIS loopback helpers for module loopback control Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 05/11] selftests: drv-net: Add loopback driver test Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 06/11] ethtool: Add MAC loopback support via ethtool_ops Björn Töpel
2026-03-11  6:04   ` [PATCH 6/11] " Naveen Mamindlapalli
2026-03-10 10:47 ` [PATCH net-next 07/11] netdevsim: Add MAC loopback simulation Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 08/11] selftests: drv-net: Add MAC loopback netdevsim test Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 09/11] MAINTAINERS: Add entry for ethtool loopback Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 10/11] netdevsim: Add module EEPROM simulation via debugfs Björn Töpel
2026-03-12  2:52   ` [net-next,10/11] " Jakub Kicinski
2026-03-10 10:47 ` [PATCH net-next 11/11] selftests: drv-net: Add CMIS loopback netdevsim test Björn Töpel
2026-03-11  6:18 ` [PATCH net-next 00/11] ethtool: Generic loopback support Naveen Mamindlapalli
2026-03-11 10:24   ` Björn Töpel
2026-03-12  2:53 ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260311194716.600704aa@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=bjorn@kernel.org \
    --cc=danieller@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=hkelam@marvell.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kory.maincent@bootlin.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=michael.chan@broadcom.com \
    --cc=naveenm@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=piergiorgio.beruto@gmail.com \
    --cc=saeedm@nvidia.com \
    --cc=shuah@kernel.org \
    --cc=tariqt@nvidia.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox