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: <0034e97b-db94-48f9-9a89-838f1ea4e479@engleder-embedded.com>
Date: Tue, 11 Mar 2025 06:39:17 +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 20:15, Gerhard Engleder wrote:
> 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.

Is it ok for you the put the phy_loopback() extension with loopback fix
for the tsnep driver to a separate patch set?

Gerhard