* [PATCH 0/2] SH: fix platform Ether support
From: Sergei Shtylyov @ 2013-08-17 22:13 UTC (permalink / raw)
To: netdev, lethal, linux-sh, davem
Hello.
[Resending with correct David's email.]
Here's a couple of patches fixing Ether support on some SH platforms.
They are against David Miller's 'net.git' (and also apply to 'net-next.git)
since they are prerequisite for the 'sh_eth' driver cleanup patchset that will
be posted a bit later. David, can I ask you to push these patches thru your
tree for that reason?
[1/2] SH7619: fix Ether support
[2/2] SolutionEngine7724: fix Ether support
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] SH7619: fix Ether support
From: Sergei Shtylyov @ 2013-08-17 22:15 UTC (permalink / raw)
To: netdev; +Cc: lethal, linux-sh, davem
In-Reply-To: <201308180213.23296.sergei.shtylyov@cogentembedded.com>
The 'sh_eth' driver's probe will crash as the platform code is hopelessly behind
the platform data -- it passes PHY ID instead of 'struct sh_eth_plat_data *'.
Strangely, both commit d88a3ea6fa4c (SH7619 add ethernet controler support) that
added the platform code and commit 71557a37adb5 ([netdrvr] sh_eth: Add SH7619
support) were done in about the same time, yet the latter one added 'struct
sh_eth_plat_data' and the platform code didn't ever get updated...
Add the proper platform data and fix off-by-one memory resource end error, while
at it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: stable@vger.kernel.org
---
arch/sh/kernel/cpu/sh2/setup-sh7619.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
Index: net/arch/sh/kernel/cpu/sh2/setup-sh7619.c
===================================================================
--- net.orig/arch/sh/kernel/cpu/sh2/setup-sh7619.c
+++ net/arch/sh/kernel/cpu/sh2/setup-sh7619.c
@@ -12,6 +12,7 @@
#include <linux/init.h>
#include <linux/serial.h>
#include <linux/serial_sci.h>
+#include <linux/sh_eth.h>
#include <linux/sh_timer.h>
#include <linux/io.h>
@@ -110,10 +111,17 @@ static struct platform_device scif2_devi
},
};
+static struct sh_eth_plat_data eth_platform_data = {
+ .phy = 1,
+ .edmac_endian = EDMAC_LITTLE_ENDIAN,
+ .register_type = SH_ETH_REG_FAST_SH3_SH2,
+ .phy_interace = PHY_INTERFACE_MODE_MII,
+};
+
static struct resource eth_resources[] = {
[0] = {
.start = 0xfb000000,
- .end = 0xfb0001c8,
+ .end = 0xfb0001c7,
.flags = IORESOURCE_MEM,
},
[1] = {
@@ -127,7 +135,7 @@ static struct platform_device eth_device
.name = "sh7619-ether",
.id = -1,
.dev = {
- .platform_data = (void *)1,
+ .platform_data = ð_platform_data,
},
.num_resources = ARRAY_SIZE(eth_resources),
.resource = eth_resources,
^ permalink raw reply
* [PATCH 2/2] SolutionEngine7724: fix Ether support
From: Sergei Shtylyov @ 2013-08-17 22:19 UTC (permalink / raw)
To: netdev, lethal, linux-sh, davem
In-Reply-To: <201308180213.23296.sergei.shtylyov@cogentembedded.com>
The Ether platform data is behind the declaration of 'struct sh_eth_plat_data'
as it's lacking the initializers for the 'register_type' and 'phy_interface'
fields -- it means they'll be implicitly and wrongly set to SH_ETH_REG_GIGABIT
and PHY_INTERFACE_MODE_NA. Initialize the fields explicitly and fix off-by-one
error in the Ether memory resource end, while at it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: stable@vger.kernel.org
---
arch/sh/boards/mach-se/7724/setup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: net/arch/sh/boards/mach-se/7724/setup.c
===================================================================
--- net.orig/arch/sh/boards/mach-se/7724/setup.c
+++ net/arch/sh/boards/mach-se/7724/setup.c
@@ -365,7 +365,7 @@ static struct platform_device keysc_devi
static struct resource sh_eth_resources[] = {
[0] = {
.start = SH_ETH_ADDR,
- .end = SH_ETH_ADDR + 0x1FC,
+ .end = SH_ETH_ADDR + 0x1FC - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
@@ -377,6 +377,8 @@ static struct resource sh_eth_resources[
static struct sh_eth_plat_data sh_eth_plat = {
.phy = 0x1f, /* SMSC LAN8187 */
.edmac_endian = EDMAC_LITTLE_ENDIAN,
+ .register_type = SH_ETH_REG_FAST_SH4,
+ .phy_interace = PHY_INTERFACE_MODE_MII,
};
static struct platform_device sh_eth_device = {
^ permalink raw reply
* [PATCH 0/2] sh_eth: don't get the register layout from platform data
From: Sergei Shtylyov @ 2013-08-17 23:08 UTC (permalink / raw)
To: netdev, davem; +Cc: lethal, linux-sh
Hello.
Here's a couple of patches making the 'sh_eth' driver get the register
layout from the internal data structures, not the platform data; this is
in preparation to adding device tree support to the driver. The patches are
against David Miller's 'net-next.git' repo and the couple of SH Ether fixes
I've just posted. David, if you decide to merge those SH patches into the
'net.git' repo, then a sync of it to 'net-next.git' would be required before
applying this series.
[1/2] sh_eth: get register layout from 'struct sh_eth_cpu_data'
[2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] sh_eth: get register layout from 'struct sh_eth_cpu_data'
From: Sergei Shtylyov @ 2013-08-17 23:11 UTC (permalink / raw)
To: netdev, davem; +Cc: linux-sh
In-Reply-To: <201308180308.39941.sergei.shtylyov@cogentembedded.com>
The register layout is a SoC characteristic, so it's wrong that it's stored
in the otherwise board specific platform data. Add 'register_type' field to
'struct sh_eth_cpu_data', initialize it properly for each SoC, and read it
from this structure instead of the platfrom data from now on...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 22 +++++++++++++++++++++-
drivers/net/ethernet/renesas/sh_eth.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -378,6 +378,8 @@ static struct sh_eth_cpu_data r8a777x_da
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_r8a777x,
+ .register_type = SH_ETH_REG_FAST_RCAR,
+
.ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
.ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
.eesipr_value = 0x01ff009f,
@@ -398,6 +400,8 @@ static struct sh_eth_cpu_data r8a7790_da
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_r8a777x,
+ .register_type = SH_ETH_REG_FAST_RCAR,
+
.ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
.ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
.eesipr_value = 0x01ff009f,
@@ -435,6 +439,8 @@ static struct sh_eth_cpu_data sh7724_dat
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_sh7724,
+ .register_type = SH_ETH_REG_FAST_SH4,
+
.ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
.ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
.eesipr_value = 0x01ff009f,
@@ -473,6 +479,8 @@ static struct sh_eth_cpu_data sh7757_dat
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_sh7757,
+ .register_type = SH_ETH_REG_FAST_SH4,
+
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
.rmcr_value = 0x00000001,
@@ -541,6 +549,8 @@ static struct sh_eth_cpu_data sh7757_dat
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_giga,
+ .register_type = SH_ETH_REG_GIGABIT,
+
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
@@ -599,6 +609,8 @@ static struct sh_eth_cpu_data sh7734_dat
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_gether,
+ .register_type = SH_ETH_REG_GIGABIT,
+
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
@@ -626,6 +638,8 @@ static struct sh_eth_cpu_data sh7763_dat
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_gether,
+ .register_type = SH_ETH_REG_GIGABIT,
+
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
@@ -663,6 +677,8 @@ static struct sh_eth_cpu_data r8a7740_da
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_gether,
+ .register_type = SH_ETH_REG_GIGABIT,
+
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
@@ -685,6 +701,8 @@ static struct sh_eth_cpu_data r8a7740_da
};
static struct sh_eth_cpu_data sh7619_data = {
+ .register_type = SH_ETH_REG_FAST_SH3_SH2,
+
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
.apr = 1,
@@ -694,6 +712,8 @@ static struct sh_eth_cpu_data sh7619_dat
};
static struct sh_eth_cpu_data sh771x_data = {
+ .register_type = SH_ETH_REG_FAST_SH3_SH2,
+
.eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
.tsu = 1,
};
@@ -2643,10 +2663,10 @@ static int sh_eth_drv_probe(struct platf
mdp->edmac_endian = pd->edmac_endian;
mdp->no_ether_link = pd->no_ether_link;
mdp->ether_link_active_low = pd->ether_link_active_low;
- mdp->reg_offset = sh_eth_get_register_offset(pd->register_type);
/* set cpu data */
mdp->cd = (struct sh_eth_cpu_data *)id->driver_data;
+ mdp->reg_offset = sh_eth_get_register_offset(mdp->cd->register_type);
sh_eth_set_default_cpu_data(mdp->cd);
/* set function */
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -454,6 +454,7 @@ struct sh_eth_cpu_data {
void (*set_rate)(struct net_device *ndev);
/* mandatory initialize value */
+ int register_type;
unsigned long eesipr_value;
/* optional initialize value */
^ permalink raw reply
* [PATCH 2/2] sh_eth: remove 'register_type' field from 'struct sh_eth_plat_data'
From: Sergei Shtylyov @ 2013-08-17 23:13 UTC (permalink / raw)
To: netdev, davem, lethal, linux-sh
In-Reply-To: <201308180308.39941.sergei.shtylyov@cogentembedded.com>
Now that the 'register_type' field of the 'sh_eth' driver's platform data is not
used by the driver anymore, it's time to remove it and its initializers from
the SH platform code. Also move *enum* declaring values for this field from
<linux/sh_eth.h> to the local driver's header file as they're only needed
by the driver itself now...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 1 -
arch/arm/mach-shmobile/board-bockw.c | 1 -
arch/sh/boards/board-espt.c | 1 -
arch/sh/boards/board-sh7757lcr.c | 4 ----
arch/sh/boards/mach-ecovec24/setup.c | 1 -
arch/sh/boards/mach-se/7724/setup.c | 1 -
arch/sh/boards/mach-sh7763rdp/setup.c | 1 -
arch/sh/kernel/cpu/sh2/setup-sh7619.c | 1 -
drivers/net/ethernet/renesas/sh_eth.h | 7 +++++++
include/linux/sh_eth.h | 7 -------
10 files changed, 7 insertions(+), 18 deletions(-)
Index: net-next/arch/arm/mach-shmobile/board-armadillo800eva.c
===================================================================
--- net-next.orig/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ net-next/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -358,7 +358,6 @@ static struct platform_device usbhsf_dev
static struct sh_eth_plat_data sh_eth_platdata = {
.phy = 0x00, /* LAN8710A */
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_GIGABIT,
.phy_interface = PHY_INTERFACE_MODE_MII,
};
Index: net-next/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- net-next.orig/arch/arm/mach-shmobile/board-bockw.c
+++ net-next/arch/arm/mach-shmobile/board-bockw.c
@@ -89,7 +89,6 @@ static struct sh_mobile_sdhi_info sdhi0_
static struct sh_eth_plat_data ether_platform_data __initdata = {
.phy = 0x01,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_FAST_RCAR,
.phy_interface = PHY_INTERFACE_MODE_RMII,
/*
* Although the LINK signal is available on the board, it's connected to
Index: net-next/arch/sh/boards/board-espt.c
===================================================================
--- net-next.orig/arch/sh/boards/board-espt.c
+++ net-next/arch/sh/boards/board-espt.c
@@ -80,7 +80,6 @@ static struct resource sh_eth_resources[
static struct sh_eth_plat_data sh7763_eth_pdata = {
.phy = 0,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_GIGABIT,
.phy_interface = PHY_INTERFACE_MODE_MII,
};
Index: net-next/arch/sh/boards/board-sh7757lcr.c
===================================================================
--- net-next.orig/arch/sh/boards/board-sh7757lcr.c
+++ net-next/arch/sh/boards/board-sh7757lcr.c
@@ -77,7 +77,6 @@ static struct resource sh_eth0_resources
static struct sh_eth_plat_data sh7757_eth0_pdata = {
.phy = 1,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_FAST_SH4,
.set_mdio_gate = sh7757_eth_set_mdio_gate,
};
@@ -106,7 +105,6 @@ static struct resource sh_eth1_resources
static struct sh_eth_plat_data sh7757_eth1_pdata = {
.phy = 1,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_FAST_SH4,
.set_mdio_gate = sh7757_eth_set_mdio_gate,
};
@@ -151,7 +149,6 @@ static struct resource sh_eth_giga0_reso
static struct sh_eth_plat_data sh7757_eth_giga0_pdata = {
.phy = 18,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_GIGABIT,
.set_mdio_gate = sh7757_eth_giga_set_mdio_gate,
.phy_interface = PHY_INTERFACE_MODE_RGMII_ID,
};
@@ -186,7 +183,6 @@ static struct resource sh_eth_giga1_reso
static struct sh_eth_plat_data sh7757_eth_giga1_pdata = {
.phy = 19,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_GIGABIT,
.set_mdio_gate = sh7757_eth_giga_set_mdio_gate,
.phy_interface = PHY_INTERFACE_MODE_RGMII_ID,
};
Index: net-next/arch/sh/boards/mach-ecovec24/setup.c
===================================================================
--- net-next.orig/arch/sh/boards/mach-ecovec24/setup.c
+++ net-next/arch/sh/boards/mach-ecovec24/setup.c
@@ -159,7 +159,6 @@ static struct resource sh_eth_resources[
static struct sh_eth_plat_data sh_eth_plat = {
.phy = 0x1f, /* SMSC LAN8700 */
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_FAST_SH4,
.phy_interface = PHY_INTERFACE_MODE_MII,
.ether_link_active_low = 1
};
Index: net-next/arch/sh/boards/mach-se/7724/setup.c
===================================================================
--- net-next.orig/arch/sh/boards/mach-se/7724/setup.c
+++ net-next/arch/sh/boards/mach-se/7724/setup.c
@@ -377,7 +377,6 @@ static struct resource sh_eth_resources[
static struct sh_eth_plat_data sh_eth_plat = {
.phy = 0x1f, /* SMSC LAN8187 */
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_FAST_SH4,
.phy_interace = PHY_INTERFACE_MODE_MII,
};
Index: net-next/arch/sh/boards/mach-sh7763rdp/setup.c
===================================================================
--- net-next.orig/arch/sh/boards/mach-sh7763rdp/setup.c
+++ net-next/arch/sh/boards/mach-sh7763rdp/setup.c
@@ -88,7 +88,6 @@ static struct resource sh_eth_resources[
static struct sh_eth_plat_data sh7763_eth_pdata = {
.phy = 1,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_GIGABIT,
.phy_interface = PHY_INTERFACE_MODE_MII,
};
Index: net-next/arch/sh/kernel/cpu/sh2/setup-sh7619.c
===================================================================
--- net-next.orig/arch/sh/kernel/cpu/sh2/setup-sh7619.c
+++ net-next/arch/sh/kernel/cpu/sh2/setup-sh7619.c
@@ -114,7 +114,6 @@ static struct platform_device scif2_devi
static struct sh_eth_plat_data eth_platform_data = {
.phy = 1,
.edmac_endian = EDMAC_LITTLE_ENDIAN,
- .register_type = SH_ETH_REG_FAST_SH3_SH2,
.phy_interace = PHY_INTERFACE_MODE_MII,
};
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -157,6 +157,13 @@ enum {
SH_ETH_MAX_REGISTER_OFFSET,
};
+enum {
+ SH_ETH_REG_GIGABIT,
+ SH_ETH_REG_FAST_RCAR,
+ SH_ETH_REG_FAST_SH4,
+ SH_ETH_REG_FAST_SH3_SH2
+};
+
/* Driver's parameters */
#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
#define SH4_SKB_RX_ALIGN 32
Index: net-next/include/linux/sh_eth.h
===================================================================
--- net-next.orig/include/linux/sh_eth.h
+++ net-next/include/linux/sh_eth.h
@@ -5,17 +5,10 @@
#include <linux/if_ether.h>
enum {EDMAC_LITTLE_ENDIAN, EDMAC_BIG_ENDIAN};
-enum {
- SH_ETH_REG_GIGABIT,
- SH_ETH_REG_FAST_RCAR,
- SH_ETH_REG_FAST_SH4,
- SH_ETH_REG_FAST_SH3_SH2
-};
struct sh_eth_plat_data {
int phy;
int edmac_endian;
- int register_type;
phy_interface_t phy_interface;
void (*set_mdio_gate)(void *addr);
^ permalink raw reply
* About tcp: set timestamps for restored skb-s
From: Eric Dumazet @ 2013-08-18 0:39 UTC (permalink / raw)
To: Andrey Vagin; +Cc: netdev
Because of gmail.com problems, I missed lot of netdev traffic
Related to :
http://patchwork.ozlabs.org/patch/267678/
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5423223..b2f6c74 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1121,6 +1121,13 @@ new_segment:
goto wait_for_memory;
/*
+ * All packets are restored as if they have
+ * already been sent.
+ */
+ if (tp->repair)
+ TCP_SKB_CB(skb)->when = tcp_time_stamp;
+
The test could be removed.
Setting @when for regular sends seems harmless
^ permalink raw reply related
* Re: [PATCH ipsec 1/3] ipv6: wire up skb->encapsulation
From: Simon Horman @ 2013-08-18 4:24 UTC (permalink / raw)
To: netdev, steffen.klassert, yoshfuji, nicolas.dichtel
In-Reply-To: <20130817180738.GA24518@order.stressinduktion.org>
On Sat, Aug 17, 2013 at 08:07:38PM +0200, Hannes Frederic Sowa wrote:
> Hi Simon!
>
> On Sat, Aug 17, 2013 at 07:51:16PM +0200, Hannes Frederic Sowa wrote:
> > When pushing a new header before current one call skb_reset_inner_headers
> > to record the position of the inner headers in the various ipv6 tunnel
> > protocols.
> >
> > We later need this to correctly identify the addresses needed to send
> > back an error in the xfrm layer.
> >
> > This change is safe, because skb->protocol is always checked before
> > dereferencing data from the inner protocol.
> >
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
> >
> > This patch is based on Steffen Klassert's ipsec tree.
> >
> > net/ipv6/ip6_gre.c | 5 +++++
> > net/ipv6/ip6_tunnel.c | 6 ++++++
> > net/ipv6/sit.c | 5 +++++
> > 3 files changed, 16 insertions(+)
> >
> > diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> > index ecd6073..90747f1 100644
> > --- a/net/ipv6/ip6_gre.c
> > +++ b/net/ipv6/ip6_gre.c
> > @@ -724,6 +724,11 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
> > ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
> > }
> >
> > + if (likely(!skb->encapsulation)) {
> > + skb_reset_inner_headers(skb);
> > + skb->encapsulation = 1;
> > + }
> > +
>
> While doing these patches, I wondered how skb->inner_protocol will be
> used in future (you added it in 0d89d2035fe063461a5ddb609b2c12e7fb006e44
> ("MPLS: Add limited GSO support")). Current use by tunnels seems safe to
> me, but I wondered how you would extend its use?
Hi,
I must confess that I'm not entirely sure that I understand the question.
The purpose of adding inner_protocol was to allow GSO of MPLS as MPLS is
rather special and does not include the inner protocol anywhere in the
packet. So this allows it to be known when GSO occurs if it was previously
known - I believe the sole use-case here is if a packet wasn't MPLS when
received but then turned into MPLS by Open vSwtich.
I'm not aware of any other encapsulation/tunnelling protocols which share
MPLS's unusual property of not including the inner-protocol in the packet,
but if they exist then skb->inner_protocol may be useful when adding GSO
support for them.
Beyond that I do not envisage any extension of the use of
skb->inner_protocol at this point. But I feel that somehow I am missing
the point of your question.
^ permalink raw reply
* NAT stops forwarding ACKs after PMTU discovery
From: Corey Hickey @ 2013-08-18 5:55 UTC (permalink / raw)
To: Linux Netdev List
Hi,
If there is a better user-oriented list I should ask this question on,
please tell me; I've asked a couple similar questions on netdev before
and gotten some great help.
I'm having a problem wherein some NATted connections stop forwarding
packets. I've troubleshot the problem far enough to tell that it happens
when path MTU discovery happens--the ACK to the retransmitted packet
never gets forwarded back to my local client (and neither do the
retransmitted ACKs).
This is my setup:
----------------------------------------------------------------------
MTU 9100 MTU 1355 MTU 1500
client --> linux router --> vpn --> work host
198.18.0.3 198.18.0.1 (eth0) 10.15.24.13
192.168.61.54 (tun0)
----------------------------------------------------------------------
I'm running openconnect on a Linux router to connect to a cisco VPN at
work. The Linux router does SNAT (MASQUERADE) over the virtual tun0
interface created by openconnect.
This is the best test I have so far:
$ sudo ip route flush cache ; ssh workhost.example.com exit
Read from socket failed: Connection reset by peer
Most of the time, this hangs for a few minutes before giving up;
sometimes it just works fine. tcpdumps indicate that when it works, all
packets transmitted are below the VPN's MTU; when it fails, MTU
discovery has happened:
1. client sends large packet, for example 1832 bytes
2. router sends ICMP fragmentation needed
3. client retransmits with a smaller packet, for example 1303 bytes
4. router forwards packet over VPN
5. work host ACKs packet
6. router receives ACK but does not forward it
7. both endpoints retransmit, but ACKs never get forwarded
The NAT table maintains an entry throughout (and continues to SNAT
retransmits from the client), but the ACKs from the server never get
forwarded.
fire:~# netstat-nat -n -d 10.15.24.13
Proto NATed Address Destination Address State
tcp 198.18.0.3:51076 10.15.24.13:22 ESTABLISHED
I put a LOG target on the INPUT chain, though, and apparently these
packets are bypassing the NAT; the kernel does not think they should be
forwarded (else they would be on the FORWARD chain).
[23335.509084] IN=tun0 OUT= MAC= SRC=10.15.24.13 DST=192.168.61.54
LEN=64 TOS=0x00 PREC=0x00 TTL=62 ID=28270 DF PROTO=TCP SPT=22 DPT=51076
WINDOW=134 RES=0x00 ACK FIN URGP=0
The kernel on the router is 3.10-2-amd64 (from Debian testing). I had
the same problem with 3.2.0-4-amd64 (from Debian stable), before I tried
to see if I could upgrade the problem away.
Any help would be much appreciated. I can send full tcpdumps if needed.
Thanks,
Corey
^ permalink raw reply
* Re: [PATCH RESEND] can: mcp251x: Replace power callbacks with regulator API
From: Marc Kleine-Budde @ 2013-08-18 8:00 UTC (permalink / raw)
To: Alexander Shiyan
Cc: Russell King, netdev, Haojian Zhuang, linux-can, linux-arm-kernel,
Eric Miao, Wolfgang Grandegger
In-Reply-To: <1376773805.878998573@f169.i.mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
On 08/17/2013 11:10 PM, Alexander Shiyan wrote:
[...]
>>> - xceiver-supply: Regulator that powers the CAN transceiver
>>
>> which translates into:
>>
>>> priv->reg_xceiver = devm_regulator_get(&pdev->dev, "xceiver");
>>
>> Can you please use "xceiver" instead of "transceiver", so that future DT
>> binding will fit the scheme.
>
> OK. I am not ready to add DT support yet, but it can be added later,
DT support can be added later, I just want to make sure that you use
"xceiver" for the regulator, so that you don't need to change any code
if DT is added.
> so v2 will contain 3 parts:
If you mean series v3 consists of three patches....
> 1 - Replace power callbacks with regulator API
> 2 - Eliminate mcp251x_platform_data->irq_flags
> 3 - Replace oscillator_frequency with CLK API (and remove mcp251x.h header)
>
> Are you OK with such changes?
...them I'm okay :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* [PATCH -next] moxa: fix missing unlock on error in moxart_mac_start_xmit()
From: Wei Yongjun @ 2013-08-18 8:09 UTC (permalink / raw)
To: grant.likely, rob.herring, davem, jonas.jensen
Cc: yongjun_wei, netdev, devicetree
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add the missing unlock before return from function moxart_mac_start_xmit()
in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/moxa/moxart_ether.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index abd2c54..6eee686 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -314,6 +314,7 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
unsigned int len;
unsigned int tx_head = priv->tx_head;
u32 txdes1;
+ int ret = NETDEV_TX_BUSY;
desc = priv->tx_desc_base + (TX_REG_DESC_SIZE * tx_head);
@@ -321,7 +322,7 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (readl(desc + TX_REG_OFFSET_DESC0) & TX_DESC0_DMA_OWN) {
net_dbg_ratelimited("no TX space for packet\n");
priv->stats.tx_dropped++;
- return NETDEV_TX_BUSY;
+ goto out_unlock;
}
len = skb->len > TX_BUF_SIZE ? TX_BUF_SIZE : skb->len;
@@ -330,7 +331,7 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
len, DMA_TO_DEVICE);
if (dma_mapping_error(&ndev->dev, priv->tx_mapping[tx_head])) {
netdev_err(ndev, "DMA mapping error\n");
- return NETDEV_TX_BUSY;
+ goto out_unlock;
}
priv->tx_len[tx_head] = len;
@@ -360,10 +361,11 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
priv->tx_head = TX_NEXT(tx_head);
ndev->trans_start = jiffies;
-
+ ret = NETDEV_TX_OK;
+out_unlock:
spin_unlock_irq(&priv->txlock);
- return NETDEV_TX_OK;
+ return ret;
}
static struct net_device_stats *moxart_mac_get_stats(struct net_device *ndev)
^ permalink raw reply related
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Thomas Gleixner @ 2013-08-18 9:05 UTC (permalink / raw)
To: Fan Du
Cc: Steffen Klassert, David Miller, Herbert Xu, Daniel Borkmann, LKML,
netdev
In-Reply-To: <520B4552.2000607@windriver.com>
On Wed, 14 Aug 2013, Fan Du wrote:
> From e3929d4fdfad5b40fd8cad0e217597670d1aef54 Mon Sep 17 00:00:00 2001
> From: Fan Du <fan.du@windriver.com>
> Date: Wed, 14 Aug 2013 16:39:23 +0800
> Subject: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was
> called
>
> When clock_was_set is called in case of system wall time change
> or host resume from suspend state, use this notifier for places
> where interested in this action, e.g Ipsec SA lifetime management.
Sigh. These notifiers have been proposed in the past and we always
rejected them. Why do you need this? There should be nothing except
the core timekeeping code which needs to know about clock_was_set.
Can you please explain what kind of users you have in mind and WHY
they need to know about it.
Thanks,
tglx
^ permalink raw reply
* [PATCH] pch_gbe: ethtool cannot change parameters when link is down
From: Anders Larsen @ 2013-08-18 9:54 UTC (permalink / raw)
To: David S. Miller; +Cc: Netdev, LKML
When attempting to change e.g. the advertising mask when the link is down
ecmd->speed is -1 causing mii_ethtool_sset() to bail out.
This bug bit when connecting to a gigabit switch through a 4-pin (industrial)
cable, since link negotiation would not complete (both endpoints claimed to
be gigabit-capable, but this is not possible with only 4 pins).
Any attempt to fix this by setting autonegation to not offer 1000Mbps
failed as the setting would not be accepted while the link was still down...
Set ecmd->speed to SPEED_1000 to satisfy mii_ethtool_sset()
(the actual value of ecmd->speed doesn't matter as long as it is valid,
since a re-negotation is forced afterwards).
Signed-off-by: Anders Larsen <al@alarsen.net>
---
.../ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
index 1129db0..f0ceb89 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_ethtool.c
@@ -118,6 +118,7 @@ static int pch_gbe_set_settings(struct net_device *netdev,
* filled by get_settings() on a down link, speed is -1: */
if (speed == UINT_MAX) {
speed = SPEED_1000;
+ ethtool_cmd_speed_set(ecmd, speed);
ecmd->duplex = DUPLEX_FULL;
}
ret = mii_ethtool_sset(&adapter->mii, ecmd);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH ipsec 1/3] ipv6: wire up skb->encapsulation
From: Hannes Frederic Sowa @ 2013-08-18 11:00 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, steffen.klassert, yoshfuji, nicolas.dichtel
In-Reply-To: <20130818042416.GK30709@verge.net.au>
On Sun, Aug 18, 2013 at 02:24:16PM +1000, Simon Horman wrote:
> On Sat, Aug 17, 2013 at 08:07:38PM +0200, Hannes Frederic Sowa wrote:
> > Hi Simon!
> >
> > On Sat, Aug 17, 2013 at 07:51:16PM +0200, Hannes Frederic Sowa wrote:
> > > When pushing a new header before current one call skb_reset_inner_headers
> > > to record the position of the inner headers in the various ipv6 tunnel
> > > protocols.
> > >
> > > We later need this to correctly identify the addresses needed to send
> > > back an error in the xfrm layer.
> > >
> > > This change is safe, because skb->protocol is always checked before
> > > dereferencing data from the inner protocol.
> > >
> > > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > > Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > > Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > > ---
> > >
> > > This patch is based on Steffen Klassert's ipsec tree.
> > >
> > > net/ipv6/ip6_gre.c | 5 +++++
> > > net/ipv6/ip6_tunnel.c | 6 ++++++
> > > net/ipv6/sit.c | 5 +++++
> > > 3 files changed, 16 insertions(+)
> > >
> > > diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> > > index ecd6073..90747f1 100644
> > > --- a/net/ipv6/ip6_gre.c
> > > +++ b/net/ipv6/ip6_gre.c
> > > @@ -724,6 +724,11 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
> > > ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
> > > }
> > >
> > > + if (likely(!skb->encapsulation)) {
> > > + skb_reset_inner_headers(skb);
> > > + skb->encapsulation = 1;
> > > + }
> > > +
> >
> > While doing these patches, I wondered how skb->inner_protocol will be
> > used in future (you added it in 0d89d2035fe063461a5ddb609b2c12e7fb006e44
> > ("MPLS: Add limited GSO support")). Current use by tunnels seems safe to
> > me, but I wondered how you would extend its use?
>
> Hi,
>
> I must confess that I'm not entirely sure that I understand the question.
Sorry to be not clear enough. I try to present my envisioned use case for
inner_protocol:
I do think there may be some other corner cases when reporting back
errors to a local socket when multiple tunnels+ipsecs are stacked into
each other. The first encapsulation sets skb->inner_network_header, so
that we can later extract the needed information for the error generation
via inner_ip{v6,}_hdr. It would be handy here to use inner_protocol to
mark the type of inner_network_header in advance (all this is because,
even if we still have a reference to the local socket and know its af,
it could also have emitted an IPv4 frame, so we have to jump to the ipv4
error handling path).
Thanks,
Hannes
^ permalink raw reply
* [PATCH ipsec v2 1/3] ipv6: wire up skb->encapsulation
From: Hannes Frederic Sowa @ 2013-08-18 11:46 UTC (permalink / raw)
To: netdev; +Cc: steffen.klassert, yoshfuji, nicolas.dichtel, edumazet
When pushing a new header before current one call skb_reset_inner_headers
to record the position of the inner headers in the various ipv6 tunnel
protocols.
We later need this to correctly identify the addresses needed to send
back an error in the xfrm layer.
This change is safe, because skb->protocol is always checked before
dereferencing data from the inner protocol.
v2:
a) unchanged
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
This patch is based on Steffen Klassert's ipsec tree.
net/ipv6/ip6_gre.c | 5 +++++
net/ipv6/ip6_tunnel.c | 6 ++++++
net/ipv6/sit.c | 5 +++++
3 files changed, 16 insertions(+)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index ecd6073..90747f1 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -724,6 +724,11 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
}
+ if (likely(!skb->encapsulation)) {
+ skb_reset_inner_headers(skb);
+ skb->encapsulation = 1;
+ }
+
skb_push(skb, gre_hlen);
skb_reset_network_header(skb);
skb_set_transport_header(skb, sizeof(*ipv6h));
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 1e55866..46ba243 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1027,6 +1027,12 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
init_tel_txopt(&opt, encap_limit);
ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
}
+
+ if (likely(!skb->encapsulation)) {
+ skb_reset_inner_headers(skb);
+ skb->encapsulation = 1;
+ }
+
skb_push(skb, sizeof(struct ipv6hdr));
skb_reset_network_header(skb);
ipv6h = ipv6_hdr(skb);
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index a3437a4..fbfc5a8 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -888,6 +888,11 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
ttl = iph6->hop_limit;
tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));
+ if (likely(!skb->encapsulation)) {
+ skb_reset_inner_headers(skb);
+ skb->encapsulation = 1;
+ }
+
err = iptunnel_xmit(dev_net(dev), rt, skb, fl4.saddr, fl4.daddr,
IPPROTO_IPV6, tos, ttl, df);
iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
--
1.8.3.1
^ permalink raw reply related
* [PATCH ipsec v2 2/3] ipv6: xfrm: dereference inner ipv6 header if encapsulated
From: Hannes Frederic Sowa @ 2013-08-18 11:46 UTC (permalink / raw)
To: netdev; +Cc: steffen.klassert, edumazet
In xfrm6_local_error use inner_header if the packet was encapsulated.
v2:
a) constify ipv6hdr (thanks to Eric Dumazet)
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
This patch is based on Steffen Klassert's ipsec tree.
net/ipv6/xfrm6_output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 3ac5ab2..e092e30 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -59,10 +59,12 @@ static void xfrm6_local_rxpmtu(struct sk_buff *skb, u32 mtu)
void xfrm6_local_error(struct sk_buff *skb, u32 mtu)
{
struct flowi6 fl6;
+ const struct ipv6hdr *hdr;
struct sock *sk = skb->sk;
+ hdr = skb->encapsulation ? inner_ipv6_hdr(skb) : ipv6_hdr(skb);
fl6.fl6_dport = inet_sk(sk)->inet_dport;
- fl6.daddr = ipv6_hdr(skb)->daddr;
+ fl6.daddr = hdr->daddr;
ipv6_local_error(sk, EMSGSIZE, &fl6, mtu);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH ipsec v2 3/3] xfrm: choose protocol family by skb protocol
From: Hannes Frederic Sowa @ 2013-08-18 11:47 UTC (permalink / raw)
To: netdev; +Cc: steffen.klassert, edumazet
We need to choose the protocol family by skb->protocol. Otherwise we
call the wrong xfrm{4,6}_local_error handler in case an ipv6 sockets is
used in ipv4 mode, in which case we should call down to xfrm4_local_error
(ip6 sockets are a superset of ip4 ones).
We are called before before ip_output functions, so skb->protocol is
not reset.
v2:
a) unchanged
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
This patch is based on Steffen Klassert's ipsec tree.
include/net/xfrm.h | 4 ++--
net/xfrm/xfrm_output.c | 10 +++++++++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index b41d2d1..ac5b025 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1728,9 +1728,9 @@ static inline int xfrm_skb_dst_mtu(struct sk_buff *skb)
{
struct sock *sk = skb->sk;
- if (sk && sk->sk_family == AF_INET6)
+ if (sk && skb->protocol == htons(ETH_P_IPV6))
return ip6_skb_dst_mtu(skb);
- else if (sk && sk->sk_family == AF_INET)
+ else if (sk && skb->protocol == htons(ETH_P_IP))
return ip_skb_dst_mtu(skb);
return dst_mtu(skb_dst(skb));
}
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 6f5fc61..3bb2cdc 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -216,9 +216,17 @@ int xfrm_inner_extract_output(struct xfrm_state *x, struct sk_buff *skb)
void xfrm_local_error(struct sk_buff *skb, int mtu)
{
+ unsigned int proto;
struct xfrm_state_afinfo *afinfo;
- afinfo = xfrm_state_get_afinfo(skb->sk->sk_family);
+ if (skb->protocol == htons(ETH_P_IP))
+ proto = AF_INET;
+ else if (skb->protocol == htons(ETH_P_IPV6))
+ proto = AF_INET6;
+ else
+ return;
+
+ afinfo = xfrm_state_get_afinfo(proto);
if (!afinfo)
return;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 2/2] bnx2x: add RSS capability for GRE traffic
From: Jerry Chu @ 2013-08-18 11:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dmitry Kravkov, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, Eilon Greenstein, Tom Herbert,
Maciej Żenczykowski
In-Reply-To: <1376766116.21329.9.camel@edumazet-glaptop>
On Sat, Aug 17, 2013 at 12:01 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2013-08-17 at 21:52 +0300, Dmitry Kravkov wrote:
>
>>
>> Current bnx2x HW is not able to perform CSUM validation for
>> encapsulated packets, so in any case host needs to do that.
>> Today GRO/TPA feature depends on CSUM, but theoretically (i did not
>> investigate it) and probably HW can provide aggregated packets w/o
>> csum validation - this will save headers processing for host.
>
> I am not sure I understand this.
>
> Aggregation cannot be done if csums are not validated.
Unless all the csums from aggregated pkts are also aggregated into one
(so that the host computes s/w csum on the large pkt and validates against
the aggregated csum...) There may be some performance benefit for doing
this but it may arguably weaken already weak 1's complement csum.
Jerry
>
>
^ permalink raw reply
* [PATCH v3] r8169: fix invalid register dump
From: Peter Wu @ 2013-08-18 13:41 UTC (permalink / raw)
To: Francois Romieu, Ben Hutchings; +Cc: lekensteyn, netdev, nic_swsd
For some reason, my PCIe RTL8111E onboard NIC on a GA-Z68X-UD3H-B3
motherboard reads as FFs when reading from MMIO with a block size
larger than 7. Therefore change to reading blocks of four bytes.
Ben Hutchings noted that the buffer is large enough to hold all
registers, so now all registers are read. Since regs->len is not used
anymore, drop the superfluous range check as well. (ethtool would
already ensure that regs->len <= R8169_REGS_SIZE).
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
---
Hi,
This partly obsoletes "r8169,sis190: remove unnecessary length
check"[1]. I do not have sis190 hardware, but since that is based on
this r8169 driver, would it make sense to apply this patch to sis190
too?
Regards,
Peter
[1]: http://www.spinics.net/lists/netdev/msg246824.html
---
drivers/net/ethernet/realtek/r8169.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index b5eb419..c0c9e14 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1897,12 +1897,13 @@ static void rtl8169_get_regs(struct net_device *dev, struct ethtool_regs *regs,
void *p)
{
struct rtl8169_private *tp = netdev_priv(dev);
-
- if (regs->len > R8169_REGS_SIZE)
- regs->len = R8169_REGS_SIZE;
+ u32 __iomem *data = tp->mmio_addr;
+ u32 *dw = p;
+ int i;
rtl_lock_work(tp);
- memcpy_fromio(p, tp->mmio_addr, regs->len);
+ for (i = 0; i < R8169_REGS_SIZE; i += 4)
+ memcpy_fromio(dw++, data++, 4);
rtl_unlock_work(tp);
}
--
1.8.3.4
^ permalink raw reply related
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-18 15:24 UTC (permalink / raw)
To: Corey Hickey; +Cc: Linux Netdev List, netfilter-devel
In-Reply-To: <521061B4.1030508@fatooh.org>
On Sat, 2013-08-17 at 22:55 -0700, Corey Hickey wrote:
> Hi,
>
> If there is a better user-oriented list I should ask this question on,
> please tell me; I've asked a couple similar questions on netdev before
> and gotten some great help.
>
>
> I'm having a problem wherein some NATted connections stop forwarding
> packets. I've troubleshot the problem far enough to tell that it happens
> when path MTU discovery happens--the ACK to the retransmitted packet
> never gets forwarded back to my local client (and neither do the
> retransmitted ACKs).
>
> This is my setup:
> ----------------------------------------------------------------------
> MTU 9100 MTU 1355 MTU 1500
> client --> linux router --> vpn --> work host
> 198.18.0.3 198.18.0.1 (eth0) 10.15.24.13
> 192.168.61.54 (tun0)
> ----------------------------------------------------------------------
>
> I'm running openconnect on a Linux router to connect to a cisco VPN at
> work. The Linux router does SNAT (MASQUERADE) over the virtual tun0
> interface created by openconnect.
>
> This is the best test I have so far:
>
> $ sudo ip route flush cache ; ssh workhost.example.com exit
> Read from socket failed: Connection reset by peer
>
> Most of the time, this hangs for a few minutes before giving up;
> sometimes it just works fine. tcpdumps indicate that when it works, all
> packets transmitted are below the VPN's MTU; when it fails, MTU
> discovery has happened:
>
> 1. client sends large packet, for example 1832 bytes
> 2. router sends ICMP fragmentation needed
> 3. client retransmits with a smaller packet, for example 1303 bytes
> 4. router forwards packet over VPN
> 5. work host ACKs packet
> 6. router receives ACK but does not forward it
> 7. both endpoints retransmit, but ACKs never get forwarded
>
> The NAT table maintains an entry throughout (and continues to SNAT
> retransmits from the client), but the ACKs from the server never get
> forwarded.
>
> fire:~# netstat-nat -n -d 10.15.24.13
> Proto NATed Address Destination Address State
> tcp 198.18.0.3:51076 10.15.24.13:22 ESTABLISHED
>
>
> I put a LOG target on the INPUT chain, though, and apparently these
> packets are bypassing the NAT; the kernel does not think they should be
> forwarded (else they would be on the FORWARD chain).
>
> [23335.509084] IN=tun0 OUT= MAC= SRC=10.15.24.13 DST=192.168.61.54
> LEN=64 TOS=0x00 PREC=0x00 TTL=62 ID=28270 DF PROTO=TCP SPT=22 DPT=51076
> WINDOW=134 RES=0x00 ACK FIN URGP=0
>
>
> The kernel on the router is 3.10-2-amd64 (from Debian testing). I had
> the same problem with 3.2.0-4-amd64 (from Debian stable), before I tried
> to see if I could upgrade the problem away.
>
> Any help would be much appreciated. I can send full tcpdumps if needed.
This looks like the bug we had to fix recently :
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=356d7d88e088687b6578ca64601b0a2c9d145296
Could you try latest net tree ?
^ permalink raw reply
* [PATCH net-next] tcp: trivial: Remove nocache argument from tcp_v4_send_synack
From: Christoph Paasch @ 2013-08-18 15:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
The nocache-argument was used in tcp_v4_send_synack as an argument to
inet_csk_route_req. However, since ba3f7f04ef2b (ipv4: Kill
FLOWI_FLAG_RT_NOCACHE and associated code.) this is no more used.
This patch removes the unsued argument from tcp_v4_send_synack.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
net/ipv4/tcp_ipv4.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 05a3d45..09d45d7 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -821,8 +821,7 @@ static void tcp_v4_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
*/
static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
struct request_sock *req,
- u16 queue_mapping,
- bool nocache)
+ u16 queue_mapping)
{
const struct inet_request_sock *ireq = inet_rsk(req);
struct flowi4 fl4;
@@ -852,7 +851,7 @@ static int tcp_v4_send_synack(struct sock *sk, struct dst_entry *dst,
static int tcp_v4_rtx_synack(struct sock *sk, struct request_sock *req)
{
- int res = tcp_v4_send_synack(sk, NULL, req, 0, false);
+ int res = tcp_v4_send_synack(sk, NULL, req, 0);
if (!res)
TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_RETRANSSEGS);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH net-next 2/2] bnx2x: add RSS capability for GRE traffic
From: Eric Dumazet @ 2013-08-18 15:37 UTC (permalink / raw)
To: Jerry Chu
Cc: Dmitry Kravkov, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, Eilon Greenstein, Tom Herbert,
Maciej Żenczykowski
In-Reply-To: <CAPshTCh3CqrgasEvFG_Yy8NRHMp_rrQDqn7eRMD9NycmpxaWkQ@mail.gmail.com>
On Sun, 2013-08-18 at 04:55 -0700, Jerry Chu wrote:
> On Sat, Aug 17, 2013 at 12:01 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Sat, 2013-08-17 at 21:52 +0300, Dmitry Kravkov wrote:
> >
> >>
> >> Current bnx2x HW is not able to perform CSUM validation for
> >> encapsulated packets, so in any case host needs to do that.
> >> Today GRO/TPA feature depends on CSUM, but theoretically (i did not
> >> investigate it) and probably HW can provide aggregated packets w/o
> >> csum validation - this will save headers processing for host.
> >
> > I am not sure I understand this.
> >
> > Aggregation cannot be done if csums are not validated.
>
> Unless all the csums from aggregated pkts are also aggregated into one
> (so that the host computes s/w csum on the large pkt and validates against
> the aggregated csum...) There may be some performance benefit for doing
> this but it may arguably weaken already weak 1's complement csum.
To aggregate two packets, you first have to make sure the checksums of
each packet are ok. If the hardware does not validate checksum, then it
cannot aggregate packets.
Sure, CHECKSUM_COMPLETE support would be nice, so that linux can perform
aggregation without having to bring into cpu cache the whole frame.
^ permalink raw reply
* Re: [PATCH net-next] tcp: trivial: Remove nocache argument from tcp_v4_send_synack
From: Eric Dumazet @ 2013-08-18 15:38 UTC (permalink / raw)
To: Christoph Paasch; +Cc: David Miller, netdev
In-Reply-To: <1376840078-6556-1-git-send-email-christoph.paasch@uclouvain.be>
On Sun, 2013-08-18 at 17:34 +0200, Christoph Paasch wrote:
> The nocache-argument was used in tcp_v4_send_synack as an argument to
> inet_csk_route_req. However, since ba3f7f04ef2b (ipv4: Kill
> FLOWI_FLAG_RT_NOCACHE and associated code.) this is no more used.
>
> This patch removes the unsued argument from tcp_v4_send_synack.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> net/ipv4/tcp_ipv4.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH ipsec v2 3/3] xfrm: choose protocol family by skb protocol
From: Eric Dumazet @ 2013-08-18 15:48 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, steffen.klassert, edumazet
In-Reply-To: <20130818114701.GA10270@order.stressinduktion.org>
On Sun, 2013-08-18 at 13:47 +0200, Hannes Frederic Sowa wrote:
> We need to choose the protocol family by skb->protocol. Otherwise we
> call the wrong xfrm{4,6}_local_error handler in case an ipv6 sockets is
> used in ipv4 mode, in which case we should call down to xfrm4_local_error
> (ip6 sockets are a superset of ip4 ones).
>
> We are called before before ip_output functions, so skb->protocol is
> not reset.
>
> v2:
> a) unchanged
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
Hi Hannes
For your next patches, please add the v1/v2/v3 stuff _after_ the ---
separator as in :
Normal changelog (will be included in git history)
Signed-off-by: ....
Cc: ...
---
v2: Fix (you can omit this line if there was no change between v2 and
v1)
diffstat
diff
This is to have clean changelogs, with high S/N ratio ;)
Thanks !
^ permalink raw reply
* Re: [PATCH ipsec v2 3/3] xfrm: choose protocol family by skb protocol
From: Hannes Frederic Sowa @ 2013-08-18 16:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, steffen.klassert, edumazet
In-Reply-To: <1376840901.21329.47.camel@edumazet-glaptop>
On Sun, Aug 18, 2013 at 08:48:21AM -0700, Eric Dumazet wrote:
> On Sun, 2013-08-18 at 13:47 +0200, Hannes Frederic Sowa wrote:
> > We need to choose the protocol family by skb->protocol. Otherwise we
> > call the wrong xfrm{4,6}_local_error handler in case an ipv6 sockets is
> > used in ipv4 mode, in which case we should call down to xfrm4_local_error
> > (ip6 sockets are a superset of ip4 ones).
> >
> > We are called before before ip_output functions, so skb->protocol is
> > not reset.
> >
> > v2:
> > a) unchanged
> >
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Acked-by: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
>
> Hi Hannes
>
> For your next patches, please add the v1/v2/v3 stuff _after_ the ---
> separator as in :
>
> Normal changelog (will be included in git history)
>
> Signed-off-by: ....
> Cc: ...
> ---
> v2: Fix (you can omit this line if there was no change between v2 and
> v1)
> diffstat
> diff
>
>
> This is to have clean changelogs, with high S/N ratio ;)
Of course, I can do so.
Actually, I thought having the changelog in the commit msg is an extra
plus (even it is mostly inexpressive) because one knows there could be
more than one thread on the mailing list regarding the commit.
Thanks,
Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox