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] [day] [month] [year] [list]

Message-ID: <3c9efd22-03b3-4368-b3c2-cdf349032832@engleder-embedded.com>
Date: Fri, 7 Mar 2025 20:15:49 +0100
From: Gerhard Engleder <gerhard@...leder-embedded.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: hkallweit1@...il.com, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, netdev@...r.kernel.org, ltrager@...a.com,
 linux@...linux.org.uk, Jakub Kicinski <kuba@...nel.org>,
 Jijie Shao <shaojijie@...wei.com>
Subject: Re: [PATCH net-next v9 2/8] net: phy: Support speed selection for PHY
 loopback

On 07.03.25 17:27, Andrew Lunn wrote:
> On Thu, Mar 06, 2025 at 06:58:20AM +0100, Gerhard Engleder wrote:
>> On 04.03.25 21:00, Gerhard Engleder wrote:
>>> 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?
>>
>> Andrew, is it ok to put phy_loopback() extension to a separate patch
>> set?
> 
> Without the selftest part, the phy loopback changes go unused. We
> don't normally add APIs without a user. So i would say no, it should
> be all or nothing. I don't think it will cause many problems if these
> patches need to wait a while, a rebase should be easy, this area of
> phylib is pretty stable.

Why no user? The tsnep driver is the user to get loopback again working
after 6ff3cddc365b ("net: phylib: do not disable autoneg for fixed
speeds >= 1G"). The phy_loopback changes are used by
tsnep_phy_loopback().

Thanks to your comments it is also an improvement of the loopback
behavior, as now loopback signals the new speed like a normal link up.

Gerhard