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:   Thu, 19 Mar 2020 17:17:17 +0100
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
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

Hi Andrew,

Quoting Andrew Lunn (2020-03-19 17:05:05)
> 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;
> 
> Does this mean it is impossible to have a skew of 0ns?

It seems to be the case, the lowest value this register accepts is 0,
which means a 0.2ns delay, according to the datasheet. And I'm not
seeing any register disabling this when RGMII is used.

Thanks!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ