Received-SPF: pass (google.com: domain of linux-kernel+bounces-17868-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 5 Jan 2024 14:17:10 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: Jakub Kicinski <kuba@kernel.org>, davem@davemloft.net,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	thomas.petazzoni@bootlin.com, Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Herve Codina <herve.codina@bootlin.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	=?iso-8859-1?Q?K=F6ry?= Maincent <kory.maincent@bootlin.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Marek =?iso-8859-1?Q?Beh=FAn?= <kabel@kernel.org>,
	Piergiorgio Beruto <piergiorgio.beruto@gmail.com>,
	Oleksij Rempel <o.rempel@pengutronix.de>,
	=?iso-8859-1?Q?Nicol=F2?= Veronese <nicveronese@gmail.com>,
	Simon Horman <horms@kernel.org>
Subject: Re: [PATCH net-next v5 07/13] net: ethtool: Introduce a command to
 list PHYs on an interface
Message-ID: <2c955f94-7c95-4f66-b739-f0967ec9c171@lunn.ch>
References: <20231221180047.1924733-1-maxime.chevallier@bootlin.com>
 <20231221180047.1924733-8-maxime.chevallier@bootlin.com>
 <20240104153401.08ff9809@kernel.org>
 <20240105104311.03a35622@device-28.home>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240105104311.03a35622@device-28.home>

> > > +int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
> > > +{
> > > +	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
> > > +	struct net *net = sock_net(skb->sk);
> > > +	unsigned long ifindex = 1;  
> > 
> > This doesn't look right, if dump gets full you gotta pick up
> > when previous call left off.
> 
> I wasn't aware that this was the expected DUMP behaviour. So I should
> keep track of the last dev and last phy_index dumped in the dump_ctx I
> guess ? I'm not sure how I'm going to test this though, I only have
> devices with at most 2 PHYs :(

At a guess....

You are supposed to dump until you are out of space in the buffer. You
then return what you have, and expect another call so you can continue
with the rest.

Rather than fill the buffer, just hack the code to only put in a
single PHY, and then return with the same condition of a full
buffer. Hopefully you should get a second call, and you can then test
your logic for picking up from where you left off.

Another option might be to add PHY support to netdevsim. Add a debugfs
interface to allow you to create arbitrary PHY topologies? You can
then even add a test script.

     Andrew