[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1229fd9-2f65-40dd-bbb5-9f0f3e3b2c2c@lunn.ch>
Date: Wed, 12 Feb 2025 21:46:28 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Gerhard Engleder <gerhard@...leder-embedded.com>
Cc: hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org, Oleksij Rempel <o.rempel@...gutronix.de>
Subject: Re: [PATCH net-next v6 6/7] net: selftests: Export
net_test_phy_loopback_*
> Reusing the complete test set as extension is not feasible as the first
> test requires an existing link and for loopback test no link is
> necessary. But yes, I can do better and rework it to reusable tests.
> I'm not sure if I will use ethtool_test_flags as IMO ideally all tests
> run always to ensure easy use.
We try to ensure backwards/forwards compatibly between ethtool and the
kernel.
The point about ethtool_test_flags is that for older versions of
ethtool, you have no idea what the reserved field contains. Has it
always been set to zero? If there is a flag indicating reserved
contains a value, you then know it is safe to use it.
At some point, the API needs moving to netlink sockets. It then
becomes a lot easier to add extra parameters, as attributes.
There is also an interesting overlap here and:
https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html
What you are doing is not too dissimilar, although the PRBS is an
802.3 standard concept and typically part of the PCS. There needs to
be some sort of API for configuring the PRBS, maybe as part of ethtool
self tests? If so, the API is going to need extensions.
Andrew
Powered by blists - more mailing lists