[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d98db01-e949-4dd7-8724-3efcc2e319d9@lunn.ch>
Date: Tue, 4 Mar 2025 14:20:02 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Gerhard Engleder <gerhard@...leder-embedded.com>, hkallweit1@...il.com,
linux@...linux.org.uk, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, netdev@...r.kernel.org, ltrager@...a.com,
Jijie Shao <shaojijie@...wei.com>
Subject: Re: [PATCH net-next v9 2/8] net: phy: Support speed selection for
PHY loopback
On Mon, Mar 03, 2025 at 05:35:00PM -0800, Jakub Kicinski wrote:
> On Thu, 27 Feb 2025 21:31:32 +0100 Gerhard Engleder wrote:
> > phy_loopback() leaves it to the PHY driver to select the speed of the
> > loopback mode. Thus, the speed of the loopback mode depends on the PHY
> > driver in use.
> >
> > Add support for speed selection to phy_loopback() to enable loopback
> > with defined speeds. Ensure that link up is signaled if speed changes
> > as speed is not allowed to change during link up. Link down and up is
> > necessary for a new speed.
>
> Hi Andrew, does this one look good to you? I see your review tags
> on other patches :)
Sorry, dropped the ball on this patchset.
I actually think there needs to be a step back and look at the
requirements and what others are doing in the area.
Jijie Shao is doing similar things:
https://lore.kernel.org/lkml/20250213035529.2402283-3-shaojijie@huawei.com/
Both run into the same limitations of the current code, being able to
compose tests from what we currently have.
And then there is what Lee Trager is doing:
https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html
There is some overlap with the work Lee is doing, i assume he will
need to configure the link mode the PCS is using, which is the
scalability issue you raised with previous versions of this patchset.
And configuring the PRBS in the PCS is not so different to configuring
the packet generators we have in net/core/selftest.c.
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?
Andrew
Powered by blists - more mailing lists