linux-kernel - Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes

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: <20190215171224.sjfrid5csseywuks@shell.armlinux.org.uk>
Date:   Fri, 15 Feb 2019 17:12:24 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Antoine Tenart <antoine.tenart@...tlin.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
        maxime.chevallier@...tlin.com, gregory.clement@...tlin.com,
        miquel.raynal@...tlin.com, nadavh@...vell.com, stefanc@...vell.com,
        ymarkman@...vell.com, mw@...ihalf.com
Subject: Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while
 reconfiguring the serdes lanes

On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> The documentation advises to set the XPCS in reset while reconfiguring
> the serdes lanes. This seems to be a good thing to do, but the PPv2
> driver wasn't doing it. This patch fixes it.

Hmm.  That statment seems to have some ambiguity in it - we do two
"reconfigurations" - one may be upon initialisation, where the lane
is already configured for 10Gbase-KR, and we're re-initialising it
for the same mode.  The other case is when we're switching between
10Gbase-KR and SGMII, or as will be the case with 2.5G support for
the Alaska PHYs, 2500base-X.

Does this apply to reconfiguration of the serdes lane between
10Gbase-KR and slower modes?

> 
> Signed-off-by: Antoine Tenart <antoine.tenart@...tlin.com>
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h      | 1 +
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 8 +++++++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 21ddcac1ceea..7380bddc53b8 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -481,6 +481,7 @@
>  /* XPCS registers. PPv2.2 only */
>  #define MVPP22_XPCS_BASE(port)			(0x7400 + (port) * 0x1000)
>  #define MVPP22_XPCS_CFG0			0x0
> +#define     MVPP22_XPCS_CFG0_RESET_DIS		BIT(0)
>  #define     MVPP22_XPCS_CFG0_PCS_MODE(n)	((n) << 3)
>  #define     MVPP22_XPCS_CFG0_ACTIVE_LANE(n)	((n) << 5)
>  
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 4a18f8e54c90..5d05306e79a8 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -1016,13 +1016,19 @@ static void mvpp22_gop_init_10gkr(struct mvpp2_port *port)
>  	void __iomem *xpcs = priv->iface_base + MVPP22_XPCS_BASE(port->gop_id);
>  	u32 val;
>  
> -	/* XPCS */
> +	/* XPCS : Reset the XPCS when reconfiguring the lanes */
> +	val = readl(xpcs + MVPP22_XPCS_CFG0);
> +	writel(val & ~MVPP22_XPCS_CFG0_RESET_DIS, xpcs + MVPP22_XPCS_CFG0);
> +
>  	val = readl(xpcs + MVPP22_XPCS_CFG0);
>  	val &= ~(MVPP22_XPCS_CFG0_PCS_MODE(0x3) |
>  		 MVPP22_XPCS_CFG0_ACTIVE_LANE(0x3));
>  	val |= MVPP22_XPCS_CFG0_ACTIVE_LANE(2);
>  	writel(val, xpcs + MVPP22_XPCS_CFG0);
>  
> +	val = readl(xpcs + MVPP22_XPCS_CFG0);
> +	writel(val | MVPP22_XPCS_CFG0_RESET_DIS, xpcs + MVPP22_XPCS_CFG0);
> +
>  	/* MPCS */
>  	val = readl(mpcs + MVPP22_MPCS_CTRL);
>  	val &= ~MVPP22_MPCS_CTRL_FWD_ERR_CONN;
> -- 
> 2.20.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up