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 <redacted>; Alexander H Duyck
[off-list ref]; lee@trager.us; netdev@vger.kernel.org;
mkubecek@suse.cz; D H, Siddaraju [off-list ref]; Chintalapalle,
Balaji [off-list ref]; Lindberg, Magnus
[off-list ref]; niklas.damberg@ericsson.com
Subject: Re: Ethtool : PRBS feature

On Sat, Jun 20, 2026 at 04:39:06PM +0200, Maxime Chevallier wrote:

quoted

Hi,

On 6/20/26 15:48, Das, Shubham wrote:

quoted

quoted

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

quoted

quoted

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.

quoted

quoted

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?

quoted

quoted

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