Message-ID: <0d462aaa-7f41-4649-a665-de8a30a5b514@lunn.ch>
Date: Wed, 19 Nov 2025 15:20:06 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Lee Trager <lee@...ger.us>
Cc: Alexander Duyck <alexander.duyck@...il.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Susheela Doddagoudar <susheelavin@...il.com>,
	netdev@...r.kernel.org, mkubecek@...e.cz,
	Hariprasad Kelam <hkelam@...vell.com>,
	Alexander Duyck <alexanderduyck@...com>
Subject: Re: Ethtool: advance phy debug support

> Strictly speaking settings don't have to be mapped to ethernet
> configurations, at least not in our IP. I could use a 3 lane setup
> alternating between NRZ and PAM4 each with different TX coefficients despite
> this not making any sense. This is where the argument comes in that PRBS
> testing and TX coefficients don't belong in ethtool. The argument for
> putting everything in phy is to create a generic interface that works for
> all phys, not just ethernet. That would give us something like

Please could you always make it clear which definition of phy you are
using. generic phy, or phylib phy. Here you appear to be meaning
generic phy. For TX coefficients, that mostly makes sense to me.

There is maybe one exception i can think of, the Aquantia phylib
phy. You have a setup of a SoC with a MAC, PCS, SERDES lane, and then
a discrete aquantia BaseT PHY which has its own PCS and the all the
usual analogue stuff to put the bitstream on twisted pairs. There are
undocumented registers in phylib PHY to configuring the eye etc. There
currently are no phylib phys with embedded generic phys. There is no
reason it cannot be done, just nobody has done it so far. And there is
no reason this is special to the aquantia PHY, other phylib phys using
a SERDES towards the MAC could also have such registers.

> I don't think there is much value in that which is why I like creating an
> ethernet specific version. It makes a cleaner user interface which require
> less technical details from the user. I like piggy backing off of ethtool -s
> since users are custom to NIC speed, not lanes and mode. That would give us
> something like
> 
> ethtool -s eth42 100000baseCR2  - Test fbnic in PAM4 with 2 lanes

Yep, that i like.

> 
> ethtool --set-phy-tunable eth42 tx-coefficent 0 1 8 55 0 - Sets the
> tx-coefficent for PAM4, this way users doesn't have to know the mapping
> between mode and speed

And this i don't. --set-phy-tunable is for a phylib PHY. Its for a
device which converts a bitstream to analogue signals on twisted
pair. fbnic does not have such a device. What you do have is a generic
phy, even if currently you don't model it in Linux with an actual
generic phy. But that is 'just code'. And the generic phy API does
have some networking specific APIs, so i don't see why you cannot add
another API for enumerating and setting TX coefficients.

The other problem with what you have above is you only reference the
netdev, and not which of the multiple generic phys that netdev might
have. Think of the SoC-PCS-generic_phy-lane-generic_phy-PCS-BaseT
system above. Both the SoC and the phylib phy can have coefficient
registers. You need to enumerate which you want to set.

For a long time we had this same problem with phylib, a netdev can
have multiple phylib phys, but the kAPI had no way to indicate which
of those phys you wanted to configure. We mostly have that solved now,
but we should learn from that experience, and not repeat the same
problem.

> ethtool --start-prbs eth42 prbs31 - Start the PRBS31 test

and this has the same problem, which prbs associated to the netdev do
you want to run prb31? There could be one in the SoC PCS, the BaseT
PCS pointing back towards the Soc, and maybe in the BaseT PHY pointing
towards the line?

So you need something like

ethtool --list-prbs eth42

to list all the PRBSes associated to the netdev, maybe also listing
its capabilities. And then something like:

ethtool --start-prbs eth42 --prbs 1 --mode prbs31

to make use of the 1st PRBS, rather than the 0th.

	Andrew

Powered by blists - more mailing lists