[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fc65d6d1-6e59-47e1-8818-bc5279107549@lunn.ch>
Date: Mon, 27 Oct 2025 12:55:51 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sven Eckelmann <se@...onwunderlich.de>
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>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
sw@...onwunderlich.de, Issam Hamdi <ih@...onwunderlich.de>
Subject: Re: [PATCH] net: phy: realtek: Add RTL8224 cable testing support
On Mon, Oct 27, 2025 at 08:49:36AM +0100, Sven Eckelmann wrote:
> On Monday, 27 October 2025 01:16:12 CET Andrew Lunn wrote:
> > > +#define RTL8224_SRAM_RTCT_FAULT_BUSY BIT(0)
> > > +#define RTL8224_SRAM_RTCT_FAULT_OPEN BIT(3)
> > > +#define RTL8224_SRAM_RTCT_FAULT_SAME_SHORT BIT(4)
> > > +#define RTL8224_SRAM_RTCT_FAULT_OK BIT(5)
> > > +#define RTL8224_SRAM_RTCT_FAULT_DONE BIT(6)
> > > +#define RTL8224_SRAM_RTCT_FAULT_CROSS_SHORT BIT(7)
> >
> > It is unusual these are bits. Does the datasheet say what happens if
> > the cable is both same short and cross short?
>
> Unfortunately, the datasheet doesn't say anything about cable tests.
>
> >
> > > +static int rtl8224_cable_test_result_trans(u32 result)
> > > +{
> > > + if (result & RTL8224_SRAM_RTCT_FAULT_SAME_SHORT)
> > > + return ETHTOOL_A_CABLE_RESULT_CODE_SAME_SHORT;
> > > +
> > > + if (result & RTL8224_SRAM_RTCT_FAULT_BUSY)
> > > + return ETHTOOL_A_CABLE_RESULT_CODE_UNSPEC;
> > > +
> > > + if (result & RTL8224_SRAM_RTCT_FAULT_CROSS_SHORT)
> > > + return ETHTOOL_A_CABLE_RESULT_CODE_CROSS_SHORT;
> >
> > I don't remember seeing a PHY able to report both same short and cross
> > short at the same time. Maybe there has been, but there is no code for
> > it. We could add such a code.
>
> I've tried it a couple of times (with shorts at different lengths) but was not
> able to do this. For me, it looks like the RTL8224 can represent these faults
> in parallel but not actual detect them in parallel.
O.K. Thanks for the explanation. The code is good as it is.
Reviewed-by: Andrew Lunn <andrew@...n.ch>
Andrew
Powered by blists - more mailing lists