linux-kernel - Re: [PATCH v6 net-next 09/14] net: phy: marvell-88q2xxx: add cable test support

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]

Date: Fri, 16 Feb 2024 00:43:28 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Dimitri Fedrau <dima.fedrau@...il.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Stefan Eichenberger <eichest@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 net-next 09/14] net: phy: marvell-88q2xxx: add cable
 test support

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