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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200319160505.GE27807@lunn.ch>
Date:   Thu, 19 Mar 2020 17:05:05 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Antoine Tenart <antoine.tenart@...tlin.com>
Cc:     davem@...emloft.net, f.fainelli@...il.com, hkallweit1@...il.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 2/2] net: phy: mscc: RGMII skew delay
 configuration

On Thu, Mar 19, 2020 at 03:19:58PM +0100, Antoine Tenart wrote:
> This patch adds support for configuring the RGMII skew delays in Rx and
> Tx. The Rx and Tx skews are set based on the interface mode. By default
> their configuration is set to the default value in hardware (0.2ns);
> this means the driver do not rely anymore on the bootloader
> configuration.
> 
> Then based on the interface mode being used, a 2ns delay is added:
> - RGMII_ID adds it for both Rx and Tx.
> - RGMII_RXID adds it for Rx.
> - RGMII_TXID adds it for Tx.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart@...tlin.com>
> ---
>  drivers/net/phy/mscc/mscc.h      | 14 ++++++++++++++
>  drivers/net/phy/mscc/mscc_main.c | 29 +++++++++++++++++++++++++++++
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/net/phy/mscc/mscc.h b/drivers/net/phy/mscc/mscc.h
> index d1b8bbe8acca..25729302714c 100644
> --- a/drivers/net/phy/mscc/mscc.h
> +++ b/drivers/net/phy/mscc/mscc.h
> @@ -161,6 +161,20 @@ enum rgmii_rx_clock_delay {
>  /* Extended Page 2 Registers */
>  #define MSCC_PHY_CU_PMD_TX_CNTL		  16
>  
> +#define MSCC_PHY_RGMII_SETTINGS		  18
> +#define RGMII_SKEW_RX_POS		  1
> +#define RGMII_SKEW_TX_POS		  4
> +
> +/* RGMII skew values, in ns */
> +#define VSC8584_RGMII_SKEW_0_2		  0
> +#define VSC8584_RGMII_SKEW_0_8		  1
> +#define VSC8584_RGMII_SKEW_1_1		  2
> +#define VSC8584_RGMII_SKEW_1_7		  3
> +#define VSC8584_RGMII_SKEW_2_0		  4
> +#define VSC8584_RGMII_SKEW_2_3		  5
> +#define VSC8584_RGMII_SKEW_2_6		  6
> +#define VSC8584_RGMII_SKEW_3_4		  7

  
> +static void vsc8584_rgmii_set_skews(struct phy_device *phydev)
> +{
> +	u32 skew_rx, skew_tx;
> +
> +	/* We first set the Rx and Tx skews to their default value in h/w
> +	 * (0.2 ns).
> +	 */
> +	skew_rx = VSC8584_RGMII_SKEW_0_2;
> +	skew_tx = VSC8584_RGMII_SKEW_0_2;

Hi Antoine

Does this mean it is impossible to have a skew of 0ns?

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ