Message-ID: <52e1917a-2030-4019-bb9f-a836dc47bda9@trager.us>
Date: Thu, 13 Nov 2025 16:07:05 -0800
From: Lee Trager <lee@...ger.us>
To: Andrew Lunn <andrew@...n.ch>,
 Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Susheela Doddagoudar <susheelavin@...il.com>, netdev@...r.kernel.org,
 mkubecek@...e.cz, Hariprasad Kelam <hkelam@...vell.com>,
 Alexander Duyck <alexanderduyck@...com>
Subject: Re: Ethtool: advance phy debug support

On 11/13/25 5:28 AM, Andrew Lunn wrote:

> On Thu, Nov 13, 2025 at 12:11:08PM +0100, Maxime Chevallier wrote:
>> Hi,
>>
>> On 13/11/2025 06:12, Susheela Doddagoudar wrote:
>>> Hi All/ Michal Kubecek,
>>>
>>> To support Advanced PHY Debug operations like
>>> PRBS pattern tests,  EHM tests, TX_EQ settings, Various PHY loopback etc.....
>> Added a bunch of people in CC:
>>
>> I don't have feedback on your current proposition, however people have
>> showed interest in what you mention, it may be a good idea to get everyone
>> in the loop.
>>
>> For the Loopback you're mentionning, there's this effort here [1] that
>> Hariprasad is working on, it may be a good idea to sync the effort :)
>>
>> [1] : https://lore.kernel.org/netdev/20251024044849.1098222-1-hkelam@marvell.com/
>>
>> As for the PRBS, there was a discussion on this at the last Netdevconf,
>> see the slides and talk here [2], I've added Lee in CC but I don't
>> really know what's the state of that work.
>>
>> [2] : https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html

I have PRBS testing and configuring TX coefficent support working in an 
internal version of the fbnic driver. The problem is the interface. 
Right now I'm using DebugFS, my understanding is write access in DebugFS 
is frowned upon which is why it hasn't been up streamed yet. My original 
idea was to extend ethtool, similar to what Susheela suggested, to add 
support but I got some push back on that at netdev. I received the 
suggestion that this is really something that should be part of the phy 
subsystem which would require a new tool to be written.

Alex had started to onboard fbnic to phy as part of his work to onboard 
fbnic to phylink. My understanding is that Alex was recently asked to 
not use the phy subsystem. So the question is where does this go? What 
user space tool interacts with the API?

> For PRBS pattern tests testing i think there needs to be a framework
> around it.
>
> When you enable testing, the netif becomes usable, so its state needs
> changing to "under test" as defined in RFC2863. We ideally want it
> revert to normal operation after a time period. There are a number of
> different PRBS patterns, so you need to be able to select one, and
> maybe pass the test duration. It can also be performed in different
> places. 802.3 defines a number of registers in the PCS for this. I
> would expect to see a library that any standards conforming PCS can
> use. There are also PHYs which support this features, but each vendor
> implements it differently, so we need some sort of generic API for
> PHYs. I expect we will also end up with a set of netlink message,
> similar to how cable testing working.

Nothing can touch the comphy while PRBS testing is running. The fbnic 
driver rejects starting testing if the link is up. Once testing has 
begun I actually detach the netdev to prevent the link from coming up. 
To help enforce this I added a test mode to firmware to ensure both 
driver and firmware are hands off the comphy while testing is running.

When I spoke with test engineers internally in Meta I could not come up 
with a time period and over night testing came up as a requirement. I 
decided to just let the user start and stop testing with no time 
requirement. If firmware loses the host heartbeat it automatically 
disables PRBS testing.

fbnic controls the comphy in firmware due to limitations in 4 slice 
mode. Even if it didn't the controls are non-standard.

Lee

Powered by blists - more mailing lists