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: <4a48d205-5026-4ec9-aa8b-bc1459641d33@lunn.ch>
Date: Fri, 7 Mar 2025 17:27:58 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Gerhard Engleder <gerhard@...leder-embedded.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, 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 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.

	Andrew