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: <a14ae101-d492-45a0-90fe-683e2f43fa3e@lunn.ch>
Date: Mon, 8 Jul 2024 18:44:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 1/1] net: phy: dp83td510: add cable testing
 support

On Mon, Jul 08, 2024 at 04:05:42PM +0200, Oleksij Rempel wrote:
> Implement the TDR test procedure as described in "Application Note
> DP83TD510E Cable Diagnostics Toolkit revC", section 3.2.
> 
> The procedure was tested with "draka 08 signalkabel 2x0.8mm". The reported
> cable length was 5 meters more for each 20 meters of actual cable length.
> For instance, a 20-meter cable showed as 25 meters, and a 40-meter cable
> showed as 50 meters. Since other parts of the diagnostics provided by this
> PHY (e.g., Active Link Cable Diagnostics) require accurate cable
> characterization to provide proper results, this tuning can be implemented
> in a separate patch/interface.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> ---
>  drivers/net/phy/dp83td510.c | 158 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 158 insertions(+)
> 
> diff --git a/drivers/net/phy/dp83td510.c b/drivers/net/phy/dp83td510.c
> index d7616b13c5946..3375fa82927d0 100644
> --- a/drivers/net/phy/dp83td510.c
> +++ b/drivers/net/phy/dp83td510.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <linux/bitfield.h>
> +#include <linux/ethtool_netlink.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/phy.h>
> @@ -29,6 +30,42 @@
>  #define DP83TD510E_INT1_LINK			BIT(13)
>  #define DP83TD510E_INT1_LINK_EN			BIT(5)
>  
> +#define DP83TD510E_TDR_CFG			0x1e
> +#define DP83TD510E_TDR_START			BIT(15)
> +#define DP83TD510E_TDR_DONE			BIT(1)
> +#define DP83TD510E_TDR_FAIL			BIT(0)
> +
> +#define DP83TD510E_CTRL				0x1f
> +#define DP83TD510E_CTRL_HW_RESET		BIT(15)
> +#define DP83TD510E_CTRL_SW_RESET		BIT(14)
> +
> +#define DP83TD510E_TDR_CFG1			0x300

> +/* TX_TYPE: Transmit voltage level for TDR. 0 = 1V, 1 = 2.4V */
> +#define DP83TD510E_TDR_TX_TYPE			BIT(12)

This does not appear to be used, so it is not too important. But i
generally encode this as

#define DP83TD510E_TDR_TX_TYPE_1V		(0 << 12)
#define DP83TD510E_TDR_TX_TYPE_2V4		(1 << 12)

You can then OR in DP83TD510E_TDR_TX_TYPE_1V which does nothing, but
does document you are using 1V for the test.

> +#define DP83TD510E_TDR_CFG2			0x301
> +#define DP83TD510E_TDR_END_TAP_INDEX_1		GENMASK(14, 8)
> +#define DP83TD510E_TDR_END_TAP_INDEX_1_DEF	36
> +#define DP83TD510E_TDR_START_TAP_INDEX_1	GENMASK(6, 0)
> +#define DP83TD510E_TDR_START_TAP_INDEX_1_DEF	3

Does this correspond the minimum and maximum distance it will test?
Is this 3m to 36m?

   Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ