Also do you know what layer in the PHY you are injecting this PRBS at?
I would be curious if this is PCS or at the PMD level?

In our case PRBS functionality is implemented in the PHY firmware at the PCS (TX/RX) + PMA (FEC Error Injection) layer.


Andrew,  Alexander, Lee,

The host driver does not directly access any registers but requests the PHY FW to manage PRBS on behalf of it.
Because of this, the implementation does not naturally fit the traditional PHYLIB model, where Linux PHY drivers directly manage PHY registers. 
The functionality is closer to a firmware-managed service exposed through the PCIe driver, so we thought the right place would be to extend ethtool.

We come from the Ethernet PHY field and are attempting to generalize PRBS for generic PHYs to accommodate all bus types, which might distract us, I believe.
The existing ethtool user application interface will give a quick start for Ethernet PHY PRBS management. 
When we need other buses or when we have another model implementation, then we can abstract the commonalities into a framework.

Should we proceed with implementing the "ethtool --phy-test" ?

-----Original Message-----
From: Alexander H Duyck <redacted>
Sent: 16 June 2026 21:45
To: Das, Shubham <redacted>; Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
[off-list ref]; Chintalapalle, Balaji [off-list ref]
Subject: Re: Ethtool : PRBS feature

On Tue, 2026-06-16 at 12:14 +0000, Das, Shubham wrote:

quoted

Hi Andrew,

Thanks for the feedback.

Yes, for multi-lane ports we can accept the lane number as an argument like:

ethtool --phy-test eth1 lane 0 tx-prbs prbs7 ethtool --phy-test eth2
lane 0 rx-prbs prbs7

We referred to "Lee Trager's" "Open-Source Tooling for PHY Management and

Testing" session:

quoted

https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-

management-and-testing.html?.

quoted

We have been trying to reach "Lee Trager" to seek more input, latest update on

the approach and understand if there is a parallel effort in active so we can
collaborate.

quoted

If you can, please help me connect with "Lee Trager" and others who expressed

interest in Ethernet PRBS. We are happy to align and start implementation.

quoted

You aren't going to have much luck if you are trying to reach out via his Meta
address as he has moved onto Nvidia so he is no longer working on the fbnic
driver.

As far as the work done most of it was internal and making use of debugfs. I don't
believe any of the work for fbnic began to approach the suggested methods for
upstreamming the feature as Lee had been pulled into other efforts.

quoted

About standardizing across other bus like PCIe and USB, I had a quick discussion

with our internal designers, but I didn't observe any such SW-level config knobs
interest.

quoted

Looks like Ethernet has clear interest and we are joining that Ethernet PRBS

community too.

I think it largely depends on what your implementation looks like. The point being
made was that many of the SerDes PHYs out there are capable of use in multiple
applications. So instead of being a networking device you would be looking at a
SerDes PHY such as those in "/drivers/phy/".

Also do you know what layer in the PHY you are injecting this PRBS at?
I would be curious if this is PCS or at the PMD level?

If you are referring to the PCS level then yes, it would make sense to have it in the
networking subsystem as the PCS at this point is more a netdev specific set of
drivers, see "/drivers/net/pcs/".

In the case of the PMD that is where things get a bit more interesting.
There is an IEEE c45 register definition that includes PRBS testing registers,
however in the case of our implementation the PMD doesn't follow that
specification and follows more the "/drivers/phy/" model.

quoted

Ethernet PRBS configuration and diagnostics support is well established and

already widely used in existing Ethernet SERDES deployments.

quoted

We think Ethernet is the most natural starting point within netdev, as
it aligns with current driver practice and existing validation workflows.

The problem is many of these parts used as an Ethernet Serdes PMD are really a
multiuse part. So for example in the case of the hardware in FBNIC we use the
same part on the Ethernet PHY as we do for the PCIe
Gen5 PHY.

The complication in our case is that both are buried behind our FW due to the fact
that both are shared between slices. However for testing purposes and such we
could look at disabling the odd slices to essentially unshare the hardware if you
need another platform to test something like this with.