netdev - Re: [PATCH] net: phy: realtek: Add RTL8224 cable testing 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]

Message-ID: <8597775.T7Z3S40VBb@ripper>
Date: Mon, 27 Oct 2025 08:49:36 +0100
From: Sven Eckelmann <se@...onwunderlich.de>
To: Andrew Lunn <andrew@...n.ch>
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 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. I also played around with
open + shorts. At the end, I never saw any parallel detections and left it to 
the bit prioritization (during decoding) from RTLSDK.

RTL8226 in RTLSDK doesn't use (in contrast to RTL8224 in RTLSDK) the bits - 
but there seems to be at least some connections. The codes for RTL8226 
(according to RTLSDK) are:

* 0x60 RTL8226_SRAM_RTCT_FAULT_OK (would be RTL8224 OK+DONE)
* 0x48 RTL8226_SRAM_RTCT_FAULT_OPEN (would be RTL8224 OPEN+DONE)
* 0x50 RTL8226_SRAM_RTCT_FAULT_SHORT (would be RTL8224 SAME_SHORT + DONE)
* 0x42 RTL8226_SRAM_RTCT_FAULT_MISMATCH_OPEN (would be RTL8224 DONE + ????)
* 0x44 RTL8226_SRAM_RTCT_FAULT_MISMATCH_SHORT (would be RTL8224 DONE + ????)
* else: RTL8226_SRAM_RTCT_FAULT_UNKNOWN

It seems like these decoding would not even have cross shorts. Don't ask me 
what this mismatch is - couldn't find anything like this in RTL8224. The bits 
1 + 2 are completely unused there.

Regards,
	Sven
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)