[PATCH net-next 00/13] net: mvpp2: various fixes

[PATCH net-next 00/13] net: mvpp2: various fixes

[Antoine Tenart]

Hi all,

This series contains various fixes on bugs reported to us, or bugs I
stumbled upon while testing the various interface configurations I have
access to.

While this series contain fixes, it's sent to net-next as it is based
on top of Russell's rework and fixes he sent during the last 2 weeks
(such as his PPv2 phylink rework) that were applied to net-next. It'll
also allow the users to have more time to test those changes.

Thanks!
Antoine

Antoine Tenart (13):
  net: mvpp2: do not call phylink_mac_change if there is no event
  net: mvpp2: a port can be disabled even if we use the link IRQ
  net: mvpp2: do not disable the port if the mode hasn't changed
  net: mvpp2: reconfiguring the port interface is PPv2.2 specific
  net: mvpp2: do not set the XLG MAC in reset when disabling a port
  net: mvpp2: fix a typo in the header
  net: mvpp2: fix validate for PPv2.1
  net: mvpp2: fix the computation of the RXQs
  net: mvpp2: update the port documentation regarding the GoP
  net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
  net: mvpp2: reset the XLG MAC in port_reset
  net: mvpp2: fix alignment of MVPP2_GMAC_CONFIG_MII_SPEED definition
  net: mvpp2: some AN fields require the link to be down when updated

 drivers/net/ethernet/marvell/mvpp2/mvpp2.h    |  9 +-
 .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 98 ++++++++++++-------
 2 files changed, 66 insertions(+), 41 deletions(-)

-- 
2.20.1

[PATCH net-next 01/13] net: mvpp2: do not call phylink_mac_change if there is no event

[Antoine Tenart]

This patch makes the link interrupt handler to avoid calling
phylink_mac_change when there are no event.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index b42189260670..857b079f1a29 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -2477,14 +2477,14 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
 		}
 	}
 
+	if (!netif_running(dev) || !event)
+		goto handled;
+
 	if (port->phylink) {
 		phylink_mac_change(port->phylink, link);
 		goto handled;
 	}
 
-	if (!netif_running(dev) || !event)
-		goto handled;
-
 	if (link) {
 		mvpp2_interrupts_enable(port);
 
-- 
2.20.1

Re: [PATCH net-next 01/13] net: mvpp2: do not call phylink_mac_change if there is no event

[Russell King - ARM Linux admin]

On Fri, Feb 15, 2019 at 04:32:29PM +0100, Antoine Tenart wrote:
> This patch makes the link interrupt handler to avoid calling
> phylink_mac_change when there are no event.

The reasoning being?

> 
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index b42189260670..857b079f1a29 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -2477,14 +2477,14 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
>  		}
>  	}
>  
> +	if (!netif_running(dev) || !event)
> +		goto handled;
> +
>  	if (port->phylink) {
>  		phylink_mac_change(port->phylink, link);
>  		goto handled;
>  	}
>  
> -	if (!netif_running(dev) || !event)
> -		goto handled;
> -
>  	if (link) {
>  		mvpp2_interrupts_enable(port);
>  
> -- 
> 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

Re: [PATCH net-next 01/13] net: mvpp2: do not call phylink_mac_change if there is no event

[Antoine Tenart]

Hi Russell,

On Fri, Feb 15, 2019 at 05:05:53PM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Feb 15, 2019 at 04:32:29PM +0100, Antoine Tenart wrote:
> > This patch makes the link interrupt handler to avoid calling
> > phylink_mac_change when there are no event.
> 
> The reasoning being?

The interrupt can fire for a number of reasons, some of which may not be
related to changes in the MAC state (it can fire upon errors or counter
wraparound).

This interrupt handler currently checks if an event occurred bu checking
if the cause of the interrupt is a link change. I wanted to extend this
logic to phylink to avoid having two link change handlers (phylink and
!phylink) being called in different ways.

Anyway, the only cause unmask so far is the link one, so it won't make
any difference so far. We can probably drop this one for now.

Antoine

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

[PATCH net-next 02/13] net: mvpp2: a port can be disabled even if we use the link IRQ

[Antoine Tenart]

We had a check in the mvpp2_mac_link_down() function (called by phylink)
to avoid disabling the port when link interrupts are used. It turned out
the interrupt can still be used with the port disabled. We can thus
remove this check.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 857b079f1a29..8faa842dc17c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4738,13 +4738,6 @@ static void mvpp2_mac_link_down(struct net_device *dev, unsigned int mode,
 	mvpp2_egress_disable(port);
 	mvpp2_ingress_disable(port);
 
-	/* When using link interrupts to notify phylink of a MAC state change,
-	 * we do not want the port to be disabled (we want to receive further
-	 * interrupts, to be notified when the port will have a link later).
-	 */
-	if (!port->has_phy)
-		return;
-
 	mvpp2_port_disable(port);
 }
 
-- 
2.20.1

[PATCH net-next 03/13] net: mvpp2: do not disable the port if the mode hasn't changed

[Antoine Tenart]

The Marvell PPv2 implementation of the Phylink mac_config helper
disables and enables the port, as the link mode can trigger
reconfiguration of the serdes lanes. This patch helps not disabling the
port every time mac_config is called but only when needed, which is an
improvement as the Phylink state machine does call the function every
second.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 8faa842dc17c..d5a103dd1610 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4670,9 +4670,10 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
 		return;
 	}
 
-	/* Make sure the port is disabled when reconfiguring the mode */
-	mvpp2_port_disable(port);
 	if (change_interface) {
+		/* Make sure the port is disabled when reconfiguring the mode */
+		mvpp2_port_disable(port);
+
 		mvpp22_gop_mask_irq(port);
 
 		if (port->priv->hw_version == MVPP22) {
@@ -4682,6 +4683,8 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
 			phy_power_off(port->comphy);
 			mvpp22_mode_reconfigure(port);
 		}
+
+		mvpp2_port_enable(port);
 	}
 
 	/* mac (re)configuration */
@@ -4697,8 +4700,6 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
 
 	if (change_interface)
 		mvpp22_gop_unmask_irq(port);
-
-	mvpp2_port_enable(port);
 }
 
 static void mvpp2_mac_link_up(struct net_device *dev, unsigned int mode,
-- 
2.20.1

[PATCH net-next 04/13] net: mvpp2: reconfiguring the port interface is PPv2.2 specific

[Antoine Tenart]

This patch adds a check not to disable/enable a port when an interface
is updated when using PPv2.1 as the functions called are PPv2.2
specific.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d5a103dd1610..c8bab294f4c7 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4670,19 +4670,17 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
 		return;
 	}
 
-	if (change_interface) {
+	if (port->priv->hw_version == MVPP22 && change_interface) {
 		/* Make sure the port is disabled when reconfiguring the mode */
 		mvpp2_port_disable(port);
 
 		mvpp22_gop_mask_irq(port);
 
-		if (port->priv->hw_version == MVPP22) {
-			port->phy_interface = state->interface;
+		port->phy_interface = state->interface;
 
-			/* Reconfigure the serdes lanes */
-			phy_power_off(port->comphy);
-			mvpp22_mode_reconfigure(port);
-		}
+		/* Reconfigure the serdes lanes */
+		phy_power_off(port->comphy);
+		mvpp22_mode_reconfigure(port);
 
 		mvpp2_port_enable(port);
 	}
@@ -4698,7 +4696,7 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
 	if (port->priv->hw_version == MVPP21 && port->flags & MVPP2_F_LOOPBACK)
 		mvpp2_port_loopback_set(port, state);
 
-	if (change_interface)
+	if (port->priv->hw_version == MVPP22 && change_interface)
 		mvpp22_gop_unmask_irq(port);
 }
 
-- 
2.20.1

[PATCH net-next 05/13] net: mvpp2: do not set the XLG MAC in reset when disabling a port

[Antoine Tenart]

This patch prevents the PPv2 driver to put the XPCS in reset while
disabling a port. A port and the XPCS are two different blocks, and a
port can be used without the XPCS. Their configuration should be done
separately, which is already the case in the driver except for this one
example.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index c8bab294f4c7..2c1de23ca267 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1210,10 +1210,6 @@ static void mvpp2_port_disable(struct mvpp2_port *port)
 		val = readl(port->base + MVPP22_XLG_CTRL0_REG);
 		val &= ~MVPP22_XLG_CTRL0_PORT_EN;
 		writel(val, port->base + MVPP22_XLG_CTRL0_REG);
-
-		/* Disable & reset should be done separately */
-		val &= ~MVPP22_XLG_CTRL0_MAC_RESET_DIS;
-		writel(val, port->base + MVPP22_XLG_CTRL0_REG);
 	} else {
 		val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
 		val &= ~(MVPP2_GMAC_PORT_EN_MASK);
-- 
2.20.1

[PATCH net-next 06/13] net: mvpp2: fix a typo in the header

[Antoine Tenart]

This cosmetic patch fixes a typo made in a comment in the Marvell PPv2
Ethernet driver header.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 96e3f0669032..83fb2b03e789 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -549,7 +549,7 @@
 #define MVPP2_MAX_TSO_SEGS		300
 #define MVPP2_MAX_SKB_DESCS		(MVPP2_MAX_TSO_SEGS * 2 + MAX_SKB_FRAGS)
 
-/* Dfault number of RXQs in use */
+/* Default number of RXQs in use */
 #define MVPP2_DEFAULT_RXQ		1
 
 /* Max number of Rx descriptors */
-- 
2.20.1

[PATCH net-next 07/13] net: mvpp2: fix validate for PPv2.1

[Antoine Tenart]

The Phylink validate function is the Marvell PPv2 driver makes a check
on the GoP id. This is valid an has to be done when using PPv2.2 engines
but makes no sense when using PPv2.1. The check done when using an RGMII
interface makes sure the GoP id is not 0, but this breaks PPv2.1. Fixes
it.

Fixes: 0fb628f0f250 ("net: mvpp2: fix phylink handling of invalid PHY modes")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 2c1de23ca267..f5b299656052 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4360,7 +4360,7 @@ static void mvpp2_phylink_validate(struct net_device *dev,
 	case PHY_INTERFACE_MODE_RGMII_ID:
 	case PHY_INTERFACE_MODE_RGMII_RXID:
 	case PHY_INTERFACE_MODE_RGMII_TXID:
-		if (port->gop_id == 0)
+		if (port->priv->hw_version == MVPP22 && port->gop_id == 0)
 			goto empty_set;
 		break;
 	default:
-- 
2.20.1

[PATCH net-next 08/13] net: mvpp2: fix the computation of the RXQs

[Antoine Tenart]

The patch fixes the computation of RXQs being used by the PPv2 driver,
which is set depending on the PPv2 engine version and the queue mode
used. There are three cases:

- PPv2.1: 1 RXQ per CPU.
- PPV2.2 with MVPP2_QDIST_MULTI_MODE: 1 RXQ per CPU.
- PPv2.2 with MVPP2_QDIST_SINGLE_MODE: 1 RXQ is shared between the CPUs.

The PPv2 engine supports a maximum of 32 queues per port. This patch
adds a check so that we do not overstep this maximum.

It appeared the calculation was broken for PPv2.1 engines since
f8c6ba8424b0, as PPv2.1 ports ended up with a single RXQ while they
needed 4. This patch fixes it.

Fixes: f8c6ba8424b0 ("net: mvpp2: use only one rx queue per port per CPU")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h    |  4 ++--
 .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 23 ++++++++++++-------
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 83fb2b03e789..ceb3c4ad3739 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -549,8 +549,8 @@
 #define MVPP2_MAX_TSO_SEGS		300
 #define MVPP2_MAX_SKB_DESCS		(MVPP2_MAX_TSO_SEGS * 2 + MAX_SKB_FRAGS)
 
-/* Default number of RXQs in use */
-#define MVPP2_DEFAULT_RXQ		1
+/* Max number of RXQs per port */
+#define MVPP2_PORT_MAX_RXQ		32
 
 /* Max number of Rx descriptors */
 #define MVPP2_MAX_RXD_MAX		1024
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index f5b299656052..4a18f8e54c90 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4058,8 +4058,8 @@ static int mvpp2_multi_queue_vectors_init(struct mvpp2_port *port,
 			snprintf(irqname, sizeof(irqname), "hif%d", i);
 
 		if (queue_mode == MVPP2_QDIST_MULTI_MODE) {
-			v->first_rxq = i * MVPP2_DEFAULT_RXQ;
-			v->nrxqs = MVPP2_DEFAULT_RXQ;
+			v->first_rxq = i;
+			v->nrxqs = 1;
 		} else if (queue_mode == MVPP2_QDIST_SINGLE_MODE &&
 			   i == (port->nqvecs - 1)) {
 			v->first_rxq = 0;
@@ -4152,8 +4152,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
 	    MVPP2_MAX_PORTS * priv->max_port_rxqs)
 		return -EINVAL;
 
-	if (port->nrxqs % MVPP2_DEFAULT_RXQ ||
-	    port->nrxqs > priv->max_port_rxqs || port->ntxqs > MVPP2_MAX_TXQ)
+	if (port->nrxqs > priv->max_port_rxqs || port->ntxqs > MVPP2_MAX_TXQ)
 		return -EINVAL;
 
 	/* Disable port */
@@ -4774,10 +4773,18 @@ static int mvpp2_port_probe(struct platform_device *pdev,
 	}
 
 	ntxqs = MVPP2_MAX_TXQ;
-	if (priv->hw_version == MVPP22 && queue_mode == MVPP2_QDIST_MULTI_MODE)
-		nrxqs = MVPP2_DEFAULT_RXQ * num_possible_cpus();
-	else
-		nrxqs = MVPP2_DEFAULT_RXQ;
+	if (priv->hw_version == MVPP22 && queue_mode == MVPP2_QDIST_SINGLE_MODE) {
+		nrxqs = 1;
+	} else {
+		/* According to the PPv2.2 datasheet and our experiments on
+		 * PPv2.1, RX queues have an allocation granularity of 4 (when
+		 * more than a single one on PPv2.2).
+		 * Round up to nearest multiple of 4.
+		 */
+		nrxqs = (num_possible_cpus() + 3) & ~0x3;
+		if (nrxqs > MVPP2_PORT_MAX_RXQ)
+			nrxqs = MVPP2_PORT_MAX_RXQ;
+	}
 
 	dev = alloc_etherdev_mqs(sizeof(*port), ntxqs, nrxqs);
 	if (!dev)
-- 
2.20.1

[PATCH net-next 09/13] net: mvpp2: update the port documentation regarding the GoP

[Antoine Tenart]

The Marvell PPv2 port structure stores the GoP id of a given port. This
information is specific to PPv2.2, but cannot be used by PPv2.1. Update
its comment to denote this specificity.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index ceb3c4ad3739..21ddcac1ceea 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -803,7 +803,7 @@ struct mvpp2_port {
 	u8 id;
 
 	/* Index of the port from the "group of ports" complex point
-	 * of view
+	 * of view. This is specific to PPv2.2.
 	 */
 	int gop_id;
 
-- 
2.20.1

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

[Antoine Tenart]

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.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.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

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

[Russell King - ARM Linux admin]

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@bootlin.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

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

[Stefan Chulski]

> 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.

Exist one mode that we should add to PPv2&COMPHY 5Gbase-KR(5GBASE-T).

Stefan,
Best Regards.

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

[Antoine Tenart]

Hi Russell,

On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> 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.

The configuration at the lane at boot time is dependent to the
firmware or bootloader configuration. On the mcbin, the lane may be
configured in 10Gbase-KR, but it could be configured in SGMII as well.
The configuration upon initialization and the re-configuration are quite
similar then, as we might change mode as well at boot time.

You're right in that we might be re-configuring the lane for the same
exact mode at boot time, if it was already configured in the same mode.

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

This applies only when configuring a line in a 10G mode,
mvpp22_gop_init_10gkr isn't called otherwise.

When switching to an non-10G mode we might want to put the XPCS in reset
though, which is not done today with this patch.

Thanks,
Antoine

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

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

[Russell King - ARM Linux admin]

On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> Hi Russell,
> 
> On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> > 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.
> 
> The configuration at the lane at boot time is dependent to the
> firmware or bootloader configuration. On the mcbin, the lane may be
> configured in 10Gbase-KR, but it could be configured in SGMII as well.
> The configuration upon initialization and the re-configuration are quite
> similar then, as we might change mode as well at boot time.
> 
> You're right in that we might be re-configuring the lane for the same
> exact mode at boot time, if it was already configured in the same mode.
> 
> > Does this apply to reconfiguration of the serdes lane between
> > 10Gbase-KR and slower modes?
> 
> This applies only when configuring a line in a 10G mode,
> mvpp22_gop_init_10gkr isn't called otherwise.
> 
> When switching to an non-10G mode we might want to put the XPCS in reset
> though, which is not done today with this patch.

I'm merely pointing out the discrepency between the commit message and
what is actually being done.  I'm not particularly concerned about what
happens at boot.

We have four different transitions a port can go through, all of which
reconfigure the serdes lanes:

1. 10gkr -> 10gkr
2. 10gkr -> non-10gkr
3. non-10gkr -> non-10gkr
4. non-10gkr -> 10gkr

With this patch, XPCS is only placed into reset during the
reconfiguration for cases 1 and 4.  Case 3 doesn't matter (the XPCS
should already be in reset right?)  Case 2 isn't covered, and this
leaves a rather big hole.

It seems to me that if the documentation states that the XPCS needs to
be placed in reset while the serdes is reconfigured, then what should
be happening is:

- at boot, place the XPCS into reset.
- when we configure for 10gkr, release the reset once we've finished
  configuring the serdes.
- when we configure away from 10gkr, place the XPCS back into reset
  before configuring the serdes.

Merely placing the XPCS into reset while we configure the serdes for
10gkr doesn't seem to be "fixing" the driver to conform to your commit
message opening statement.

-- 
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

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

[Russell King - ARM Linux admin]

On Mon, Feb 18, 2019 at 10:43:02AM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> > Hi Russell,
> > 
> > On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> > > 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.
> > 
> > The configuration at the lane at boot time is dependent to the
> > firmware or bootloader configuration. On the mcbin, the lane may be
> > configured in 10Gbase-KR, but it could be configured in SGMII as well.
> > The configuration upon initialization and the re-configuration are quite
> > similar then, as we might change mode as well at boot time.
> > 
> > You're right in that we might be re-configuring the lane for the same
> > exact mode at boot time, if it was already configured in the same mode.
> > 
> > > Does this apply to reconfiguration of the serdes lane between
> > > 10Gbase-KR and slower modes?
> > 
> > This applies only when configuring a line in a 10G mode,
> > mvpp22_gop_init_10gkr isn't called otherwise.
> > 
> > When switching to an non-10G mode we might want to put the XPCS in reset
> > though, which is not done today with this patch.
> 
> I'm merely pointing out the discrepency between the commit message and
> what is actually being done.  I'm not particularly concerned about what
> happens at boot.
> 
> We have four different transitions a port can go through, all of which
> reconfigure the serdes lanes:
> 
> 1. 10gkr -> 10gkr
> 2. 10gkr -> non-10gkr
> 3. non-10gkr -> non-10gkr
> 4. non-10gkr -> 10gkr
> 
> With this patch, XPCS is only placed into reset during the
> reconfiguration for cases 1 and 4.  Case 3 doesn't matter (the XPCS
> should already be in reset right?)  Case 2 isn't covered, and this
> leaves a rather big hole.
> 
> It seems to me that if the documentation states that the XPCS needs to
> be placed in reset while the serdes is reconfigured, then what should
> be happening is:
> 
> - at boot, place the XPCS into reset.
> - when we configure for 10gkr, release the reset once we've finished
>   configuring the serdes.
> - when we configure away from 10gkr, place the XPCS back into reset
>   before configuring the serdes.
> 
> Merely placing the XPCS into reset while we configure the serdes for
> 10gkr doesn't seem to be "fixing" the driver to conform to your commit
> message opening statement.

Another case that needs to be considered: if the XPCS should be placed
into reset while reconfiguring the serdes lanes, is the same treatment
needed for the GMAC?

-- 
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

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

[Antoine Tenart]

Russell,

On Mon, Feb 18, 2019 at 10:47:57AM +0000, Russell King - ARM Linux admin wrote:
> 
> Another case that needs to be considered: if the XPCS should be placed
> into reset while reconfiguring the serdes lanes, is the same treatment
> needed for the GMAC?

That's something I wanted to check as well. I don't know for the GMAC,
while I'm sure the documentation explicitly state to put the XPCS in
reset when reconfiguring the lanes.

Antoine

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

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

[Stefan Chulski]

> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Monday, February 18, 2019 12:52 PM
> To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com;
> gregory.clement@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Yan
> Markman <ymarkman@marvell.com>; mw@semihalf.com
> Subject: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while
> reconfiguring the serdes lanes
> 
> External Email
> 
> ----------------------------------------------------------------------
> Russell,
> 
> On Mon, Feb 18, 2019 at 10:47:57AM +0000, Russell King - ARM Linux admin
> wrote:
> >
> > Another case that needs to be considered: if the XPCS should be placed
> > into reset while reconfiguring the serdes lanes, is the same treatment
> > needed for the GMAC?
> 
> That's something I wanted to check as well. I don't know for the GMAC, while
> I'm sure the documentation explicitly state to put the XPCS in reset when
> reconfiguring the lanes.

HW recommendation upon Serdes reconfiguration are the following:

1. Disable port(CTRL0_REG - in XLG/GMAC) 
2. Put port in reset (both XLG/GMAC)
3. For KR - put in reset MPCS (MAC control clock, RX SD clock, TX SD clock), XPSC is RXAUI/XAUI clock domain
4. Power down Serdes lane

Do reconfiguration of Serdes.

5. Enable Serdes lane
6. Disable MPCS reset for KR
7. Disable port reset (both XLG/GMAC)
8. Enable port  (both XLG/GMAC)

Stefan,
Best Regards.

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

[Russell King - ARM Linux admin]

Hi Stefan,

On Mon, Feb 18, 2019 at 11:08:34AM +0000, Stefan Chulski wrote:
> HW recommendation upon Serdes reconfiguration are the following:
> 
> 1. Disable port(CTRL0_REG - in XLG/GMAC) 
> 2. Put port in reset (both XLG/GMAC)
> 3. For KR - put in reset MPCS (MAC control clock, RX SD clock, TX SD clock), XPSC is RXAUI/XAUI clock domain
> 4. Power down Serdes lane
> 
> Do reconfiguration of Serdes.
> 
> 5. Enable Serdes lane
> 6. Disable MPCS reset for KR
> 7. Disable port reset (both XLG/GMAC)
> 8. Enable port  (both XLG/GMAC)

For clarity, presumably either the XLG or the GMAC should be released
from reset and enabled at any one time depending on the configured mode,
but never both together?

-- 
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

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

[Stefan Chulski]

> -----Original Message-----
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Sent: Monday, February 18, 2019 1:28 PM
> To: Stefan Chulski <stefanc@marvell.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com;
> gregory.clement@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw@semihalf.com
> Subject: Re: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS
> while reconfiguring the serdes lanes
> 
> Hi Stefan,
> 
> On Mon, Feb 18, 2019 at 11:08:34AM +0000, Stefan Chulski wrote:
> > HW recommendation upon Serdes reconfiguration are the following:
> >
> > 1. Disable port(CTRL0_REG - in XLG/GMAC) 2. Put port in reset (both
> > XLG/GMAC) 3. For KR - put in reset MPCS (MAC control clock, RX SD
> > clock, TX SD clock), XPSC is RXAUI/XAUI clock domain 4. Power down
> > Serdes lane
> >
> > Do reconfiguration of Serdes.
> >
> > 5. Enable Serdes lane
> > 6. Disable MPCS reset for KR
> > 7. Disable port reset (both XLG/GMAC)
> > 8. Enable port  (both XLG/GMAC)
> 
> For clarity, presumably either the XLG or the GMAC should be released from
> reset and enabled at any one time depending on the configured mode, but
> never both together?

Yes.
Only one of them the XLG or the GMAC ,depending on the configured mode.

Best Regards.

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

[Antoine Tenart]

Russell,

On Mon, Feb 18, 2019 at 10:43:02AM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> > On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> > > 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.
> > 
> > The configuration at the lane at boot time is dependent to the
> > firmware or bootloader configuration. On the mcbin, the lane may be
> > configured in 10Gbase-KR, but it could be configured in SGMII as well.
> > The configuration upon initialization and the re-configuration are quite
> > similar then, as we might change mode as well at boot time.
> > 
> > You're right in that we might be re-configuring the lane for the same
> > exact mode at boot time, if it was already configured in the same mode.
> > 
> > > Does this apply to reconfiguration of the serdes lane between
> > > 10Gbase-KR and slower modes?
> > 
> > This applies only when configuring a line in a 10G mode,
> > mvpp22_gop_init_10gkr isn't called otherwise.
> > 
> > When switching to an non-10G mode we might want to put the XPCS in reset
> > though, which is not done today with this patch.
> 
> I'm merely pointing out the discrepency between the commit message and
> what is actually being done.  I'm not particularly concerned about what
> happens at boot.
> 
> We have four different transitions a port can go through, all of which
> reconfigure the serdes lanes:
> 
> 1. 10gkr -> 10gkr
> 2. 10gkr -> non-10gkr
> 3. non-10gkr -> non-10gkr
> 4. non-10gkr -> 10gkr
> 
> With this patch, XPCS is only placed into reset during the
> reconfiguration for cases 1 and 4.  Case 3 doesn't matter (the XPCS
> should already be in reset right?)  Case 2 isn't covered, and this
> leaves a rather big hole.
> 
> It seems to me that if the documentation states that the XPCS needs to
> be placed in reset while the serdes is reconfigured, then what should
> be happening is:
> 
> - at boot, place the XPCS into reset.
> - when we configure for 10gkr, release the reset once we've finished
>   configuring the serdes.
> - when we configure away from 10gkr, place the XPCS back into reset
>   before configuring the serdes.
> 
> Merely placing the XPCS into reset while we configure the serdes for
> 10gkr doesn't seem to be "fixing" the driver to conform to your commit
> message opening statement.

That's right, we should put the XPCS in reset when booting and when
switching away from a 10G mode. I'll fix that in v2.

Antoine

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

[PATCH net-next 11/13] net: mvpp2: reset the XLG MAC in port_reset

[Antoine Tenart]

The mvpp2_port_reset helper resets the GMAC but not the XLG MAC, which
is used on PPv2.2 when using the port 0. This patch fixes it, so that
the two MAC are set in reset when needed. In addition, the XLG
configuration function sets the XLG MAC out of reset when called.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 5d05306e79a8..80406195a255 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1384,6 +1384,17 @@ static void mvpp2_port_reset(struct mvpp2_port *port)
 	val = readl(port->base + MVPP2_GMAC_CTRL_2_REG) |
 	      MVPP2_GMAC_PORT_RESET_MASK;
 	writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
+
+	if (port->priv->hw_version == MVPP22 && port->gop_id == 0) {
+		/* Set the XLG MAC in reset */
+		val = readl(port->base + MVPP22_XLG_CTRL0_REG) &
+		      ~MVPP22_XLG_CTRL0_MAC_RESET_DIS;
+		writel(val, port->base + MVPP22_XLG_CTRL0_REG);
+
+		while (readl(port->base + MVPP22_XLG_CTRL0_REG) &
+		       MVPP22_XLG_CTRL0_MAC_RESET_DIS)
+			continue;
+	}
 }
 
 /* Change maximum receive size of the port */
@@ -4512,6 +4523,8 @@ static void mvpp2_xlg_config(struct mvpp2_port *port, unsigned int mode,
 	ctrl0 = readl(port->base + MVPP22_XLG_CTRL0_REG);
 	ctrl4 = readl(port->base + MVPP22_XLG_CTRL4_REG);
 
+	ctrl0 |= MVPP22_XLG_CTRL0_MAC_RESET_DIS;
+
 	if (state->pause & MLO_PAUSE_TX)
 		ctrl0 |= MVPP22_XLG_CTRL0_TX_FLOW_CTRL_EN;
 	else
-- 
2.20.1

[PATCH net-next 12/13] net: mvpp2: fix alignment of MVPP2_GMAC_CONFIG_MII_SPEED definition

[Antoine Tenart]

Cosmetic patch fix the alignment of the MVPP2_GMAC_CONFIG_MII_SPEED
macro definition.

Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 7380bddc53b8..6a2b5d0013b0 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -389,7 +389,7 @@
 #define     MVPP2_GMAC_IN_BAND_AUTONEG		BIT(2)
 #define     MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS	BIT(3)
 #define     MVPP2_GMAC_IN_BAND_RESTART_AN	BIT(4)
-#define     MVPP2_GMAC_CONFIG_MII_SPEED	BIT(5)
+#define     MVPP2_GMAC_CONFIG_MII_SPEED		BIT(5)
 #define     MVPP2_GMAC_CONFIG_GMII_SPEED	BIT(6)
 #define     MVPP2_GMAC_AN_SPEED_EN		BIT(7)
 #define     MVPP2_GMAC_FC_ADV_EN		BIT(9)
-- 
2.20.1

[PATCH net-next 13/13] net: mvpp2: some AN fields require the link to be down when updated

[Antoine Tenart]

The GMAC configuration helper modifies values in the auto-negotiation
register. Some of its values require the port to be forced down when
modifying their values. This patches fixes the check made on the bit to
be updated in this register, so that the port is forced down when
needed. This fix cases where some of those parameters were updated, but
not taken into account, such as when using RGMII interfaces.

Fixes: d14e078f23cc ("net: marvell: mvpp2: only reprogram what is necessary on mac_config")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 80406195a255..0419a18f0a28 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4641,9 +4641,19 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
 		}
 	}
 
+/* Some fields of the auto-negotiation register require the port to be down when
+ * their value is updated.
+ */
+#define MVPP2_GMAC_AN_PORT_DOWN_MASK	\
+		(MVPP2_GMAC_IN_BAND_AUTONEG | \
+		 MVPP2_GMAC_IN_BAND_AUTONEG_BYPASS | \
+		 MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_CONFIG_GMII_SPEED | \
+		 MVPP2_GMAC_AN_SPEED_EN | MVPP2_GMAC_CONFIG_FULL_DUPLEX | \
+		 MVPP2_GMAC_AN_DUPLEX_EN)
+
 	if ((old_ctrl0 ^ ctrl0) & MVPP2_GMAC_PORT_TYPE_MASK ||
 	    (old_ctrl2 ^ ctrl2) & MVPP2_GMAC_INBAND_AN_MASK ||
-	    (old_an ^ an) & MVPP2_GMAC_IN_BAND_AUTONEG) {
+	    (old_an ^ an) & MVPP2_GMAC_AN_PORT_DOWN_MASK) {
 		/* Force link down */
 		old_an &= ~MVPP2_GMAC_FORCE_LINK_PASS;
 		old_an |= MVPP2_GMAC_FORCE_LINK_DOWN;
-- 
2.20.1

Re: [PATCH net-next 00/13] net: mvpp2: various fixes

[David Miller]

From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 15 Feb 2019 16:32:28 +0100

> This series contains various fixes on bugs reported to us, or bugs I
> stumbled upon while testing the various interface configurations I have
> access to.
> 
> While this series contain fixes, it's sent to net-next as it is based
> on top of Russell's rework and fixes he sent during the last 2 weeks
> (such as his PPv2 phylink rework) that were applied to net-next. It'll
> also allow the users to have more time to test those changes.

Please respond to the feedback you've received.

Thank you.