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