Message-ID: <399ca61a-abf0-4b37-af32-018a9ef08312@trager.us>
Date: Sat, 15 Nov 2025 14:38:50 -0800
From: Lee Trager <lee@...ger.us>
To: Andrew Lunn <andrew@...n.ch>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
 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/14/25 5:58 AM, Andrew Lunn wrote:

>> 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 would say ethtool is the correct API to use. At minimum it needs to
> be netlink.
>
>> 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.
> phylib uses netlink/ethtool, e.g. cable test is purely in phylib, and
> it uses ethtool. ethtool also has --set-phy-tunable, --get-phy-tunable,
> --phy-statistics, etc.
>
> Also, PRBS is not just a PHY thing, 802.3 defines it as part of the
> PCS, and i don't see why a MAC could also implement it, not that i
> have seen such a thing.
>
> And maybe other networking technologies also have something like PRBS?
> Is there an 802.11 equivalent, used for testing the analogue front
> end? CAN?
PRBS testing can be used as a signal integrity test between any two end 
points, not just networking. For example we have CSRs to allow PRBS 
testing on PCIE with fbnic. My thought was always to limit the scope to 
network use case. The feedback I received at Netdev was we need to 
handle this generically for any phy, thus the suggestion to do this on 
phy. That adds a ton of complexity so I'd be supportive to narrow this 
down to just networking and leverage ethtool.
>
>> 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?
> Linux's understanding of a PHY is a device which takes the bitstream
> from the MAC and turns it into analogue signals on twisted pairs,
> mostly for an RJ45 connector, but automotive uses other
> connectors. Its copper, and 802.3 C22 and parts of C45 define how such
> a PHY should work. There is a second use case, where a PHY converts
> between say RGMII and SGMII, but it basically uses the same registers.
>
> fbnic is not copper. It has an SFP cage. Linux has a different
> architecture for that, MAC, PCS and SFP driver. Alex abused the design
> and put a PHY into it as a shortcut. It not surprising there was push
> back.
>
> So, i still think ethtool is the correct API. In general, that
> connects to the MAC driver, although it can shortcut to a PHY
> connected to a MAC. But such a short cut has caused issues in the
> past. So i would probably not do that. Add an API to phylink, which
> the MAC can use. And an API to the PCS driver, which phylink can
> use. And for when the PHY implements PRBS, add an API to phylib and
> get phylib to call the PHY driver.
>
> I'm not saying you need to implement all that, just the bits you need
> for a PCS packet generator. But lay out the architecture such that it
> can be extended with packet generators in other places.
I'll sync with Alex on Monday about this since he is leading the phylink 
work.
>   
>>> 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.
> That actually seems odd to me. I assume you need to set the link mode
> you want. Having it default to 10/Half is probably not what you
> want. You want to use ethtool_ksettings_set to force the MAC and PCS
> into a specific link mode. Most MAC drivers don't do anything if that
> call is made when the interface is admin down. And if you look at how
> most MAC drivers are structured, they don't bind to phylink/phylib
> until open() is called. So when admin down, you don't even have a
> PCS/PHY. And some designs have multiple PCSes, and you select the one
> you need based on the link mode, set by ethtool_ksettings_set or
> autoneg. And if admin down, the phylink will turn the SFP laser off.

fbnic does not currently support autoneg, we know the settings that will 
be used for prod. At manufacturing time the EEPROM is configured with 
the expected lanes and mode(NRZ/PAM4). Firmware sends these settings to 
the driver which are stored in fbn->aui. ethtool -s  can change these 
settings when PRBS testing isn't running. Before starting testing I call 
fbnic_fw_xmit_comphy_set_msg() with those cached settings so we can test 
any configuration.

We could use the same pattern, user configures the device with ethtool 
-s before running ethtool --prbs. Devices which want to support PRBS 
will need to cache settings similar to fbnic.

>
>> 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.
> O.K. So i would probably go for a blocking netlink call, and when ^C
> is used, to exits PRBS and allows normal traffic. You then need to
> think about RTNL, which you cannot hold for hours.
RTNL() is only held when starting testing, its released once testing has 
begun. We could set a flag on the netdev to say PRBS testing is running, 
don't do anything else with this device until the flag is reset.
>
> 	Andrew

Powered by blists - more mailing lists