netdev - Re: [PATCH net-next v9 2/8] net: phy: Support speed selection for PHY loopback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d56eaf3-4d8c-40da-8a10-a287f09553e6@engleder-embedded.com>
Date: Tue, 4 Mar 2025 21:00:30 +0100
From: Gerhard Engleder <gerhard@...leder-embedded.com>
To: Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
 Jijie Shao <shaojijie@...wei.com>
Cc: hkallweit1@...il.com, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, netdev@...r.kernel.org, ltrager@...a.com,
 linux@...linux.org.uk
Subject: Re: [PATCH net-next v9 2/8] net: phy: Support speed selection for PHY
 loopback

On 04.03.25 17:15, Jakub Kicinski wrote:
> On Tue, 4 Mar 2025 14:20:02 +0100 Andrew Lunn wrote:
>> The current IOCTL interface is definitely too limiting for what Lee
>> will need. So there is a netlink API coming soon. Should Gerhard and
>> Jijie try to shoehorn what they want into the current IOCTL handler,
>> or help design the netlink API? How can selftest.c be taken apart and
>> put back together to make it more useful? And should the high level
>> API for PRBS be exported through it, making it easier to use for any
>> netdev?
> 
> As we think about this let's keep in mind that selftests are generic,
> not PHY-centric. Even if we can pass all link settings in there are
> other innumerable params people may want in the future.

My patchset can be divided into two parts:
1) Extend phy_loopback() to select a defined speed
2) Extend tsnep selftests to get some in-kernel test coverage for the
    phy_loopback() extension

This discussion is related to the selftest rework of the second part.
Would it be ok to put the first part into a separate patchset, as this
changes make sense and work even without the selftests?

For the selftests IMO Jijie Shao and me should try to extend
net/core/selftests in a generic way for both drivers. There shall not be
multiple "send, receive and check skb" implementations in various
drivers. Andrew suggested to make the selftests generic enough to let
others benefit. To prove that, Jijie Shao needs to be able to use the
new selftest sets.

For me it is ok to keep back these selftests until a new netlink API is
available. I feel not comfortable to design a new netlink API as I have
no need to make the selftests configurable by user space like Lee
Trager.

So what to do with these selftests?
Hold back until new netlink API?
Rework them to only support the "send, receive and check skb" case
without any PHY stuff and use it in tsnep and hibmcge?
Keep them as they are as new test sets and parameters can be added
in the future if needed?

Gerhard