Message-ID: <e38b51f0-b403-42b0-a8e5-8069755683f6@lunn.ch>
Date: Tue, 18 Nov 2025 14:50:33 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Alexander H Duyck <alexander.duyck@...il.com>
Cc: Lee Trager <lee@...ger.us>,
	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

> > As i said before, what is important is we have an architecture that
> > allows for PRBS in different locations. You don't need to implement
> > all those locations, just the plumbing you need for your use case. So
> > MAC calling phylink, calling into the PCS driver. We might also need
> > some enumeration of where the PRBSes are, and being able to select
> > which one you want to use, e.g. you could have a PCS with PRBS, doing
> > SGMII connecting to a Marvell PHY which also has PRBS.
> 
> It seems to me like we would likely end up with two different setups.
> For the SerDes PHYs they would likely end up with support for many more
> test patterns than a standard Ethernet PHY would.
> 
> I know I had been looking at section 45.2.1.168 - 45.2.1.174 of the
> IEEE 802.3 spec as that would be the standard for a PMA/PMD interface,
> or section 45.2.3.17 - 45.2.3.20 for the PCS interface, as to how to do
> this sort of testing on Ethernet using a c45 PHY. I wonder if we
> couldn't use those registers as a general guide for putting together
> the interface to enable the PHY testing with the general idea being
> that the APIs should translate to similar functionality as what is
> exposed in the IEEE spec.

It probably needs somebody to look at the different PRBS and see what
is common and what is different. 802.3 is a good starting point.
If you look around you can find some Marvell documents:

https://www.mouser.com/pdfDocs/marvell-phys-transceivers-alaska-c-88x5113-datasheet-2018-07.pdf
https://www.marvell.com/content/dam/marvell/en/public-collateral/phys-transceivers/marvell-phys-transceivers-alaska-m-88e21x0-datasheet.pdf
https://www.marvell.com/content/dam/marvell/en/public-collateral/phys-transceivers/marvell-phys-transceivers-alaska-x-88x2222-datasheet.pdf

And there are other vendors:

https://www.ti.com/lit/ds/symlink/dp83tc811r-q1.pdf

But we should also make use of the flexibility of netlink. We can
probably get a core set of attributes, but maybe also allow each PRBS
to make use of additional attributes?

> It isn't so much hard wired as limited based on the cable connected to
> it. In addition the other end doesn't do any sort of autoneg.

For PRBS, i doubt you want negotiation. Do you actually have a link
partner? Or it is some test equipment? If you are tuning SERDES
windows/eyes, you have to assume you are going to make the link worse,
before it gets better, and so autoneg will fail. So i expect the
general case of anybody using PRBS is going to want to use 'ethtool -s
autoneg off' to force the system into a specific mode.

> As far as the testing itself, we aren't going to be linking anyway. So
> the configured speed/duplex won't matter.

I'm surprised about that. Again, general case, would a 1G 1000baseX
allow/require different tuning to a 2500BaseX link? It is clocked at a
different frequency? Duplex however is probably not an issue, does an
SGMII SERDES running at 100Half even look different to a 100Full? The
SERDES always runs at the same speed, 10/100 just require symbol
duplication to full the stream up to 1G. And link modes > 1G don't
have a duplex setting.

> When we are testing either
> the PCS or the PMA/PMD is essentially running the show and everything
> above it is pretty much cut off. So the MAC isn't going to see a link
> anyway. In the grand scheme of things it is basically just a matter of
> setting up the lanes and frequency/modulation for those lanes.

And the kernel API for that, at the top level is ksettings_set(). I
agree the MAC is not sending packets etc, but it is the one
configuring everything below it, via phylink/phylib or firmware. Is
there really any difference between a real configuration and a PRBS
configuration for testing a link mode?

And then we need a second API to access whatever you want to tune,
which i guess is vendor specific. As far as i remember, Lee's basic
design did separate this into a different API after looking around at
what different vendors provided.

> This is one of the reasons why I was thinking of something like a
> phydev being provided by the driver. Specifically it provides an
> interface that can be inspected by a netdev via standard calls to
> determine things like if the link is allowed to come up. In the case of
> the phydev code it already had all the bits in place for PHY_CABLETEST
> as a state.

And this is why i talked about infrastructure, or core for PRBS,
something which can deal with a netdev state transitions. A don't see
a phydev as a good representation of a PRBS. We probably want a PRBS
'device' which can be embedded in a phydev, or a PCS, or a generic
PHY, which registers itself to the PRBS core, and it is associated to
a netdev.

	Andrew

Powered by blists - more mailing lists