Ethtool : PRBS feature

Ethtool : PRBS feature

[Das, Shubham]

Hi All,

I'm looking for feedback on a potential extension to ethtool for controlling Ethernet PHY link characterization using PRBS generation and error injection.
PRBS is a port level configuration and ethtool ?phy-test will provide control interface at every port-level.

PRBS is an IEEE standard, and almost all Ethernet PHY SerDes comes with PRBS generator and receiver to assist physical link characterization.
In addition to PRBS sequence, we want to support provide SW control knobs to insert fixed number of errors, retrieve the bit error count, and clear them as needed.
With this, we are trying to standardize a multi-decade technology PRBS, so every Ethernet vendor can get benefited and replace the device specific custom tools.
From Ethernet designer point-of-view, it helps identify, fine tune, and make the ethernet communication better and stable. 
From end-user point of view, it helps gather debug data when something is not working at expected speeds.

Typical operations include:

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

ethtool --phy-test eth2 bert start
ethtool --phy-test eth2 bert stop
ethtool --phy-test eth2 stats
ethtool --phy-test eth2 clear-stats

ethtool --phy-test eth1 inject-error 1
ethtool --phy-test eth1 inject-error 1e-3

ethtool --phy-test eth1 tx-prbs off
ethtool --phy-test eth2 rx-prbs off


Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly. 
Conceptually:
       ethtool ⇒ ethtool netlink ⇒ driver-specific implementation

The intent would be to provide a common userspace interface while allowing implementations in NIC drivers.

Before proceeding further, I would appreciate feedback on:

1. Whether ethtool is considered the appropriate userspace interface for these functionality
2. Whether similar work has been proposed previously.

Thanks,
Shubham D

Re: Ethtool : PRBS feature

[Andrew Lunn]

> 2. Whether similar work has been proposed previously.

There was a presentation at netdev conf last year about this topic,
and how you use it to configure SERDES eyes. And then a long
discussion on the netdev mailing afterwards. You should read the
discussion, and incorporate the ideas. There was a couple of points
raised:

SERDES are also used for PCIe, USB, SATA, and they have similar
capabilities to a SERDES used for networking. Do we want a networking
specific solution, or something more generic?

You need to include lane information, since there can be 1, 2 or 4
lanes involved, and you need to specify which lane you want to test.

      Andrew

RE: Ethtool : PRBS feature

[Das, Shubham]

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:
https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html?.
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.
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.

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. 
Looks like Ethernet has clear interest and we are joining that Ethernet PRBS community too.

Ethernet PRBS configuration and diagnostics support is well established and already widely used in existing Ethernet SERDES deployments.
We think Ethernet is the most natural starting point within netdev, as it aligns with current driver practice and existing validation workflows. 

Thanks,
Shubham D


> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 11 June 2026 21:14
> To: Das, Shubham <shubham.das@intel.com>
> Cc: netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> <siddaraju.dh@intel.com>; Chintalapalle, Balaji <balaji.chintalapalle@intel.com>
> Subject: Re: Ethtool : PRBS feature
> 
> > 2. Whether similar work has been proposed previously.
> 
> There was a presentation at netdev conf last year about this topic,
> and how you use it to configure SERDES eyes. And then a long
> discussion on the netdev mailing afterwards. You should read the
> discussion, and incorporate the ideas. There was a couple of points
> raised:
> 
> SERDES are also used for PCIe, USB, SATA, and they have similar
> capabilities to a SERDES used for networking. Do we want a networking
> specific solution, or something more generic?
> 
> You need to include lane information, since there can be 1, 2 or 4
> lanes involved, and you need to specify which lane you want to test.
> 
>       Andrew

Re: Ethtool : PRBS feature

[Alexander H Duyck]

On Tue, 2026-06-16 at 12:14 +0000, Das, Shubham wrote:
> 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:
> https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html?.
> 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.
> 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.
> 

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.

> 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. 
> 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.

> Ethernet PRBS configuration and diagnostics support is well established and already widely used in existing Ethernet SERDES deployments.
> 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.

RE: Ethtool : PRBS feature

[Das, Shubham]

> 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 <alexander.duyck@gmail.com>
> Sent: 16 June 2026 21:45
> To: Das, Shubham <shubham.das@intel.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> <siddaraju.dh@intel.com>; Chintalapalle, Balaji <balaji.chintalapalle@intel.com>
> Subject: Re: Ethtool : PRBS feature
> 
> On Tue, 2026-06-16 at 12:14 +0000, Das, Shubham wrote:
> > 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:
> > https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-
> management-and-testing.html?.
> > 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.
> > 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.
> >
> 
> 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.
> 
> > 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.
> > 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.
> 
> > Ethernet PRBS configuration and diagnostics support is well established and
> already widely used in existing Ethernet SERDES deployments.
> > 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.

Re: Ethtool : PRBS feature

[Andrew Lunn]

> The host driver does not directly access any registers but requests
> the PHY FW to manage PRBS on behalf of it.

Maybe a dumb question. Why?

Can you change the firmware to expose the 802.3 registers for PRBS?
You can then write a library which both plylib and your driver can
use.

	Andrew

RE: Ethtool : PRBS feature

[Das, Shubham]

> Can you change the firmware to expose the 802.3 registers for PRBS?
> You can then write a library which both plylib and your driver can use.

Andrew,

No, exposing the PRBS registers to drivers is not possible in our design (the registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy).

Additionally, the PHY PRBS registers are not in accordance with the IEEE Clause 45 definitions. For instance, the PRBS registers are paged and 32-bit wide.

Given these constraints, we think ethtool --phy-test is a reasonable starting point for exposing the long-established Ethernet PRBS functionality to Linux userspace, as it aligns well with the driver-owned NIC architecture model. If you think a more generic layered approach would be preferable, we would appreciate guidance on the expected architecture. That would help us better understand the implementation complexity, required effort, and delivery timelines.

Thanks,
Shubham D

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 20 June 2026 00:07
> To: Das, Shubham <shubham.das@intel.com>
> Cc: Alexander H Duyck <alexander.duyck@gmail.com>; lee@trager.us;
> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> <siddaraju.dh@intel.com>; Chintalapalle, Balaji
> <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
> Subject: Re: Ethtool : PRBS feature
> 
> > The host driver does not directly access any registers but requests
> > the PHY FW to manage PRBS on behalf of it.
> 
> Maybe a dumb question. Why?
> 
> Can you change the firmware to expose the 802.3 registers for PRBS?
> You can then write a library which both plylib and your driver can use.
> 
> 	Andrew

Re: Ethtool : PRBS feature

[Maxime Chevallier]

Hi,

On 6/20/26 15:48, Das, Shubham wrote:
>> Can you change the firmware to expose the 802.3 registers for PRBS?
>> You can then write a library which both plylib and your driver can use.
> 
> Andrew,
> 
> No, exposing the PRBS registers to drivers is not possible in our design (the registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy).
> 
> Additionally, the PHY PRBS registers are not in accordance with the IEEE Clause 45 definitions. For instance, the PRBS registers are paged and 32-bit wide.
> 
> Given these constraints, we think ethtool --phy-test is a reasonable starting point for exposing the long-established Ethernet PRBS functionality to Linux userspace, as it aligns well with the driver-owned NIC architecture model. If you think a more generic layered approach would be preferable, we would appreciate guidance on the expected architecture. That would help us better understand the implementation complexity, required effort, and delivery timelines.

Can you elaborate on what you have in mind for now ? what would the
"ethtool --phy-test" command look like in terms of its behaviour and
parameters ?

This feature is interesting for multiple people, each having different
hardware designs and constraints. It's good to consider an iterative
approach to build this, however we need to have in mind that this is
uAPI, so once we commit to a design choice, we have to live with it.

We do have flexibility on the kernel side of the API. We can implement PRBS
in generic PHY, phylib, some MAC driver that talks to a firmware, etc. and
hide away these implementation details to userspace, but we need to make
sure the uAPI we come up with allows us to support all of that.

Let's figure this out together, if you already have some ideas in mind we
can use that as a starting point for the discussion :)

Maxime

> 
> Thanks,
> Shubham D
> 
>> -----Original Message-----
>> From: Andrew Lunn <andrew@lunn.ch>
>> Sent: 20 June 2026 00:07
>> To: Das, Shubham <shubham.das@intel.com>
>> Cc: Alexander H Duyck <alexander.duyck@gmail.com>; lee@trager.us;
>> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
>> <siddaraju.dh@intel.com>; Chintalapalle, Balaji
>> <balaji.chintalapalle@intel.com>; Lindberg, Magnus
>> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
>> Subject: Re: Ethtool : PRBS feature
>>
>>> The host driver does not directly access any registers but requests
>>> the PHY FW to manage PRBS on behalf of it.
>>
>> Maybe a dumb question. Why?
>>
>> Can you change the firmware to expose the 802.3 registers for PRBS?
>> You can then write a library which both plylib and your driver can use.
>>
>> 	Andrew
> 

Re: Ethtool : PRBS feature

[Andrew Lunn]

On Sat, Jun 20, 2026 at 04:39:06PM +0200, Maxime Chevallier wrote:
> Hi,
> 
> On 6/20/26 15:48, Das, Shubham wrote:
> >> Can you change the firmware to expose the 802.3 registers for PRBS?
> >> You can then write a library which both plylib and your driver can use.
> > 
> > Andrew,
> > 
> > No, exposing the PRBS registers to drivers is not possible in our design (the registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy).
> > 
> > Additionally, the PHY PRBS registers are not in accordance with the IEEE Clause 45 definitions. For instance, the PRBS registers are paged and 32-bit wide.
> > 

Hi Shubham

Do you at least have the functionality of the standard C45 registers,
even if the addresses and bit fields are messed up?

If you do, maybe we should actually start with a C45 conforming
implementation, and then you can do a translation layer to whatever
oddball implementation you have?

> > Given these constraints, we think ethtool --phy-test is a
> > reasonable starting point for exposing the long-established
> > Ethernet PRBS functionality to Linux userspace, as it aligns well
> > with the driver-owned NIC architecture model.

I agree an ethtool --phy-test makes sense, but we need to ensure
standard based C45 functionality is covered, not just your oddball
vendor functionality.

	Andrew

RE: Ethtool : PRBS feature

[Das, Shubham]

> Do you at least have the functionality of the standard C45 registers, even if the addresses and bit fields are messed up?
> If you do, maybe we should actually start with a C45 conforming implementation, and then you can do a translation layer to whatever oddball implementation you have?

The PHY supports the equivalent functionality (PRBS TX, PRBS RX/checker, BER testing, error injection, and symbol/error counters read), 
but these are not exposed through standard Clause 45 PRBS registers. Instead, all operations are implemented by PHY firmware
and accessed through a command/control register interface.

If we want to support both driver-owned NIC architectures and use cases where the PHY driver directly manages the PRBS functionality,
Should this be exposed through a common phylib abstraction/API or a different approach ?

- Shubham D

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 21 June 2026 00:51
> To: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Cc: Das, Shubham <shubham.das@intel.com>; Alexander H Duyck
> <alexander.duyck@gmail.com>; lee@trager.us; netdev@vger.kernel.org;
> mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle,
> Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
> Subject: Re: Ethtool : PRBS feature
> 
> On Sat, Jun 20, 2026 at 04:39:06PM +0200, Maxime Chevallier wrote:
> > Hi,
> >
> > On 6/20/26 15:48, Das, Shubham wrote:
> > >> Can you change the firmware to expose the 802.3 registers for PRBS?
> > >> You can then write a library which both plylib and your driver can use.
> > >
> > > Andrew,
> > >
> > > No, exposing the PRBS registers to drivers is not possible in our design (the
> registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy).
> > >
> > > Additionally, the PHY PRBS registers are not in accordance with the IEEE
> Clause 45 definitions. For instance, the PRBS registers are paged and 32-bit wide.
> > >
> 
> Hi Shubham
> 
> Do you at least have the functionality of the standard C45 registers, even if the
> addresses and bit fields are messed up?
> 
> If you do, maybe we should actually start with a C45 conforming implementation,
> and then you can do a translation layer to whatever oddball implementation you
> have?
> 
> > > Given these constraints, we think ethtool --phy-test is a reasonable
> > > starting point for exposing the long-established Ethernet PRBS
> > > functionality to Linux userspace, as it aligns well with the
> > > driver-owned NIC architecture model.
> 
> I agree an ethtool --phy-test makes sense, but we need to ensure standard based
> C45 functionality is covered, not just your oddball vendor functionality.
> 
> 	Andrew

RE: Ethtool : PRBS feature

[Das, Shubham]

Hi Maxime,

> Can you elaborate on what you have in mind for now ? what would the "ethtool --
> phy-test" command look like in terms of its behaviour and parameters ?

We are trying to converge on a userspace uAPI for PRBS/BERT functionality that can work across
different hardware models (PHY-managed, MAC/NIC-offloaded, or firmware-based implementations),
without exposing those differences to userspace.

Based on the functionality we currently have, we proposed below commands in first email :

PRBS Transmitter/Checker Pattern Configuration:
ethtool --phy-test eth1 tx-prbs prbs7
ethtool --phy-test eth2 rx-prbs prbs7

BERT Test:
ethtool --phy-test eth2 bert start
ethtool --phy-test eth2 bert stop

BERT Test Counter Read/ PRBS Lock Status:
ethtool --phy-test eth2 stats

BERT Clear stats - Symbol and Error counter:
ethtool --phy-test eth2 clear-stats

TX Error Injection:
ethtool --phy-test eth1 inject-error 1
ethtool --phy-test eth1 inject-error 1e-3

Disable PRBS Pattern : TX/RX
ethtool --phy-test eth1 tx-prbs off
ethtool --phy-test eth2 rx-prbs off

Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly. 
Conceptually:
       ethtool ⇒ ethtool netlink ⇒ driver-specific implementation

We would appreciate your input on whether a command-based model is suitable for a uAPI, and how we should design
it to accommodate different implementation models, such as PHY-based, phylib-based, and MAC/firmware-offloaded PRBS.

- Shubham D

> -----Original Message-----
> From: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Sent: 20 June 2026 20:09
> To: Das, Shubham <shubham.das@intel.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: Alexander H Duyck <alexander.duyck@gmail.com>; lee@trager.us;
> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> <siddaraju.dh@intel.com>; Chintalapalle, Balaji
> <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
> Subject: Re: Ethtool : PRBS feature
> 
> Hi,
> 
> On 6/20/26 15:48, Das, Shubham wrote:
> >> Can you change the firmware to expose the 802.3 registers for PRBS?
> >> You can then write a library which both plylib and your driver can use.
> >
> > Andrew,
> >
> > No, exposing the PRBS registers to drivers is not possible in our design (the
> registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy).
> >
> > Additionally, the PHY PRBS registers are not in accordance with the IEEE Clause
> 45 definitions. For instance, the PRBS registers are paged and 32-bit wide.
> >
> > Given these constraints, we think ethtool --phy-test is a reasonable starting
> point for exposing the long-established Ethernet PRBS functionality to Linux
> userspace, as it aligns well with the driver-owned NIC architecture model. If you
> think a more generic layered approach would be preferable, we would appreciate
> guidance on the expected architecture. That would help us better understand the
> implementation complexity, required effort, and delivery timelines.
> 
> Can you elaborate on what you have in mind for now ? what would the "ethtool --
> phy-test" command look like in terms of its behaviour and parameters ?
> 
> This feature is interesting for multiple people, each having different hardware
> designs and constraints. It's good to consider an iterative approach to build this,
> however we need to have in mind that this is uAPI, so once we commit to a design
> choice, we have to live with it.
> 
> We do have flexibility on the kernel side of the API. We can implement PRBS in
> generic PHY, phylib, some MAC driver that talks to a firmware, etc. and hide away
> these implementation details to userspace, but we need to make sure the uAPI
> we come up with allows us to support all of that.
> 
> Let's figure this out together, if you already have some ideas in mind we can use
> that as a starting point for the discussion :)
> 
> Maxime
> 
> >
> > Thanks,
> > Shubham D
> >
> >> -----Original Message-----
> >> From: Andrew Lunn <andrew@lunn.ch>
> >> Sent: 20 June 2026 00:07
> >> To: Das, Shubham <shubham.das@intel.com>
> >> Cc: Alexander H Duyck <alexander.duyck@gmail.com>; lee@trager.us;
> >> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> >> <siddaraju.dh@intel.com>; Chintalapalle, Balaji
> >> <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> >> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
> >> Subject: Re: Ethtool : PRBS feature
> >>
> >>> The host driver does not directly access any registers but requests
> >>> the PHY FW to manage PRBS on behalf of it.
> >>
> >> Maybe a dumb question. Why?
> >>
> >> Can you change the firmware to expose the 802.3 registers for PRBS?
> >> You can then write a library which both plylib and your driver can use.
> >>
> >> 	Andrew
> >

Re: Ethtool : PRBS feature

[Lee Trager]

On 6/22/26 8:38 AM, Das, Shubham wrote:

> Hi Maxime,
>
>> Can you elaborate on what you have in mind for now ? what would the "ethtool --
>> phy-test" command look like in terms of its behaviour and parameters ?
> We are trying to converge on a userspace uAPI for PRBS/BERT functionality that can work across
> different hardware models (PHY-managed, MAC/NIC-offloaded, or firmware-based implementations),
> without exposing those differences to userspace.

This was my original thought as well. Create a well defined uAPI for 
PRBS testing/TX FIR tuning and allow the driver to implement support 
however it sees fit. Since our target is for ethernet devices ethtool 
was a natural spot for the uAPI.

I presented this at netdev last year and received strong push back 
against associating PRBS testing/TX FIR tuning with ethtool. The 
argument being any new uAPI added to the kernel should be generic enough 
to handle future use cases so duplicate uAPIs don't have to be added. 
Since PRBS testing/TX FIR tuning can be done on many phys(Ethernet, 
PCIE, USB, etc) the uAPI does not belong in ethtool and needs to be 
structured to support other use cases.

As drivers/phy is the base phy library the thought was support should be 
added in drivers/phy and a new phytool should be created to interact 
with a uAPI. This would be generic enough to support all use cases, with 
the downside being existing drivers would have to onboard to drivers/phy.

I do wonder if the best path forward would be to create phytool in a way 
that allows the driver to implement PRBS testing/TX FIR tuning as it 
sees fit instead of being strictly tied to drivers/phy.

>
> Based on the functionality we currently have, we proposed below commands in first email :
>
> PRBS Transmitter/Checker Pattern Configuration:
> ethtool --phy-test eth1 tx-prbs prbs7
> ethtool --phy-test eth2 rx-prbs prbs7
>
> BERT Test:
> ethtool --phy-test eth2 bert start
> ethtool --phy-test eth2 bert stop
>
> BERT Test Counter Read/ PRBS Lock Status:
> ethtool --phy-test eth2 stats
>
> BERT Clear stats - Symbol and Error counter:
> ethtool --phy-test eth2 clear-stats
>
> TX Error Injection:
> ethtool --phy-test eth1 inject-error 1
> ethtool --phy-test eth1 inject-error 1e-3
>
> Disable PRBS Pattern : TX/RX
> ethtool --phy-test eth1 tx-prbs off
> ethtool --phy-test eth2 rx-prbs off

The goal of running testing is to validate TX FIR values. If testing 
fails we need a uAPI to change those values.

Also the uAPI need to support testing per lane. One thing hardware 
engineers at Meta did was test each lane with a different set of TX FIR 
values which allowed them to quickly determine the best set of values.

>
> Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly.
> Conceptually:
>         ethtool ⇒ ethtool netlink ⇒ driver-specific implementation
>
> We would appreciate your input on whether a command-based model is suitable for a uAPI, and how we should design
> it to accommodate different implementation models, such as PHY-based, phylib-based, and MAC/firmware-offloaded PRBS.
>
> - Shubham D
>
>> -----Original Message-----
>> From: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> Sent: 20 June 2026 20:09
>> To: Das, Shubham <shubham.das@intel.com>; Andrew Lunn <andrew@lunn.ch>
>> Cc: Alexander H Duyck <alexander.duyck@gmail.com>; lee@trager.us;
>> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
>> <siddaraju.dh@intel.com>; Chintalapalle, Balaji
>> <balaji.chintalapalle@intel.com>; Lindberg, Magnus
>> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
>> Subject: Re: Ethtool : PRBS feature
>>
>> Hi,
>>
>> On 6/20/26 15:48, Das, Shubham wrote:
>>>> Can you change the firmware to expose the 802.3 registers for PRBS?
>>>> You can then write a library which both plylib and your driver can use.
>>> Andrew,
>>>
>>> No, exposing the PRBS registers to drivers is not possible in our design (the
>> registers are buried deep within the Accelerator/NIC/PHY/Analog IP hierarchy).
>>> Additionally, the PHY PRBS registers are not in accordance with the IEEE Clause
>> 45 definitions. For instance, the PRBS registers are paged and 32-bit wide.
>>> Given these constraints, we think ethtool --phy-test is a reasonable starting
>> point for exposing the long-established Ethernet PRBS functionality to Linux
>> userspace, as it aligns well with the driver-owned NIC architecture model. If you
>> think a more generic layered approach would be preferable, we would appreciate
>> guidance on the expected architecture. That would help us better understand the
>> implementation complexity, required effort, and delivery timelines.
>>
>> Can you elaborate on what you have in mind for now ? what would the "ethtool --
>> phy-test" command look like in terms of its behaviour and parameters ?
>>
>> This feature is interesting for multiple people, each having different hardware
>> designs and constraints. It's good to consider an iterative approach to build this,
>> however we need to have in mind that this is uAPI, so once we commit to a design
>> choice, we have to live with it.
>>
>> We do have flexibility on the kernel side of the API. We can implement PRBS in
>> generic PHY, phylib, some MAC driver that talks to a firmware, etc. and hide away
>> these implementation details to userspace, but we need to make sure the uAPI
>> we come up with allows us to support all of that.
>>
>> Let's figure this out together, if you already have some ideas in mind we can use
>> that as a starting point for the discussion :)
>>
>> Maxime
>>
>>> Thanks,
>>> Shubham D
>>>
>>>> -----Original Message-----
>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>> Sent: 20 June 2026 00:07
>>>> To: Das, Shubham <shubham.das@intel.com>
>>>> Cc: Alexander H Duyck <alexander.duyck@gmail.com>; lee@trager.us;
>>>> netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
>>>> <siddaraju.dh@intel.com>; Chintalapalle, Balaji
>>>> <balaji.chintalapalle@intel.com>; Lindberg, Magnus
>>>> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
>>>> Subject: Re: Ethtool : PRBS feature
>>>>
>>>>> The host driver does not directly access any registers but requests
>>>>> the PHY FW to manage PRBS on behalf of it.
>>>> Maybe a dumb question. Why?
>>>>
>>>> Can you change the firmware to expose the 802.3 registers for PRBS?
>>>> You can then write a library which both plylib and your driver can use.
>>>>
>>>> 	Andrew

Re: Ethtool : PRBS feature

[Andrew Lunn]

On Mon, Jun 22, 2026 at 03:38:30PM +0000, Das, Shubham wrote:
> Hi Maxime,
> 
> > Can you elaborate on what you have in mind for now ? what would the "ethtool --
> > phy-test" command look like in terms of its behaviour and parameters ?
> 
> We are trying to converge on a userspace uAPI for PRBS/BERT functionality that can work across
> different hardware models (PHY-managed, MAC/NIC-offloaded, or firmware-based implementations),
> without exposing those differences to userspace.
> 
> Based on the functionality we currently have, we proposed below commands in first email :
> 
> PRBS Transmitter/Checker Pattern Configuration:
> ethtool --phy-test eth1 tx-prbs prbs7
> ethtool --phy-test eth2 rx-prbs prbs7
> 
> BERT Test:
> ethtool --phy-test eth2 bert start
> ethtool --phy-test eth2 bert stop
> 
> BERT Test Counter Read/ PRBS Lock Status:
> ethtool --phy-test eth2 stats
> 
> BERT Clear stats - Symbol and Error counter:
> ethtool --phy-test eth2 clear-stats
> 
> TX Error Injection:
> ethtool --phy-test eth1 inject-error 1
> ethtool --phy-test eth1 inject-error 1e-3
> 
> Disable PRBS Pattern : TX/RX
> ethtool --phy-test eth1 tx-prbs off
> ethtool --phy-test eth2 rx-prbs off
> 
> Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly. 
> Conceptually:
>        ethtool ⇒ ethtool netlink ⇒ driver-specific implementation
> 
> We would appreciate your input on whether a command-based model is suitable for a uAPI, and how we should design
> it to accommodate different implementation models, such as PHY-based, phylib-based, and MAC/firmware-offloaded PRBS.

This is technical, not the uAPI. You need to define the netlink
messages and all the attributes that are passed between user space and
kernel. Please take a look at Documentation/netlink/specs and propose
an extension to ethtool.yaml.

Taking a quick look at this:

You are missing a way to enumerate what test patterns the hardware
supports. There is more than prbs7. You want to be able to report the
contents of C45 1.1500, and other similar registers.

To avoid race conditions, maybe some of these commands need combining. 
ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start

The configuration is then atomic, with respect to the uAPI, so we
don't get two users configuring it at the same time, ending up with a
messed up configuration.

Traditionally, Unix does not offer a way to clear statistic counters
back to zero. So i'm not sure about clear-stats. We also need to think
about hardware which does not support that. And there is locking
issues, can the stats be cleared while a test is active? 

You need to think about the units for inject errors. There is no
floating point support. Also, is this corrupt packets? Or single bit
flips in the stream? It needs to be well defined what it actually
means. The driver can then convert it to whatever the hardware
supports. How does 802.3 specify this?

Also, 802.3 defines PRBS7 as a benign pattern. With a quick look, i
did not find a definition of benign, but injecting errors does not
seem benign to me.

I'm assuming when 'start' is used, the networking core will change the
interface status to IF_OPER_TESTING. It is not always obvious why an
interface is in testing mode, rather than IF_OPER_UP. Cable testing
could also be running, etc. So maybe there needs to be a way to report
why it is in IF_OPER_TESTING?

I also wounder if a timeout should be used with start, so that it will
return to IF_OPER_UP after a time period?

       Andrew

Re: Ethtool : PRBS feature

[Lee Trager]

On 6/23/26 2:43 AM, Andrew Lunn wrote:

> Taking a quick look at this:
>
> You are missing a way to enumerate what test patterns the hardware
> supports. There is more than prbs7. You want to be able to report the
> contents of C45 1.1500, and other similar registers.
Not only is there more than PRBS7 but also PRBS 8/10 encoding which is 
an option on any test. There may be other options, that was the only one 
fbnic supported. I agree there does need to be a user interface which 
displays supported tests and options.
> To avoid race conditions, maybe some of these commands need combining.
> ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
>
> The configuration is then atomic, with respect to the uAPI, so we
> don't get two users configuring it at the same time, ending up with a
> messed up configuration.
Testing consumes the link so you really don't want anything done to the 
netdev while testing is running. fbnic does the following.

1. Testing cannot start when the link is up
2. Once testing starts the driver removes the netdev to prevent use. The 
netdev is only added back when testing stops. The upstream solution will 
need something that can keep the netdev but lock everything down while 
testing is running.
3. Once testing starts you cannot change the test, even on an individual 
lane basis. You must stop testing first.
>
> Traditionally, Unix does not offer a way to clear statistic counters
> back to zero. So i'm not sure about clear-stats. We also need to think
> about hardware which does not support that. And there is locking
> issues, can the stats be cleared while a test is active?

fbnic actually has separate registers for PRBS test results. Results do 
need to be clean between runs but I never created an explicit clear 
interface. Firmware automatically reset the registers when a new test 
was started. This also allows results to be viewed after testing has 
stopped.

Reading results was a little tricky due to roll over between two 32bit 
registers. I was able to read results while testing was running without 
pausing. Technically I could clear results while testing was running but 
never saw a need to.

>
> You need to think about the units for inject errors. There is no
> floating point support. Also, is this corrupt packets? Or single bit
> flips in the stream? It needs to be well defined what it actually
> means. The driver can then convert it to whatever the hardware
> supports. How does 802.3 specify this?
>
> Also, 802.3 defines PRBS7 as a benign pattern. With a quick look, i
> did not find a definition of benign, but injecting errors does not
> seem benign to me.
>
> I'm assuming when 'start' is used, the networking core will change the
> interface status to IF_OPER_TESTING. It is not always obvious why an
> interface is in testing mode, rather than IF_OPER_UP. Cable testing
> could also be running, etc. So maybe there needs to be a way to report
> why it is in IF_OPER_TESTING?
>
> I also wounder if a timeout should be used with start, so that it will
> return to IF_OPER_UP after a time period?

When I spoke to hardware engineers at Meta they did not want a timeout. 
Testing often occurred over days, so they wanted to be able to start it 
and explicitly stop it. I'm not against a time out but I do think it 
should be optional.

Since PRBS testing is handled by firmware one safety measure I added is 
if firmware lost contact with the host testing was automatically stopped 
and TX FIR values were reset to factory. This ensured that the NIC won't 
get stuck in testing and on initialization the driver doesn't have to 
worry about testing state.

Lee

Re: Ethtool : PRBS feature

[Andrew Lunn]

>     To avoid race conditions, maybe some of these commands need combining.
>     ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
> 
>     The configuration is then atomic, with respect to the uAPI, so we
>     don't get two users configuring it at the same time, ending up with a
>     messed up configuration.
> 
> Testing consumes the link so you really don't want anything done to the netdev
> while testing is running. fbnic does the following.
> 
> 1. Testing cannot start when the link is up

That is not going to work in the generic case. Many MAC drivers don't
bind to there PCS or PHY until open() is called. So there is no way to
pass the uAPI calls onto the PCS or PHY if the interface is
down. There are also some MACs which connect to multiple PCSs, and
there can be multiple PHYs. So you need to somehow indicate which
PCS/PHY should perform the PRBS. There was a discussion about loopback
recently, which has the same issue, you can perform loopback testing
in multiple places. So i expect the same concept will be used for
this.

> 2. Once testing starts the driver removes the netdev to prevent use. The netdev
> is only added back when testing stops. The upstream solution will need
> something that can keep the netdev but lock everything down while testing is
> running.

Probably IF_OPER_TESTING would be part of this. If the interface is in
this state, you want many other things blocked. However, probably
ksettings get/set need to work, so you can force the link into a
specific mode.

> 3. Once testing starts you cannot change the test, even on an individual lane
> basis. You must stop testing first.
> 
> 
>     Traditionally, Unix does not offer a way to clear statistic counters
>     back to zero. So i'm not sure about clear-stats. We also need to think
>     about hardware which does not support that. And there is locking
>     issues, can the stats be cleared while a test is active?
> 
> fbnic actually has separate registers for PRBS test results. Results do need to
> be clean between runs but I never created an explicit clear interface. Firmware
> automatically reset the registers when a new test was started. This also allows
> results to be viewed after testing has stopped.

We should really take 802.3 as the model, but i've not had time yet to
read what it says about the statistics.

> Reading results was a little tricky due to roll over between two 32bit
> registers.

802.3 is make this even more interesting, since those registers are 16
bits.

> When I spoke to hardware engineers at Meta they did not want a timeout. Testing
> often occurred over days, so they wanted to be able to start it and explicitly
> stop it. I'm not against a time out but I do think it should be optional.
> 
> Since PRBS testing is handled by firmware one safety measure I added is if
> firmware lost contact with the host testing was automatically stopped and TX
> FIR values were reset to factory. This ensured that the NIC won't get stuck in
> testing and on initialization the driver doesn't have to worry about testing
> state.

That will work for firmware, but not when Linux is driving the
hardware. I don't know if netlink will allow it, or if RTNL will get
in the way etc, but it could be we actually don't want a start and
stop commands at all, it is a blocking netlink call, and the test runs
until the user space process closes the socket?

      Andrew

Re: Ethtool : PRBS feature

[Alexander Duyck]

On Tue, Jun 23, 2026 at 7:30 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> >     To avoid race conditions, maybe some of these commands need combining.
> >     ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
> >
> >     The configuration is then atomic, with respect to the uAPI, so we
> >     don't get two users configuring it at the same time, ending up with a
> >     messed up configuration.
> >
> > Testing consumes the link so you really don't want anything done to the netdev
> > while testing is running. fbnic does the following.
> >
> > 1. Testing cannot start when the link is up
>
> That is not going to work in the generic case. Many MAC drivers don't
> bind to there PCS or PHY until open() is called. So there is no way to
> pass the uAPI calls onto the PCS or PHY if the interface is
> down. There are also some MACs which connect to multiple PCSs, and
> there can be multiple PHYs. So you need to somehow indicate which
> PCS/PHY should perform the PRBS. There was a discussion about loopback
> recently, which has the same issue, you can perform loopback testing
> in multiple places. So i expect the same concept will be used for
> this.

I would think something like this would still be usable. You would
just need to specify the phy address and possibly device address in
the case that you support doing such testing at multiple layers.
Basically it would be up to the driver to provide a way to connect the
request with the desired interface. I would imagine something similar
is the case for the loopback handling since there are so many layers
where you can hairpin things back to the port it came in on.

> > 2. Once testing starts the driver removes the netdev to prevent use. The netdev
> > is only added back when testing stops. The upstream solution will need
> > something that can keep the netdev but lock everything down while testing is
> > running.
>
> Probably IF_OPER_TESTING would be part of this. If the interface is in
> this state, you want many other things blocked. However, probably
> ksettings get/set need to work, so you can force the link into a
> specific mode.

I would imagine it depends on if you want to enforce ordering on this
or not. I would say the set would probably need to be blocked as you
wouldn't normally want to be changing the setting in the middle of a
test as it would cause the error stats to climb quickly.

> > 3. Once testing starts you cannot change the test, even on an individual lane
> > basis. You must stop testing first.
> >
> >
> >     Traditionally, Unix does not offer a way to clear statistic counters
> >     back to zero. So i'm not sure about clear-stats. We also need to think
> >     about hardware which does not support that. And there is locking
> >     issues, can the stats be cleared while a test is active?
> >
> > fbnic actually has separate registers for PRBS test results. Results do need to
> > be clean between runs but I never created an explicit clear interface. Firmware
> > automatically reset the registers when a new test was started. This also allows
> > results to be viewed after testing has stopped.
>
> We should really take 802.3 as the model, but i've not had time yet to
> read what it says about the statistics.

I think most of this is all called out in the IEEE 802.3-2022 spec
under section 45.2.1.169 - 45.2.1.174. Basically the ability and
controls live in the 1500 range, Tx error statistics in the 1600, and
Rx statistics in the 1700 range.

> > Reading results was a little tricky due to roll over between two 32bit
> > registers.
>
> 802.3 is make this even more interesting, since those registers are 16
> bits.

Yeah, normally to deal with something like that we would likely be
looking at having to maintain a fairly high read frequency. Although
in theory the error counts shouldn't be climbing that fast anyway. The
spec calls out that the registers are clear on read and held at ~0 in
the event of overflow which would be a failing case for any reasonable
test anyway.

> > When I spoke to hardware engineers at Meta they did not want a timeout. Testing
> > often occurred over days, so they wanted to be able to start it and explicitly
> > stop it. I'm not against a time out but I do think it should be optional.
> >
> > Since PRBS testing is handled by firmware one safety measure I added is if
> > firmware lost contact with the host testing was automatically stopped and TX
> > FIR values were reset to factory. This ensured that the NIC won't get stuck in
> > testing and on initialization the driver doesn't have to worry about testing
> > state.
>
> That will work for firmware, but not when Linux is driving the
> hardware. I don't know if netlink will allow it, or if RTNL will get
> in the way etc, but it could be we actually don't want a start and
> stop commands at all, it is a blocking netlink call, and the test runs
> until the user space process closes the socket?

What we would probably need to do is look at testing as a state rather
than an operation. Basically the NIC would be put into the testing
state and as a result it would just be sitting there emitting whatever
test pattern it is supposed to emit, and validating it is receiving
the pattern it expects to receive.

The statistics could probably just be a subset of the PHY statistics
that could be collected separately. Actually now that I think about it
I wonder if we couldn't look at putting together the interface similar
to how we currently handle FEC where you have the --set-fec interface
to configure things and the --show-fec interface with the -I option to
show the current state and also dump the statistics.

RE: Ethtool : PRBS feature

[Das, Shubham]

Hi All,

Below are the proposed modifications to the UAPI, data structures, and Netlink messages to support PRBS/BERT and test pattern configuration.

diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
index 5e9135e3774f..cb11e139dd81 100644
--- a/Documentation/netlink/specs/ethtool.yaml
+++ b/Documentation/netlink/specs/ethtool.yaml
@@ -30,6 +30,36 @@ definitions:
+    name: phy-test-pattern
+    enum-name: phy-test-pattern
+    type: enum
+    name-prefix: phy-test-pattern-
+    doc: PRBS and other PHY test patterns
+    entries:
+      - off
+      - prbs7
+      - prbs9
+      - prbs11
+      - prbs13
+      - prbs15
+      - prbs23
+      - prbs31
+      - ssprq
+      - prbs13q
+      - prbs31q
+      - square
+  -
+    name: phy-test-action
+    enum-name: phy-test-action
+    type: enum
+    name-prefix: phy-test-action-
+    doc: Actions for PHY BERT test control
+    entries:
+      - none
+      - start
+      - stop
+      - stats
   -
     name: header-flags
     type: flags
@@ -1818,6 +1848,58 @@ attribute-sets:
         type: u32
         enum: loopback-type
 
+  -
+    name: phy-test
+    attr-cnt-name: __ethtool-a-phy-test-cnt
+    doc: |
+      PHY test configuration for pattern generation/checking,
+      BERT (Bit Error Rate Test), and statistics.
+    attributes:
+      -
+        name: unspec
+        type: unused
+        value: 0
+      -
+        name: header
+        type: nest
+        nested-attributes: header
+      -
+        name: tx-pattern
+        type: u32
+        doc: TX test pattern type (PRBS or square wave)
+        enum: phy-test-pattern
+      -
+        name: rx-pattern
+        type: u32
+        doc: RX checker pattern type (PRBS or square wave)
+        enum: phy-test-pattern
+      -
+        name: bert-action
+        type: u32
+        doc: BERT test start/stop/stats
+        enum: phy-test-action
+      -
+        name: inject-error-count
+        type: u32
+        doc: |
+          Number of errors to inject. Each invocation injects the specified
+          number of bit errors into the data stream.
+      -
+        name: ber-lock-status
+        type: u8
+        doc: PRBS lock status (1=locked, 0=not locked)
+      -
+        name: ber-error-count
+        type: u64
+        doc: BERT bit error count
+      -
+        name: ber-total-bits-sent
+        type: u64
+        doc: BERT total bits tested
+      -
+        name: supported-test-patterns
+        type: u32
+        doc: Bitmask of supported test patterns
 
   -
     name: phy-tunable
@@ -2924,6 +3006,53 @@ operations:
            - header
            - enabled
            - type
+    -
+      name: phy-test-act
+      doc: |
+        Configure PHY test parameters. Each attribute is optional and only
+        specified attributes are applied. TX/RX patterns are set on the
+        local port. BERT and error injection operate on the receiver port.
+        When bert-action is stats, a reply with BERT counters is returned.
+        Typical workflow:
+          ethtool --phy-test eth1 tx-pattern prbs7  (TX side)
+          ethtool --phy-test eth2 rx-pattern prbs7  (RX side)
+          ethtool --phy-test eth2 bert start        (start BERT on RX)
+          ethtool --phy-test eth2 bert stats        (read counters and lock status)
+          ethtool --phy-test eth2 bert stop         (stop BERT)
+
+      attribute-set: phy-test
+
+      do:
+        request:
+          attributes:
+            - header
+            - tx-pattern
+            - rx-pattern
+            - bert-action
+            - inject-error-count
+        reply:
+          attributes:
+            - header
+            - ber-lock-status
+            - ber-error-count
+            - ber-total-bits-sent
+    -
+      name: phy-test-get
+      doc: |
+        Get PHY test configuration status and supported patterns.
+
+      attribute-set: phy-test
+
+      do:
+        request:
+          attributes:
+            - header
+        reply:
+          attributes:
+            - header
+            - tx-pattern
+            - rx-pattern
+            - supported-test-patterns
 
 mcast-groups:
   list:
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 1ac85b8aebd7..3bcca506cf7b 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h

+/* Bitmask of which ethtool_phy_test fields were explicitly specified */
+#define PHY_TEST_CMD_TX_PATTERN		    BIT(0)
+#define PHY_TEST_CMD_RX_PATTERN		    BIT(1)
+#define PHY_TEST_CMD_BERT_ACTION	    BIT(2)
+#define PHY_TEST_CMD_INJECT_COUNT	    BIT(3)
+
+/**
+ * struct ethtool_phy_test - PHY test configuration and status
+ * @cmd: Bitmask of PHY_TEST_CMD_* indicating which fields to apply (SET)
+ * @tx_pattern: TX test pattern
+ * @rx_pattern: RX checker pattern
+ * @bert_action: BERT start/stop/stats action
+ * @inject_error_count: Number of bit errors to inject (SET only)
+ * @supported_test_patterns: Bitmask of supported patterns (GET only)
+ * @ber_lock_status: BER lock status 1=locked, 0=not locked (GET only)
+ * @ber_error_count: BERT bit error count (GET only)
+ * @ber_total_bits_sent: BERT total bits tested (GET only)
+ */
+struct ethtool_phy_test {
+	u32 cmd;
+	enum phy_test_pattern tx_pattern;
+	enum phy_test_pattern rx_pattern;
+	enum phy_test_action bert_action;
+	u32 inject_error_count;
+	u32 supported_test_patterns;
+	u8 ber_lock_status;
+	u64 ber_error_count;
+	u64 ber_total_bits_sent;
+};
+
 /**
  * struct ethtool_ops - optional netdev operations
  * @supported_input_xfrm: supported types of input xfrm from %RXH_XFRM_*.
@@ -1091,7 +1121,8 @@ struct ethtool_loopback {
  * @get_mm: Query the 802.3 MAC Merge layer state.
  * @set_mm: Set the 802.3 MAC Merge layer parameters.
  * @get_mm_stats: Query the 802.3 MAC Merge layer statistics.
- *
+ * @get_phy_test: Get PHY test status, patterns, and BERT counters.
+ * @set_phy_test: Configure PHY test (pattern, BERT, error injection). *
  * All operations are optional (i.e. the function pointer may be set
  * to %NULL) and callers must take this into account.  Callers must
  * hold the RTNL lock.
@@ -1260,6 +1291,10 @@ struct ethtool_ops {
 	void	(*get_mm_stats)(struct net_device *dev, struct ethtool_mm_stats *stats);
+	int	(*get_phy_test)(struct net_device *dev,
+				struct ethtool_phy_test *test);
+	int	(*set_phy_test)(struct net_device *dev,
+				struct ethtool_phy_test *test);
 };


The 'tx_prbs' and 'rx_prbs' command parameters have been renamed to 'tx_pattern' and 'rx_pattern' to allow support
for additional test patterns defined in the RFC, such as square patterns, in addition to PRBS.

The statistics have been moved to the 'ber' test command.

I also think it would be better to expose 'tx_pattern' and 'rx_pattern' as separate commands,
since the TX and RX ports can be different. They are only the same when operating in loopback mode.


> You need to think about the units for inject errors. There is no floating point support. Also, is this corrupt packets? 
> Or single bit flips in the stream? It needs to be well defined what it actually means. The driver can then convert it to whatever the hardware supports. How does 802.3 specify this?

I believe it is not mentioned in IEEE specs, But it will be helpful in debug in both data and PRBS mode.
Maybe we can have number of errors injected in steam when we issue command rather than error rate ?


> Traditionally, Unix does not offer a way to clear statistic counters back to zero. So i'm not sure about clear-stats.
> We also need to think about hardware which does not support that. And there is locking issues, can the stats be cleared while a test is active? 

I think we can auto clear in PHY FW or in implementation when we start the test.

Also, as previously suggested we need new status to indicate device is under test for net device.
 
- Shubham D

> -----Original Message-----
> From: Alexander Duyck <alexander.duyck@gmail.com>
> Sent: 24 June 2026 21:06
> To: Andrew Lunn <andrew@lunn.ch>
> Cc: Lee Trager <lee@trager.us>; Das, Shubham <shubham.das@intel.com>;
> Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org;
> mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle,
> Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
> Subject: Re: Ethtool : PRBS feature
> 
> On Tue, Jun 23, 2026 at 7:30 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > >     To avoid race conditions, maybe some of these commands need combining.
> > >     ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
> > >
> > >     The configuration is then atomic, with respect to the uAPI, so we
> > >     don't get two users configuring it at the same time, ending up with a
> > >     messed up configuration.
> > >
> > > Testing consumes the link so you really don't want anything done to
> > > the netdev while testing is running. fbnic does the following.
> > >
> > > 1. Testing cannot start when the link is up
> >
> > That is not going to work in the generic case. Many MAC drivers don't
> > bind to there PCS or PHY until open() is called. So there is no way to
> > pass the uAPI calls onto the PCS or PHY if the interface is down.
> > There are also some MACs which connect to multiple PCSs, and there can
> > be multiple PHYs. So you need to somehow indicate which PCS/PHY should
> > perform the PRBS. There was a discussion about loopback recently,
> > which has the same issue, you can perform loopback testing in multiple
> > places. So i expect the same concept will be used for this.
> 
> I would think something like this would still be usable. You would just need to
> specify the phy address and possibly device address in the case that you support
> doing such testing at multiple layers.
> Basically it would be up to the driver to provide a way to connect the request with
> the desired interface. I would imagine something similar is the case for the
> loopback handling since there are so many layers where you can hairpin things
> back to the port it came in on.
> 
> > > 2. Once testing starts the driver removes the netdev to prevent use.
> > > The netdev is only added back when testing stops. The upstream
> > > solution will need something that can keep the netdev but lock
> > > everything down while testing is running.
> >
> > Probably IF_OPER_TESTING would be part of this. If the interface is in
> > this state, you want many other things blocked. However, probably
> > ksettings get/set need to work, so you can force the link into a
> > specific mode.
> 
> I would imagine it depends on if you want to enforce ordering on this or not. I
> would say the set would probably need to be blocked as you wouldn't normally
> want to be changing the setting in the middle of a test as it would cause the error
> stats to climb quickly.
> 
> > > 3. Once testing starts you cannot change the test, even on an
> > > individual lane basis. You must stop testing first.
> > >
> > >
> > >     Traditionally, Unix does not offer a way to clear statistic counters
> > >     back to zero. So i'm not sure about clear-stats. We also need to think
> > >     about hardware which does not support that. And there is locking
> > >     issues, can the stats be cleared while a test is active?
> > >
> > > fbnic actually has separate registers for PRBS test results. Results
> > > do need to be clean between runs but I never created an explicit
> > > clear interface. Firmware automatically reset the registers when a
> > > new test was started. This also allows results to be viewed after testing has
> stopped.
> >
> > We should really take 802.3 as the model, but i've not had time yet to
> > read what it says about the statistics.
> 
> I think most of this is all called out in the IEEE 802.3-2022 spec under section
> 45.2.1.169 - 45.2.1.174. Basically the ability and controls live in the 1500 range,
> Tx error statistics in the 1600, and Rx statistics in the 1700 range.
> 
> > > Reading results was a little tricky due to roll over between two
> > > 32bit registers.
> >
> > 802.3 is make this even more interesting, since those registers are 16
> > bits.
> 
> Yeah, normally to deal with something like that we would likely be looking at
> having to maintain a fairly high read frequency. Although in theory the error
> counts shouldn't be climbing that fast anyway. The spec calls out that the registers
> are clear on read and held at ~0 in the event of overflow which would be a failing
> case for any reasonable test anyway.
> 
> > > When I spoke to hardware engineers at Meta they did not want a
> > > timeout. Testing often occurred over days, so they wanted to be able
> > > to start it and explicitly stop it. I'm not against a time out but I do think it
> should be optional.
> > >
> > > Since PRBS testing is handled by firmware one safety measure I added
> > > is if firmware lost contact with the host testing was automatically
> > > stopped and TX FIR values were reset to factory. This ensured that
> > > the NIC won't get stuck in testing and on initialization the driver
> > > doesn't have to worry about testing state.
> >
> > That will work for firmware, but not when Linux is driving the
> > hardware. I don't know if netlink will allow it, or if RTNL will get
> > in the way etc, but it could be we actually don't want a start and
> > stop commands at all, it is a blocking netlink call, and the test runs
> > until the user space process closes the socket?
> 
> What we would probably need to do is look at testing as a state rather than an
> operation. Basically the NIC would be put into the testing state and as a result it
> would just be sitting there emitting whatever test pattern it is supposed to emit,
> and validating it is receiving the pattern it expects to receive.
> 
> The statistics could probably just be a subset of the PHY statistics that could be
> collected separately. Actually now that I think about it I wonder if we couldn't
> look at putting together the interface similar to how we currently handle FEC
> where you have the --set-fec interface to configure things and the --show-fec
> interface with the -I option to show the current state and also dump the
> statistics.

Re: Ethtool : PRBS feature

[Andrew Lunn]

> +        name: inject-error-count
> +        type: u32
> +        doc: |
> +          Number of errors to inject. Each invocation injects the specified
> +          number of bit errors into the data stream.

Sorry, but i could not implement that, in a sensible way, given its
current specification.

I suppose i could simply flip the first `inject-error-count` bits, and
make the rest of the stream perfect? I could also wait until the stop
command is received, and then flip that many bits before i stop the
stream? But none of these seem sensible.

Please make this specification have sufficient details, or references
to 802.3, that you could give it to another engineer and get back a
reasonable implementation, without having to answer any questions.

> +      name: phy-test-act
> +      doc: |
> +        Configure PHY test parameters. Each attribute is optional and only
> +        specified attributes are applied. TX/RX patterns are set on the
> +        local port. BERT and error injection operate on the receiver port.

Error injection operates on the receive port? That is not what i
expected. I should go read 802.3, and understand how this is used.

	Andrew

RE: Ethtool : PRBS feature

[Das, Shubham]

> Sorry, but i could not implement that, in a sensible way, given its current
> specification.
> 
> I suppose i could simply flip the first `inject-error-count` bits, and make the rest of
> the stream perfect? I could also wait until the stop command is received, and
> then flip that many bits before i stop the stream? But none of these seem
> sensible.
> 
> Please make this specification have sufficient details, or references to 802.3, that
> you could give it to another engineer and get back a reasonable implementation,
> without having to answer any questions.

Andrew,

IEEE has clear documentation of the PRBS Receiver block and the BER counter as an output.
Before performing the actual BER validation, it is a usual industry practice to introduce errors
to guarantee that the checker is functional and accurately identifying them.

Similarly, in DATA mode, error injection is used to verify the FEC block
by ensuring that injected errors are detected and corrected as expected.

Updated description.

+        name: inject-error-count
+        type: u32
+        doc: |
+          Request the PHY to inject exactly this many bit errors into the
+          currently active test data stream.
+
+          This is a diagnostic tool used to validate that the far-end PRBS
+          checker or FEC decoder is functioning correctly. For example,
+          after enabling a PRBS pattern and confirming ber-lock-status is
+          locked, injecting N errors should cause ber-error-count to
+          increment by exactly N on the receiving port, confirming the
+          checker is actively detecting bit errors. Similarly, in normal
+          data mode with FEC enabled, injecting errors verifies that the
+          FEC block detects errors as expected.

> > +      name: phy-test-act
> > +      doc: |
> > +        Configure PHY test parameters. Each attribute is optional and only
> > +        specified attributes are applied. TX/RX patterns are set on the
> > +        local port. BERT and error injection operate on the receiver port.
> 
> Error injection operates on the receive port? That is not what i expected. I should
> go read 802.3, and understand how this is used.

Thanks for the correction, it is in transmit direction, Updated description.

+      name: phy-test-act
+      doc: |
+        Configure PHY test parameters. Each attribute is optional and only
+        specified attributes are applied. TX/RX patterns are set on the
+        local port. BERT operates on the receiver port, while errors
+        are injected through the PRBS/DATA transmission port. 
+        When bert-action is stats, a reply with BERT counters is returned.
+        Typical workflow:
+          ethtool --phy-test eth1 tx-pattern prbs7  (TX side)
+          ethtool --phy-test eth2 rx-pattern prbs7  (RX side)
+          ethtool --phy-test eth2 bert start        (start BERT on RX)
+          ethtool --phy-test eth2 bert stats        (read counters)
+          ethtool --phy-test eth2 bert stop         (stop BERT)

- Shubham D


> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 29 June 2026 22:27
> To: Das, Shubham <shubham.das@intel.com>
> Cc: Alexander Duyck <alexander.duyck@gmail.com>; Lee Trager <lee@trager.us>;
> Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org;
> mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle,
> Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus
> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
> Subject: Re: Ethtool : PRBS feature
> 
> > +        name: inject-error-count
> > +        type: u32
> > +        doc: |
> > +          Number of errors to inject. Each invocation injects the specified
> > +          number of bit errors into the data stream.
> 
> Sorry, but i could not implement that, in a sensible way, given its current
> specification.
> 
> I suppose i could simply flip the first `inject-error-count` bits, and make the rest of
> the stream perfect? I could also wait until the stop command is received, and
> then flip that many bits before i stop the stream? But none of these seem
> sensible.
> 
> Please make this specification have sufficient details, or references to 802.3, that
> you could give it to another engineer and get back a reasonable implementation,
> without having to answer any questions.
> 
> > +      name: phy-test-act
> > +      doc: |
> > +        Configure PHY test parameters. Each attribute is optional and only
> > +        specified attributes are applied. TX/RX patterns are set on the
> > +        local port. BERT and error injection operate on the receiver port.
> 
> Error injection operates on the receive port? That is not what i expected. I should
> go read 802.3, and understand how this is used.
> 
> 	Andrew

Re: Ethtool : PRBS feature

[Andrew Lunn]

On Wed, Jul 01, 2026 at 05:10:43PM +0000, Das, Shubham wrote:
> > Sorry, but i could not implement that, in a sensible way, given its current
> > specification.
> > 
> > I suppose i could simply flip the first `inject-error-count` bits, and make the rest of
> > the stream perfect? I could also wait until the stop command is received, and
> > then flip that many bits before i stop the stream? But none of these seem
> > sensible.
> > 
> > Please make this specification have sufficient details, or references to 802.3, that
> > you could give it to another engineer and get back a reasonable implementation,
> > without having to answer any questions.
> 
> Andrew,
> 
> IEEE has clear documentation of the PRBS Receiver block and the BER counter as an output.
> Before performing the actual BER validation, it is a usual industry practice to introduce errors
> to guarantee that the checker is functional and accurately identifying them.
> 
> Similarly, in DATA mode, error injection is used to verify the FEC block
> by ensuring that injected errors are detected and corrected as expected.
> 
> Updated description.
> 
> +        name: inject-error-count
> +        type: u32
> +        doc: |
> +          Request the PHY to inject exactly this many bit errors into the
> +          currently active test data stream.
> +
> +          This is a diagnostic tool used to validate that the far-end PRBS
> +          checker or FEC decoder is functioning correctly. For example,
> +          after enabling a PRBS pattern and confirming ber-lock-status is
> +          locked, injecting N errors should cause ber-error-count to
> +          increment by exactly N on the receiving port, confirming the
> +          checker is actively detecting bit errors. Similarly, in normal
> +          data mode with FEC enabled, injecting errors verifies that the
> +          FEC block detects errors as expected.

There is no mention of how many frames to send in the stream. I don't
think that is part of the API? Because we have no idea of how many
frames will be sent, it is not possible to distribute the corrupted
frames over the duration of the stream. So that means i should flip
one bit, anywhere in the first inject-error-count frames. All frames
after that should not have bit flips. The assumption being, the stream
has a minimum of inject-error-count frames, and if the stream is
short, the counter will be too low. But it does not matter if the
stream is longer.

Your description has no mention of frames. Should it? What exactly
does the ber-error-count count? Can multiple bit flip within one frame
be counted individually? I don't see how, since the checksum just says
the frame is bad, and cannot report how bad.

As i said, give this description to another engineer and ask him/her
how it could be implemented.

https://www.youtube.com/watch?v=j-6N3bLgYyQ

	Andrew

Re: Ethtool : PRBS feature

[Srinivasan, Vijay]

[-- Attachment #1.1: Type: text/plain, Size: 6186 bytes --]

Hi Andrew,
I think there is a disconnect here. Please see the diagram attached indicating the error injection location.
Here, we are referring to error injection at the "bit" level, not "frame" level.
Bit error(s) injected at the PMA/PMD boundary, does not distinguish between data (Frames) vs test patterns (PRBS).
Many SerDes IP's , if not all, include error injection as part of the test pattern block (BIST in the diagram).
Some IP's may have error injection outside of BIST in the common data path (as shown in the diagram) in which case bit errors may be injected in both data mode (frame/traffic) and test pattern mode (BIST).
Regardless, we are seeking error injection capability at PMA/PMD to be made available through user/driver space (ethtool) .

Notes:

  1.
Error injection can be "one-shot" (single error) or continuous (fixed rate, say 1 bit error every 10**6 bits (1E-6)).
  2.
Error injection availability is IP/API dependent. One-shot mode is highly likely to be available in all SerDes IP's.
  3.
Error injection location and implementation is IP dependent.
  4.
If IP/API supported:
     *
One-shot error injected in test pattern (PRBS) mode captured as individual/single bit error at the far-end checker.
     *
One-shot error injected in data (traffic/frame) mode captured as:
        *
Individual/single corrected codeword error if FEC is used for the link
        *
Individual/single CRC:  (a) if FEC is not used for the link and (b) if bit error injected corrupts any of the bits used to compute CRC.
     *
Effect of errors injected at fixed rate is a corollary to one-shot with additional :
        *
Errors injected at higher rates (> 1E-4) may result in uncorrected FEC codewords or loss of link
        *
Presence of uncorrected FEC codewords will lead to MAC CRCs

What is requested:

  1.
One-shot bit error injection (required/preferred), fixed rate is optional

How to inject error:

  1.
Test pattern mode:
     *
Generate any PRBS pattern
     *
Configure error checker on receive side (same device in loopback mode or far-end device) - measure Bit Error Ratio (BER) without error injection
     *
Inject error and verify BER>0 (if BER==0 without injection)
  2.
Data (Traffic/Frame) mode:
     *
Configure and establish link (same device in loopback mode or far-end device)
     *
Measure MAC CRC and/or FEC corrected/uncorrected codeword counts
     *
Inject error and verify MAC CRC or FEC corrected counts match injected error count



Vijay

________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, July 1, 2026 10:32 AM
To: Das, Shubham <shubham.das@intel.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>; Lee Trager <lee@trager.us>; Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org <netdev@vger.kernel.org>; mkubecek@suse.cz <mkubecek@suse.cz>; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle, Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com <niklas.damberg@ericsson.com>; Wirandi, Jonas <jonas.wirandi@ericsson.com>; Srinivasan, Vijay <vijay.srinivasan@intel.com>
Subject: Re: Ethtool : PRBS feature

On Wed, Jul 01, 2026 at 05:10:43PM +0000, Das, Shubham wrote:
> > Sorry, but i could not implement that, in a sensible way, given its current
> > specification.
> >
> > I suppose i could simply flip the first `inject-error-count` bits, and make the rest of
> > the stream perfect? I could also wait until the stop command is received, and
> > then flip that many bits before i stop the stream? But none of these seem
> > sensible.
> >
> > Please make this specification have sufficient details, or references to 802.3, that
> > you could give it to another engineer and get back a reasonable implementation,
> > without having to answer any questions.
>
> Andrew,
>
> IEEE has clear documentation of the PRBS Receiver block and the BER counter as an output.
> Before performing the actual BER validation, it is a usual industry practice to introduce errors
> to guarantee that the checker is functional and accurately identifying them.
>
> Similarly, in DATA mode, error injection is used to verify the FEC block
> by ensuring that injected errors are detected and corrected as expected.
>
> Updated description.
>
> +        name: inject-error-count
> +        type: u32
> +        doc: |
> +          Request the PHY to inject exactly this many bit errors into the
> +          currently active test data stream.
> +
> +          This is a diagnostic tool used to validate that the far-end PRBS
> +          checker or FEC decoder is functioning correctly. For example,
> +          after enabling a PRBS pattern and confirming ber-lock-status is
> +          locked, injecting N errors should cause ber-error-count to
> +          increment by exactly N on the receiving port, confirming the
> +          checker is actively detecting bit errors. Similarly, in normal
> +          data mode with FEC enabled, injecting errors verifies that the
> +          FEC block detects errors as expected.

There is no mention of how many frames to send in the stream. I don't
think that is part of the API? Because we have no idea of how many
frames will be sent, it is not possible to distribute the corrupted
frames over the duration of the stream. So that means i should flip
one bit, anywhere in the first inject-error-count frames. All frames
after that should not have bit flips. The assumption being, the stream
has a minimum of inject-error-count frames, and if the stream is
short, the counter will be too low. But it does not matter if the
stream is longer.

Your description has no mention of frames. Should it? What exactly
does the ber-error-count count? Can multiple bit flip within one frame
be counted individually? I don't see how, since the checksum just says
the frame is bad, and cannot report how bad.

As i said, give this description to another engineer and ask him/her
how it could be implemented.

https://www.youtube.com/watch?v=j-6N3bLgYyQ

        Andrew

[-- Attachment #1.2: Type: text/html, Size: 16159 bytes --]

[-- Attachment #2: Error Injection at Bit Level.pdf --]
[-- Type: application/pdf, Size: 38062 bytes --]

Re: Ethtool : PRBS feature

[Andrew Lunn]

On Wed, Jul 01, 2026 at 09:38:08PM +0000, Srinivasan, Vijay wrote:
> Hi Andrew,
> I think there is a disconnect here.

Which proves my point. The specification is not sufficient if you have
to keep correcting me.

The kAPI should be understandable by somebody who has a general
networking background. Please write a specification with that
assumption in mind. Don't assume the reader is a test engineer who has
used PRBS for half his life. Assume it is a brand new test engineer
who is hearing PRBS for the first time. That is what most engineers on
the netdev list are. Me included.

    Andrew

Re: Ethtool : PRBS feature

[Lee Trager]

On 6/29/26 9:15 AM, Das, Shubham wrote:

> Hi All,
>
> Below are the proposed modifications to the UAPI, data structures, and Netlink messages to support PRBS/BERT and test pattern configuration.
>
> diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
> index 5e9135e3774f..cb11e139dd81 100644
> --- a/Documentation/netlink/specs/ethtool.yaml
> +++ b/Documentation/netlink/specs/ethtool.yaml
> @@ -30,6 +30,36 @@ definitions:
> +    name: phy-test-pattern
> +    enum-name: phy-test-pattern
> +    type: enum
> +    name-prefix: phy-test-pattern-
> +    doc: PRBS and other PHY test patterns
> +    entries:
> +      - off
> +      - prbs7
> +      - prbs9
> +      - prbs11

fbnic supports a number of other tests as well. Getting the full list of 
common PRBS tests codified would be ideal

- prbs11.0

- prbs11.1

- prbs11.2

- prbs11.3

> +      - prbs13

  - prbs13.0

- prbs13.1

- prbs13.2

- prbs13.3

> +      - prbs15
- prbs16
> +      - prbs23
> +      - prbs31
- prbs32
> +      - ssprq
> +      - prbs13q
> +      - prbs31q
> +      - square
> +  -
> +    name: phy-test-action
> +    enum-name: phy-test-action
Each lane and each direction is a completely separate test with its own 
test of statistics. The test is actually verified on the Rx side, Tx is 
your generator so you won't have data to collect. So when you run PRBS 
testing on a 2 lane NIC you are actually running 4 independent tests. 
While its fine to have a shortcut to run the same test on all lanes we 
absolutely need a way to run tests per lane and the ability to choose 
Rx, Tx, or both.
> +    type: enum
> +    name-prefix: phy-test-action-
> +    doc: Actions for PHY BERT test control
> +    entries:
> +      - none
> +      - start
> +      - stop
> +      - stats
I wouldn't consider stats a phy-test action. It shouldn't change the 
state of the NIC at all. I would just add phy-test-stats as set of 
standard ethtool statistics.
>     -
>       name: header-flags
>       type: flags
> @@ -1818,6 +1848,58 @@ attribute-sets:
>           type: u32
>           enum: loopback-type
>   
> +  -
> +    name: phy-test
> +    attr-cnt-name: __ethtool-a-phy-test-cnt
> +    doc: |
> +      PHY test configuration for pattern generation/checking,
> +      BERT (Bit Error Rate Test), and statistics.
> +    attributes:
> +      -
> +        name: unspec
> +        type: unused
> +        value: 0
> +      -
> +        name: header
> +        type: nest
> +        nested-attributes: header
> +      -
> +        name: tx-pattern
> +        type: u32
> +        doc: TX test pattern type (PRBS or square wave)
> +        enum: phy-test-pattern
> +      -
> +        name: rx-pattern
> +        type: u32
> +        doc: RX checker pattern type (PRBS or square wave)
> +        enum: phy-test-pattern
> +      -
> +        name: bert-action
> +        type: u32
> +        doc: BERT test start/stop/stats
> +        enum: phy-test-action
> +      -
> +        name: inject-error-count
> +        type: u32
> +        doc: |
> +          Number of errors to inject. Each invocation injects the specified
> +          number of bit errors into the data stream.
> +      -
> +        name: ber-lock-status
> +        type: u8
> +        doc: PRBS lock status (1=locked, 0=not locked)
> +      -
> +        name: ber-error-count
> +        type: u64
> +        doc: BERT bit error count
> +      -
> +        name: ber-total-bits-sent
> +        type: u64
> +        doc: BERT total bits tested
> +      -
> +        name: supported-test-patterns
> +        type: u32
> +        doc: Bitmask of supported test patterns
Again all of this needs to be per lane.
>   
>     -
>       name: phy-tunable
> @@ -2924,6 +3006,53 @@ operations:
>              - header
>              - enabled
>              - type
> +    -
> +      name: phy-test-act
> +      doc: |
> +        Configure PHY test parameters. Each attribute is optional and only
> +        specified attributes are applied. TX/RX patterns are set on the
> +        local port. BERT and error injection operate on the receiver port.
> +        When bert-action is stats, a reply with BERT counters is returned.
> +        Typical workflow:
> +          ethtool --phy-test eth1 tx-pattern prbs7  (TX side)
> +          ethtool --phy-test eth2 rx-pattern prbs7  (RX side)
> +          ethtool --phy-test eth2 bert start        (start BERT on RX)
> +          ethtool --phy-test eth2 bert stats        (read counters and lock status)
> +          ethtool --phy-test eth2 bert stop         (stop BERT)
> +
> +      attribute-set: phy-test
> +
> +      do:
> +        request:
> +          attributes:
> +            - header
> +            - tx-pattern
> +            - rx-pattern
> +            - bert-action
> +            - inject-error-count
> +        reply:
> +          attributes:
> +            - header
> +            - ber-lock-status
> +            - ber-error-count
> +            - ber-total-bits-sent
> +    -
> +      name: phy-test-get
> +      doc: |
> +        Get PHY test configuration status and supported patterns.
> +
> +      attribute-set: phy-test
> +
> +      do:
> +        request:
> +          attributes:
> +            - header
> +        reply:
> +          attributes:
> +            - header
> +            - tx-pattern
> +            - rx-pattern
> +            - supported-test-patterns
>   
>   mcast-groups:
>     list:
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 1ac85b8aebd7..3bcca506cf7b 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
>
> +/* Bitmask of which ethtool_phy_test fields were explicitly specified */
> +#define PHY_TEST_CMD_TX_PATTERN		    BIT(0)
> +#define PHY_TEST_CMD_RX_PATTERN		    BIT(1)
> +#define PHY_TEST_CMD_BERT_ACTION	    BIT(2)
> +#define PHY_TEST_CMD_INJECT_COUNT	    BIT(3)
> +
> +/**
> + * struct ethtool_phy_test - PHY test configuration and status
> + * @cmd: Bitmask of PHY_TEST_CMD_* indicating which fields to apply (SET)
> + * @tx_pattern: TX test pattern
> + * @rx_pattern: RX checker pattern
> + * @bert_action: BERT start/stop/stats action
> + * @inject_error_count: Number of bit errors to inject (SET only)
> + * @supported_test_patterns: Bitmask of supported patterns (GET only)
> + * @ber_lock_status: BER lock status 1=locked, 0=not locked (GET only)
> + * @ber_error_count: BERT bit error count (GET only)
> + * @ber_total_bits_sent: BERT total bits tested (GET only)
> + */
> +struct ethtool_phy_test {
> +	u32 cmd;
> +	enum phy_test_pattern tx_pattern;
> +	enum phy_test_pattern rx_pattern;
> +	enum phy_test_action bert_action;
> +	u32 inject_error_count;
> +	u32 supported_test_patterns;
> +	u8 ber_lock_status;
> +	u64 ber_error_count;
> +	u64 ber_total_bits_sent;
> +};
> +
>   /**
>    * struct ethtool_ops - optional netdev operations
>    * @supported_input_xfrm: supported types of input xfrm from %RXH_XFRM_*.
> @@ -1091,7 +1121,8 @@ struct ethtool_loopback {
>    * @get_mm: Query the 802.3 MAC Merge layer state.
>    * @set_mm: Set the 802.3 MAC Merge layer parameters.
>    * @get_mm_stats: Query the 802.3 MAC Merge layer statistics.
> - *
> + * @get_phy_test: Get PHY test status, patterns, and BERT counters.
> + * @set_phy_test: Configure PHY test (pattern, BERT, error injection). *
>    * All operations are optional (i.e. the function pointer may be set
>    * to %NULL) and callers must take this into account.  Callers must
>    * hold the RTNL lock.
> @@ -1260,6 +1291,10 @@ struct ethtool_ops {
>   	void	(*get_mm_stats)(struct net_device *dev, struct ethtool_mm_stats *stats);
> +	int	(*get_phy_test)(struct net_device *dev,
> +				struct ethtool_phy_test *test);
> +	int	(*set_phy_test)(struct net_device *dev,
> +				struct ethtool_phy_test *test);
>   };
>
>
> The 'tx_prbs' and 'rx_prbs' command parameters have been renamed to 'tx_pattern' and 'rx_pattern' to allow support
> for additional test patterns defined in the RFC, such as square patterns, in addition to PRBS.
>
> The statistics have been moved to the 'ber' test command.
>
> I also think it would be better to expose 'tx_pattern' and 'rx_pattern' as separate commands,
> since the TX and RX ports can be different. They are only the same when operating in loopback mode.
>
>
>> You need to think about the units for inject errors. There is no floating point support. Also, is this corrupt packets?
>> Or single bit flips in the stream? It needs to be well defined what it actually means. The driver can then convert it to whatever the hardware supports. How does 802.3 specify this?
> I believe it is not mentioned in IEEE specs, But it will be helpful in debug in both data and PRBS mode.
> Maybe we can have number of errors injected in steam when we issue command rather than error rate ?
>
>
>> Traditionally, Unix does not offer a way to clear statistic counters back to zero. So i'm not sure about clear-stats.
>> We also need to think about hardware which does not support that. And there is locking issues, can the stats be cleared while a test is active?
> I think we can auto clear in PHY FW or in implementation when we start the test.
>
> Also, as previously suggested we need new status to indicate device is under test for net device.
>   
> - Shubham D
>
>> -----Original Message-----
>> From: Alexander Duyck <alexander.duyck@gmail.com>
>> Sent: 24 June 2026 21:06
>> To: Andrew Lunn <andrew@lunn.ch>
>> Cc: Lee Trager <lee@trager.us>; Das, Shubham <shubham.das@intel.com>;
>> Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org;
>> mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle,
>> Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus
>> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
>> Subject: Re: Ethtool : PRBS feature
>>
>> On Tue, Jun 23, 2026 at 7:30 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>>>      To avoid race conditions, maybe some of these commands need combining.
>>>>      ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
>>>>
>>>>      The configuration is then atomic, with respect to the uAPI, so we
>>>>      don't get two users configuring it at the same time, ending up with a
>>>>      messed up configuration.
>>>>
>>>> Testing consumes the link so you really don't want anything done to
>>>> the netdev while testing is running. fbnic does the following.
>>>>
>>>> 1. Testing cannot start when the link is up
>>> That is not going to work in the generic case. Many MAC drivers don't
>>> bind to there PCS or PHY until open() is called. So there is no way to
>>> pass the uAPI calls onto the PCS or PHY if the interface is down.
>>> There are also some MACs which connect to multiple PCSs, and there can
>>> be multiple PHYs. So you need to somehow indicate which PCS/PHY should
>>> perform the PRBS. There was a discussion about loopback recently,
>>> which has the same issue, you can perform loopback testing in multiple
>>> places. So i expect the same concept will be used for this.
>> I would think something like this would still be usable. You would just need to
>> specify the phy address and possibly device address in the case that you support
>> doing such testing at multiple layers.
>> Basically it would be up to the driver to provide a way to connect the request with
>> the desired interface. I would imagine something similar is the case for the
>> loopback handling since there are so many layers where you can hairpin things
>> back to the port it came in on.
>>
>>>> 2. Once testing starts the driver removes the netdev to prevent use.
>>>> The netdev is only added back when testing stops. The upstream
>>>> solution will need something that can keep the netdev but lock
>>>> everything down while testing is running.
>>> Probably IF_OPER_TESTING would be part of this. If the interface is in
>>> this state, you want many other things blocked. However, probably
>>> ksettings get/set need to work, so you can force the link into a
>>> specific mode.
>> I would imagine it depends on if you want to enforce ordering on this or not. I
>> would say the set would probably need to be blocked as you wouldn't normally
>> want to be changing the setting in the middle of a test as it would cause the error
>> stats to climb quickly.
>>
>>>> 3. Once testing starts you cannot change the test, even on an
>>>> individual lane basis. You must stop testing first.
>>>>
>>>>
>>>>      Traditionally, Unix does not offer a way to clear statistic counters
>>>>      back to zero. So i'm not sure about clear-stats. We also need to think
>>>>      about hardware which does not support that. And there is locking
>>>>      issues, can the stats be cleared while a test is active?
>>>>
>>>> fbnic actually has separate registers for PRBS test results. Results
>>>> do need to be clean between runs but I never created an explicit
>>>> clear interface. Firmware automatically reset the registers when a
>>>> new test was started. This also allows results to be viewed after testing has
>> stopped.
>>> We should really take 802.3 as the model, but i've not had time yet to
>>> read what it says about the statistics.
>> I think most of this is all called out in the IEEE 802.3-2022 spec under section
>> 45.2.1.169 - 45.2.1.174. Basically the ability and controls live in the 1500 range,
>> Tx error statistics in the 1600, and Rx statistics in the 1700 range.
>>
>>>> Reading results was a little tricky due to roll over between two
>>>> 32bit registers.
>>> 802.3 is make this even more interesting, since those registers are 16
>>> bits.
>> Yeah, normally to deal with something like that we would likely be looking at
>> having to maintain a fairly high read frequency. Although in theory the error
>> counts shouldn't be climbing that fast anyway. The spec calls out that the registers
>> are clear on read and held at ~0 in the event of overflow which would be a failing
>> case for any reasonable test anyway.
>>
>>>> When I spoke to hardware engineers at Meta they did not want a
>>>> timeout. Testing often occurred over days, so they wanted to be able
>>>> to start it and explicitly stop it. I'm not against a time out but I do think it
>> should be optional.
>>>> Since PRBS testing is handled by firmware one safety measure I added
>>>> is if firmware lost contact with the host testing was automatically
>>>> stopped and TX FIR values were reset to factory. This ensured that
>>>> the NIC won't get stuck in testing and on initialization the driver
>>>> doesn't have to worry about testing state.
>>> That will work for firmware, but not when Linux is driving the
>>> hardware. I don't know if netlink will allow it, or if RTNL will get
>>> in the way etc, but it could be we actually don't want a start and
>>> stop commands at all, it is a blocking netlink call, and the test runs
>>> until the user space process closes the socket?
>> What we would probably need to do is look at testing as a state rather than an
>> operation. Basically the NIC would be put into the testing state and as a result it
>> would just be sitting there emitting whatever test pattern it is supposed to emit,
>> and validating it is receiving the pattern it expects to receive.
>>
>> The statistics could probably just be a subset of the PHY statistics that could be
>> collected separately. Actually now that I think about it I wonder if we couldn't
>> look at putting together the interface similar to how we currently handle FEC
>> where you have the --set-fec interface to configure things and the --show-fec
>> interface with the -I option to show the current state and also dump the
>> statistics.

Re: Ethtool : PRBS feature

[Lee Trager]

On 7/1/26 3:02 PM, Andrew Lunn wrote:

> On Wed, Jul 01, 2026 at 09:38:08PM +0000, Srinivasan, Vijay wrote:
>> Hi Andrew,
>> I think there is a disconnect here.
> Which proves my point. The specification is not sufficient if you have
> to keep correcting me.
>
> The kAPI should be understandable by somebody who has a general
> networking background. Please write a specification with that
> assumption in mind. Don't assume the reader is a test engineer who has
> used PRBS for half his life. Assume it is a brand new test engineer
> who is hearing PRBS for the first time. That is what most engineers on
> the netdev list are. Me included.

I think part of the disconnect is that PRBS testing is a signal 
integrity test, not a network test. In this case the phy happens to be 
Ethernet but it could just as easily be PCIE or USB. That is why it was 
heavily suggested to me at netdev 0x19 that this should be done on the 
generic phy layer, not netdev.

Lee