Received-SPF: pass (google.com: domain of linux-kernel+bounces-67845-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 16 Feb 2024 00:43:28 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Dimitri Fedrau <dima.fedrau@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Stefan Eichenberger <eichest@gmail.com>, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 net-next 09/14] net: phy: marvell-88q2xxx: add cable
 test support
Message-ID: <ecfac8c1-de0d-4ccc-ad24-5e62b3d1bf5a@lunn.ch>
References: <20240213213955.178762-1-dima.fedrau@gmail.com>
 <20240213213955.178762-10-dima.fedrau@gmail.com>
 <fe604759-d1cd-4a4d-ba64-69936b3e6598@lunn.ch>
 <20240215210350.GB3103@debian>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240215210350.GB3103@debian>

On Thu, Feb 15, 2024 at 10:03:50PM +0100, Dimitri Fedrau wrote:
> Am Wed, Feb 14, 2024 at 06:54:58PM +0100 schrieb Andrew Lunn:
> > > +static int mv88q222x_cable_test_get_status(struct phy_device *phydev,
> > > +					   bool *finished)
> > > +{
> > > +	int ret;
> > > +	u32 dist;
> > > +
> > > +	ret = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_MMD_PCS_MV_TDR_STATUS);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +
> > > +	*finished = true;
> > 
> > That looks odd. Is there no status bit which says it has completed? Is
> > it guaranteed to complete within a fixed time? How is it guaranteed that
> > mv88q222x_cable_test_get_status() is called at the necessary delay after 
> > mv88q222x_cable_test_start()?
> > 
> According to the datasheet and the Marvell API bits(0:1) can be used to
> check if the test has completed. Sample code waits 500ms before checking
> the bits. If the test is not completed after the delay the corresponding
> function returns with an error.

Thanks for the explanation.

> 
> I just used bits(7:4) where 2'b1000 means that the test is in progress,
> and setting *finished = false. I didn't introduced any delay, relying
> on the reschedule delay of the PHY state machine. I didn't notice any
> problems with this approach. Anyway if the test does not complete for
> whatever reasons we get stuck here, right ?

It should not happen, and if it does, its a bug in the PHY
firmware. And if that happens, the PHY is probably dead anyway.

phylib does allow you to break out of the cable test state by calling
phy_stop(). That generally happens when you admin down the interface.

So please do check the test has completed.

	Andrew