Add support for the Turris Mox router

pinctrl: armada-37xx: Correct mpp definitions

This patch corrects below mpp definitions:
- The sdio_sb group is composed of 6 pins and not 5;
- The rgmii group contains pins mpp2[17:6] and not mpp2[19:6];
- Pin of group "pmic0" is mpp1[6] but not mpp1[16];
- Pin of group "pmic1" is mpp1[7] but not mpp1[17];
- A new group "smi" is added in A0 with 2 pins - mpp2[19:18], its bitmask is bit4;
- Group "pcie1" has 3 pins in A0 - mpp2[5:3], its bit mask is bit5 | bit9 | bit10 but not bit4;
- Group "ptp" has 3 pins in A0 as Z1, but its bitmask is changed to bit11 | bit12 | bit13.

Signed-off-by Marek Behun <[email protected]>

drivers/mfd/moxtet.c new file +3 -0

+		}
+	}
+}

The SFP cage GPIOs on the SFP cage module of Turris Mox can be configured via the moxtet bus.

This driver supports those GPIOs so that they can be used by phylink.

Quoted 3 lines · Marek Beh?n

The SFP cage GPIOs on the SFP cage module of Turris Mox can be configured via the moxtet bus.

Quoted 2 lines

This driver supports those GPIOs so that they can be used by phylink.

I don't see anything in this driver which is specific to SFP. It is just a GPIO driver for 3 lines. So i would drop all references to SFP. You can then use it to blink LEDs on some other module, etc.

Andrew

For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the networking driver behaves weirdly when using napi_gro_receive.

For example downloading a big file from a local network (low ping) is fast, but when downloading from a remote server (higher ping), the download speed is at first high but drops rapidly to almost nothing or absolutely nothing.

This is fixed when using netif_receive_skb instead of napi_gro_receive.

Quoted 8 lines · Marek Beh?n

For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the networking driver behaves weirdly when using napi_gro_receive.

For example downloading a big file from a local network (low ping) is fast, but when downloading from a remote server (higher ping), the download speed is at first high but drops rapidly to almost nothing or absolutely nothing.

Quoted 1 line

This is fixed when using netif_receive_skb instead of napi_gro_receive.

Before doing this, we should really understand what is going on. It is probably just a driver bug which needs fixing. And GRO should be good for performance, so we do want to use it, if possible.

Andrew

For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the networking driver behaves weirdly when using napi_gro_receive.

For example downloading a big file from a local network (low ping) is fast, but when downloading from a remote server (higher ping), the download speed is at first high but drops rapidly to almost nothing or absolutely nothing.

This is fixed when using netif_receive_skb instead of napi_gro_receive.

Signed-off-by Marek Behun <[email protected]>

Cc Russell King - ARM Linux <[email protected]>

Cc netdev at vger.kernel.org

drivers/net/ethernet/marvell/mvneta.c +8 -2

index 0ad2f3f7da85..27f3017d94c5 100644
@@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
 
 			skb->protocol = eth_type_trans(skb, dev);
 			mvneta_rx_csum(pp, rx_status, skb);
-			napi_gro_receive(&port->napi, skb);
+			if (pp->neta_armada3700)
+				netif_receive_skb(skb);
+			else
+				napi_gro_receive(&port->napi, skb);
 
 			rcvd_pkts++;
 			rcvd_bytes += rx_bytes;

@@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
 
 		mvneta_rx_csum(pp, rx_status, skb);
 
-		napi_gro_receive(&port->napi, skb);
+		if (pp->neta_armada3700)
+			netif_receive_skb(skb);
+		else
+			napi_gro_receive(&port->napi, skb);
 	}
 
 	if (rcvd_pkts) {

+ more people

Quoted 7 lines · On Wed, 8 Aug 2018 17:27:05 +0200 Marek Beh?n wrote:

For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the networking driver behaves weirdly when using napi_gro_receive.

For example downloading a big file from a local network (low ping) is fast, but when downloading from a remote server (higher ping), the download speed is at first high but drops rapidly to almost nothing or absolutely nothing.

We also met this issue on some berlin platforms. I tried to fix the bug, but no clue so far.

Quoted 2 lines

This is fixed when using netif_receive_skb instead of napi_gro_receive.

This is a workaround. The good news is this workaround also fixes the issue we saw on berlin.

Quoted 11 lines

Signed-off-by Marek Behun <[email protected]>

Cc Russell King - ARM Linux <[email protected]>

Cc netdev at vger.kernel.org

drivers/net/ethernet/marvell/mvneta.c +0 -0

index 0ad2f3f7da85..27f3017d94c5 100644
@@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
 

drivers/net/ethernet/marvell/mvneta.c static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, · line 1965

Quoted 7 lines

drivers/net/ethernet/marvell/mvneta.c +4 -1

 			skb->protocol = eth_type_trans(skb, dev);
 			mvneta_rx_csum(pp, rx_status, skb);
-			napi_gro_receive(&port->napi, skb);
+			if (pp->neta_armada3700)
+				netif_receive_skb(skb);
+			else
+				napi_gro_receive(&port->napi, skb);

Quoted 15 lines

drivers/net/ethernet/marvell/mvneta.c +4 -1

 			rcvd_pkts++;
 			rcvd_bytes += rx_bytes;

@@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
 
 		mvneta_rx_csum(pp, rx_status, skb);
 
-		napi_gro_receive(&port->napi, skb);
+		if (pp->neta_armada3700)
+			netif_receive_skb(skb);
+		else
+			napi_gro_receive(&port->napi, skb);
 	}
 
 	if (rcvd_pkts) {  

Hi,

Quoted 32 lines · On Thu, 9 Aug 2018 12:40:41 +0800 Jisheng Zhang wrote:

+ more people

Quoted 7 lines · On Wed, 8 Aug 2018 17:27:05 +0200 Marek Beh?n wrote:

For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the networking driver behaves weirdly when using napi_gro_receive.

For example downloading a big file from a local network (low ping) is fast, but when downloading from a remote server (higher ping), the download speed is at first high but drops rapidly to almost nothing or absolutely nothing.

We also met this issue on some berlin platforms. I tried to fix the bug, but no clue so far.

Quoted 2 lines

This is fixed when using netif_receive_skb instead of napi_gro_receive.

This is a workaround. The good news is this workaround also fixes the issue we saw on berlin.

Quoted 11 lines

Signed-off-by Marek Behun <[email protected]>

Cc Russell King - ARM Linux <[email protected]>

Cc netdev at vger.kernel.org

drivers/net/ethernet/marvell/mvneta.c +0 -0

index 0ad2f3f7da85..27f3017d94c5 100644
@@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
 

Quoted 7 lines

drivers/net/ethernet/marvell/mvneta.c static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo, · line 1965

Quoted 7 lines

drivers/net/ethernet/marvell/mvneta.c +4 -1

 			skb->protocol = eth_type_trans(skb, dev);
 			mvneta_rx_csum(pp, rx_status, skb);
-			napi_gro_receive(&port->napi, skb);
+			if (pp->neta_armada3700)
+				netif_receive_skb(skb);
+			else
+				napi_gro_receive(&port->napi, skb);  

I think I found the root cause, if neta_armada3700 is true, the port got from this_cpu_ptr(pp->ports) is invalid, this is bug... I'll cook a patch for this

Thanks

Quoted 16 lines

Quoted 15 lines

drivers/net/ethernet/marvell/mvneta.c +4 -1

 			rcvd_pkts++;
 			rcvd_bytes += rx_bytes;

@@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
 
 		mvneta_rx_csum(pp, rx_status, skb);
 
-		napi_gro_receive(&port->napi, skb);
+		if (pp->neta_armada3700)
+			netif_receive_skb(skb);
+		else
+			napi_gro_receive(&port->napi, skb);
 	}
 
 	if (rcvd_pkts) {    

Quoted 42 lines · On Thu, 9 Aug 2018 19:27:55 +0800 Jisheng Zhang wrote:

Hi,

Quoted 38 lines · On Thu, 9 Aug 2018 12:40:41 +0800 Jisheng Zhang wrote:

+ more people

Quoted 8 lines · On Wed, 8 Aug 2018 17:27:05 +0200 Marek Beh?n wrote:

For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the networking driver behaves weirdly when using napi_gro_receive.

For example downloading a big file from a local network (low ping) is fast, but when downloading from a remote server (higher ping), the download speed is at first high but drops rapidly to almost nothing or absolutely nothing.

We also met this issue on some berlin platforms. I tried to fix the bug, but no clue so far.

Quoted 3 lines

This is fixed when using netif_receive_skb instead of napi_gro_receive.

This is a workaround. The good news is this workaround also fixes the issue we saw on berlin.

Quoted 15 lines

Signed-off-by Marek Behun <[email protected]>

Cc Russell King - ARM Linux <[email protected]>

Cc netdev at vger.kernel.org

(quoted diff) +0 -0

b/drivers/net/ethernet/marvell/mvneta.c index 0ad2f3f7da85..27f3017d94c5 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
skb->protocol = eth_type_trans(skb,
dev); mvneta_rx_csum(pp, rx_status, skb);

(quoted diff) +1 -1

-			napi_gro_receive(&port->napi, skb);
+			if (pp->neta_armada3700)

Quoted 8 lines

Quoted 4 lines

Quoted 4 lines

drivers/net/ethernet/marvell/mvneta.c +3 -0

+				netif_receive_skb(skb);
+			else
+				napi_gro_receive(&port->napi,

skb);

I think I found the root cause, if neta_armada3700 is true, the port got from this_cpu_ptr(pp->ports) is invalid, this is bug... I'll cook a patch for this

correct it as:

the port's(port is got from this_cpu_ptr(pp->ports) napi is invalid.

Patch is sent out. Could you please try?

Per my test, it solves the issue we saw on berlin.

Quoted 20 lines

Thanks

Quoted 16 lines

Quoted 15 lines

drivers/net/ethernet/marvell/mvneta.c +4 -1

 			rcvd_pkts++;
 			rcvd_bytes += rx_bytes;

@@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct
 mvneta_port *pp, int rx_todo, 
 		mvneta_rx_csum(pp, rx_status, skb);
 
-		napi_gro_receive(&port->napi, skb);
+		if (pp->neta_armada3700)
+			netif_receive_skb(skb);
+		else
+			napi_gro_receive(&port->napi, skb);
 	}
 
 	if (rcvd_pkts) {