Message-ID: <401e9d39-2c28-480e-b1c4-d3601131c1fb@lunn.ch>
Date: Fri, 14 Nov 2025 14:58:12 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Lee Trager <lee@...ger.us>
Cc: 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

> I have PRBS testing and configuring TX coefficent support working in an
> internal version of the fbnic driver. The problem is the interface. Right
> now I'm using DebugFS, my understanding is write access in DebugFS is
> frowned upon which is why it hasn't been up streamed yet. My original idea
> was to extend ethtool, similar to what Susheela suggested, to add support
> but I got some push back on that at netdev.

I would say ethtool is the correct API to use. At minimum it needs to
be netlink.

> I received the suggestion that
> this is really something that should be part of the phy subsystem which
> would require a new tool to be written.

phylib uses netlink/ethtool, e.g. cable test is purely in phylib, and
it uses ethtool. ethtool also has --set-phy-tunable, --get-phy-tunable,
--phy-statistics, etc.

Also, PRBS is not just a PHY thing, 802.3 defines it as part of the
PCS, and i don't see why a MAC could also implement it, not that i
have seen such a thing.

And maybe other networking technologies also have something like PRBS?
Is there an 802.11 equivalent, used for testing the analogue front
end? CAN?

> 
> Alex had started to onboard fbnic to phy as part of his work to onboard
> fbnic to phylink. My understanding is that Alex was recently asked to not
> use the phy subsystem. So the question is where does this go? What user
> space tool interacts with the API?

Linux's understanding of a PHY is a device which takes the bitstream
from the MAC and turns it into analogue signals on twisted pairs,
mostly for an RJ45 connector, but automotive uses other
connectors. Its copper, and 802.3 C22 and parts of C45 define how such
a PHY should work. There is a second use case, where a PHY converts
between say RGMII and SGMII, but it basically uses the same registers.

fbnic is not copper. It has an SFP cage. Linux has a different
architecture for that, MAC, PCS and SFP driver. Alex abused the design
and put a PHY into it as a shortcut. It not surprising there was push
back.

So, i still think ethtool is the correct API. In general, that
connects to the MAC driver, although it can shortcut to a PHY
connected to a MAC. But such a short cut has caused issues in the
past. So i would probably not do that. Add an API to phylink, which
the MAC can use. And an API to the PCS driver, which phylink can
use. And for when the PHY implements PRBS, add an API to phylib and
get phylib to call the PHY driver.

I'm not saying you need to implement all that, just the bits you need
for a PCS packet generator. But lay out the architecture such that it
can be extended with packet generators in other places.
 
> > For PRBS pattern tests testing i think there needs to be a framework
> > around it.
> > 
> > When you enable testing, the netif becomes usable, so its state needs
> > changing to "under test" as defined in RFC2863. We ideally want it
> > revert to normal operation after a time period. There are a number of
> > different PRBS patterns, so you need to be able to select one, and
> > maybe pass the test duration. It can also be performed in different
> > places. 802.3 defines a number of registers in the PCS for this. I
> > would expect to see a library that any standards conforming PCS can
> > use. There are also PHYs which support this features, but each vendor
> > implements it differently, so we need some sort of generic API for
> > PHYs. I expect we will also end up with a set of netlink message,
> > similar to how cable testing working.
> 
> Nothing can touch the comphy while PRBS testing is running. The fbnic driver
> rejects starting testing if the link is up.

That actually seems odd to me. I assume you need to set the link mode
you want. Having it default to 10/Half is probably not what you
want. You want to use ethtool_ksettings_set to force the MAC and PCS
into a specific link mode. Most MAC drivers don't do anything if that
call is made when the interface is admin down. And if you look at how
most MAC drivers are structured, they don't bind to phylink/phylib
until open() is called. So when admin down, you don't even have a
PCS/PHY. And some designs have multiple PCSes, and you select the one
you need based on the link mode, set by ethtool_ksettings_set or
autoneg. And if admin down, the phylink will turn the SFP laser off.

> When I spoke with test engineers internally in Meta I could not come up with
> a time period and over night testing came up as a requirement. I decided to
> just let the user start and stop testing with no time requirement. If
> firmware loses the host heartbeat it automatically disables PRBS testing.

O.K. So i would probably go for a blocking netlink call, and when ^C
is used, to exits PRBS and allows normal traffic. You then need to
think about RTNL, which you cannot hold for hours.

	Andrew

Powered by blists - more mailing lists