Re: Ethtool : PRBS feature

On Fri, Jul 24, 2026 at 8:26 AM Das, Shubham [off-list ref] wrote:

Thanks, Maxime, for summarizing the PRBS discussion from Netdev conference.

Based on the discussion, I'd like to propose the following changes to
the current PRBS proposal. Add a new command:

ethtool --interface-capabilities

This command would expose the interface hardware layout and enumerate all
available functional blocks, including their layer, block ID, and supported hardware
capabilities such as loopback, PRBS generation/checking, BERT, error injection,
and other test operations.

The interface layout is summarized below.
+-------------------------------------------------------------------------------------------------------------------------------------+
|Block        Name                  Component       Sublayer       Depth          Loopback                 PRBS                 |
|------------------------------------------------------------------------------------------------------------------------------------ |
|1            host-mac                    MAC                  RS                  0             Local, Remote              N/A                 |
|2            host-pcs                      PHY                  PCS                 0             Local, Remote              N/A                 |
|3            host-pma                    PHY                  PMA               0             Local, Remote     prbs7-31, ssprq     |
|4            host-pmd                    PHY                  PMD               0             Local, Remote              N/A                |
|5            ext-phy-host-pcs        PHY                  PCS                 0             Local, Remote              N/A                |
|6            ext-phy-host-pma      PHY                  PMA               0             Local, Remote      prbs7-31, ssprq   |
|7            ext-phy-line-pcs         PHY                  PCS                 1             Local, Remote               N/A               |
|8            ext-phy-line-pma       PHY                  PMA               1             Local, Remote      prbs7-31, ssprq   |
|9            ext-pma                       Retimer           PMA               0             Local, Remote     prbs7-31, ssprq    |
|10          module-host              MODULE         PMA                0             Local, Remote     prbs7-31, ssprq    |
|11          module-line                MODULE         PMA               1             Local, Remote      prbs7-31, ssprq   |
+------------------------------------------------------------------------------------------------------------------------------------+

How does this deal with lanes or cases where you have multiple PHYs in
parallel such as the DSA setups?

The block ID would be used as the target identifier for --phy-test and
loopback set/get commands. Based on the block ID, the driver can identify
the corresponding functional block and perform the requested operation.

Host-side information can be populated by the driver based on
the hardware design. External PHY information can be obtained via phylink,
and module-related information can be retrieved over the I2C interface.

The updated proposal is provided below for review and comments.

...

+    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_nrz
+      - square_pam4 (JP03A - IEEE Std. 802.3-2022 94.2.9.1)
+      - tx_linearity (LIN - IEEE Std. 802.3-2022 94.2.9.4)
+      - scrambled_idle
+      - k28_5
+      - k28_7

These test patterns are going to be the biggest problem with this
approach. I almost wonder if we shouldn't look at having essentially 2
sets. One for the standard prbs values, and then one set of strings
that work sort of like the private flags where you can just specify
your own string to identify it and add it as a one-off until it can
become standardized.