* [PATCH 2/7] ipv6 addrconf: remove addrconf_sysctl_hop_limit()
From: Maciej Żenczykowski @ 2016-09-24 16:05 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller
Cc: netdev, Erik Kline, Lorenzo Colitti
In-Reply-To: <1474733109-18355-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <maze@google.com>
replace with extra1/2 magic
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
net/ipv6/addrconf.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 11fa1a5564d4..3a835495fb53 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -5467,20 +5467,6 @@ int addrconf_sysctl_forward(struct ctl_table *ctl, int write,
}
static
-int addrconf_sysctl_hop_limit(struct ctl_table *ctl, int write,
- void __user *buffer, size_t *lenp, loff_t *ppos)
-{
- struct ctl_table lctl;
- int min_hl = 1, max_hl = 255;
-
- lctl = *ctl;
- lctl.extra1 = &min_hl;
- lctl.extra2 = &max_hl;
-
- return proc_dointvec_minmax(&lctl, write, buffer, lenp, ppos);
-}
-
-static
int addrconf_sysctl_mtu(struct ctl_table *ctl, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
@@ -5713,6 +5699,9 @@ int addrconf_sysctl_ignore_routes_with_linkdown(struct ctl_table *ctl,
return ret;
}
+static int one = 1;
+static int two_five_five = 255;
+
static const struct ctl_table addrconf_sysctl[] = {
{
.procname = "forwarding",
@@ -5726,7 +5715,9 @@ static const struct ctl_table addrconf_sysctl[] = {
.data = &ipv6_devconf.hop_limit,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = addrconf_sysctl_hop_limit,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &one,
+ .extra2 = &two_five_five,
},
{
.procname = "mtu",
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/7] ipv6 addrconf: enable use of proc_dointvec_minmax in addrconf_sysctl
From: Maciej Żenczykowski @ 2016-09-24 16:05 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller
Cc: netdev, Erik Kline, Lorenzo Colitti
In-Reply-To: <CAHo-Oozocj2rzY8hTTr1f3roMy9iz50j6X=dBG5qmz4B_LFAFQ@mail.gmail.com>
From: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
net/ipv6/addrconf.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -6044,8 +6044,14 @@ static int __addrconf_sysctl_register(struct net *net, char *dev_name,
for (i = 0; table[i].data; i++) {
table[i].data += (char *)p - (char *)&ipv6_devconf;
- table[i].extra1 = idev; /* embedded; no ref */
- table[i].extra2 = net;
+ /* If one of these is already set, then it is not safe to
+ * overwrite either of them: this makes proc_dointvec_minmax
+ * usable.
+ */
+ if (!table[i].extra1 && !table[i].extra2) {
+ table[i].extra1 = idev; /* embedded; no ref */
+ table[i].extra2 = net;
+ }
}
snprintf(path, sizeof(path), "net/ipv6/conf/%s", dev_name);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Implement rfc7559 ipv6 router solicitation backoff
From: Maciej Żenczykowski @ 2016-09-24 16:01 UTC (permalink / raw)
To: Linux NetDev, David Miller, Erik Kline, Lorenzo Colitti
^ permalink raw reply
* Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages
From: Jean Delvare @ 2016-09-24 15:55 UTC (permalink / raw)
To: Joe Perches
Cc: Larry Finger, Chaoming Li, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1474657363.1849.9.camel@perches.com>
Hi Joe, Larry,
On Fri, 23 Sep 2016 12:02:43 -0700, Joe Perches wrote:
> On Fri, 2016-09-23 at 13:59 -0500, Larry Finger wrote:
> > I'm not familiar with the %#x format. What does it do?
>
> Outputs SPECIAL prefix, it's the same as "0x%x"
>
> lib/vsprintf.c:
> #define SPECIAL 64 /* prefix hex with "0x", octal with "0" */
Is hexadecimal actually the best way to display these values? I guess it
depends how they are listed in the datasheets (if there's anything like
that for these chips?)
I found it a bit difficult to look up the meaning of the value.
HAL_DEF_WOWLAN is an enum value, the number is not set and there's no
comment. I had to count the line numbers, taking blank lines into
account... I ended up pasting the whole enum to a random C file and
printing the value of HAL_DEF_WOWLAN to make sure it was 92.
Would it make sense to explicitly set the enum values, or add them as
comments, to make such look-ups easier?
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH 0/3] net: fec: updates to align IP header
From: Eric Nelson @ 2016-09-24 15:29 UTC (permalink / raw)
To: Andy Duan, netdev@vger.kernel.org
Cc: linux@arm.linux.org.uk, andrew@lunn.ch, otavio@ossystems.com.br,
edumazet@google.com, troy.kisky@boundarydevices.com,
davem@davemloft.net, u.kleine-koenig@pengutronix.de
In-Reply-To: <AM4PR0401MB2260BDF848F89A445B1D013BFFCB0@AM4PR0401MB2260.eurprd04.prod.outlook.com>
On 09/24/2016 08:09 AM, Andy Duan wrote:
> From: Eric Nelson <eric@nelint.com> Sent: Saturday, September 24, 2016 10:42 PM
>> To: netdev@vger.kernel.org
>> Cc: linux@arm.linux.org.uk; andrew@lunn.ch; Andy Duan
>> <fugang.duan@nxp.com>; otavio@ossystems.com.br;
>> edumazet@google.com; troy.kisky@boundarydevices.com;
>> davem@davemloft.net; u.kleine-koenig@pengutronix.de; Eric Nelson
>> <eric@nelint.com>
>> Subject: [PATCH 0/3] net: fec: updates to align IP header
>>
>> This patch series is the outcome of investigation into very high numbers of
>> alignment faults on kernel 4.1.33 from the linux-fslc
>> tree:
>> https://github.com/freescale/linux-fslc/tree/4.1-1.0.x-imx
>>
>> The first two patches remove support for the receive accelerator (RACC)
>> from the i.MX25 and i.MX27 SoCs which don't support the function.
>>
>> The third patch enables hardware alignment of the ethernet packet payload
>> (and especially the IP header) to prevent alignment faults in the IP stack.
>>
>> Testing on i.MX6UL on the 4.1.33 kernel showed that this patch removed on
>> the order of 70k alignment faults during a 100MiB transfer using wget.
>>
>> Testing on an i.MX6Q (SABRE Lite) board on net-next (4.8.0-rc7) showed a
>> much more modest improvement from 10's of faults, and it's not clear why
>> that's the case.
>>
>> Eric Nelson (3):
>> net: fec: remove QUIRK_HAS_RACC from i.mx25
>> net: fec: remove QUIRK_HAS_RACC from i.mx27
>> net: fec: align IP header in hardware
>>
>> drivers/net/ethernet/freescale/fec_main.c | 15 ++++++++++++---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> --
>> 2.7.4
> I will investigate the diff between 4.1 and 4.8. Thanks.
>
Thanks. Note that I'm not sure if the difference is 4.1 vs. 4.8 or
i.MX6UL vs. i.MX6Q.
> Acked-by: Fugang Duan <fugang.duan@nxp.com>
>
^ permalink raw reply
* RE: [PATCH 0/3] net: fec: updates to align IP header
From: Andy Duan @ 2016-09-24 15:09 UTC (permalink / raw)
To: Eric Nelson, netdev@vger.kernel.org
Cc: linux@arm.linux.org.uk, andrew@lunn.ch, otavio@ossystems.com.br,
edumazet@google.com, troy.kisky@boundarydevices.com,
davem@davemloft.net, u.kleine-koenig@pengutronix.de
In-Reply-To: <1474728139-9335-1-git-send-email-eric@nelint.com>
From: Eric Nelson <eric@nelint.com> Sent: Saturday, September 24, 2016 10:42 PM
> To: netdev@vger.kernel.org
> Cc: linux@arm.linux.org.uk; andrew@lunn.ch; Andy Duan
> <fugang.duan@nxp.com>; otavio@ossystems.com.br;
> edumazet@google.com; troy.kisky@boundarydevices.com;
> davem@davemloft.net; u.kleine-koenig@pengutronix.de; Eric Nelson
> <eric@nelint.com>
> Subject: [PATCH 0/3] net: fec: updates to align IP header
>
> This patch series is the outcome of investigation into very high numbers of
> alignment faults on kernel 4.1.33 from the linux-fslc
> tree:
> https://github.com/freescale/linux-fslc/tree/4.1-1.0.x-imx
>
> The first two patches remove support for the receive accelerator (RACC)
> from the i.MX25 and i.MX27 SoCs which don't support the function.
>
> The third patch enables hardware alignment of the ethernet packet payload
> (and especially the IP header) to prevent alignment faults in the IP stack.
>
> Testing on i.MX6UL on the 4.1.33 kernel showed that this patch removed on
> the order of 70k alignment faults during a 100MiB transfer using wget.
>
> Testing on an i.MX6Q (SABRE Lite) board on net-next (4.8.0-rc7) showed a
> much more modest improvement from 10's of faults, and it's not clear why
> that's the case.
>
> Eric Nelson (3):
> net: fec: remove QUIRK_HAS_RACC from i.mx25
> net: fec: remove QUIRK_HAS_RACC from i.mx27
> net: fec: align IP header in hardware
>
> drivers/net/ethernet/freescale/fec_main.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
I will investigate the diff between 4.1 and 4.8. Thanks.
Acked-by: Fugang Duan <fugang.duan@nxp.com>
^ permalink raw reply
* [PATCH 0/3] net: fec: updates to align IP header
From: Eric Nelson @ 2016-09-24 14:42 UTC (permalink / raw)
To: netdev
Cc: linux, andrew, fugang.duan, otavio, edumazet, troy.kisky, davem,
u.kleine-koenig, Eric Nelson
In-Reply-To: <AM4PR0401MB22609D8151C2B63CA7768A1AFFCB0@AM4PR0401MB2260.eurprd04.prod.outlook.com>
This patch series is the outcome of investigation into very high
numbers of alignment faults on kernel 4.1.33 from the linux-fslc
tree:
https://github.com/freescale/linux-fslc/tree/4.1-1.0.x-imx
The first two patches remove support for the receive accelerator (RACC) from
the i.MX25 and i.MX27 SoCs which don't support the function.
The third patch enables hardware alignment of the ethernet packet payload
(and especially the IP header) to prevent alignment faults in the IP stack.
Testing on i.MX6UL on the 4.1.33 kernel showed that this patch removed
on the order of 70k alignment faults during a 100MiB transfer using
wget.
Testing on an i.MX6Q (SABRE Lite) board on net-next (4.8.0-rc7) showed
a much more modest improvement from 10's of faults, and it's not clear
why that's the case.
Eric Nelson (3):
net: fec: remove QUIRK_HAS_RACC from i.mx25
net: fec: remove QUIRK_HAS_RACC from i.mx27
net: fec: align IP header in hardware
drivers/net/ethernet/freescale/fec_main.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/3] net: fec: remove QUIRK_HAS_RACC from i.mx27
From: Eric Nelson @ 2016-09-24 14:42 UTC (permalink / raw)
To: netdev
Cc: linux, andrew, fugang.duan, otavio, edumazet, troy.kisky, davem,
u.kleine-koenig, Eric Nelson
In-Reply-To: <1474728139-9335-1-git-send-email-eric@nelint.com>
According to the i.MX27 reference manual, this SoC does not have support
for the receive accelerator (RACC) register at offset 0x1C4.
http://cache.nxp.com/files/32bit/doc/ref_manual/MCIMX27RM.pdf
Signed-off-by: Eric Nelson <eric@nelint.com>
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d193406..0219e79 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -92,7 +92,7 @@ static struct platform_device_id fec_devtype[] = {
.driver_data = FEC_QUIRK_USE_GASKET,
}, {
.name = "imx27-fec",
- .driver_data = FEC_QUIRK_HAS_RACC,
+ .driver_data = 0,
}, {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME |
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] net: fec: align IP header in hardware
From: Eric Nelson @ 2016-09-24 14:42 UTC (permalink / raw)
To: netdev
Cc: linux, andrew, fugang.duan, otavio, edumazet, troy.kisky, davem,
u.kleine-koenig, Eric Nelson
In-Reply-To: <1474728139-9335-1-git-send-email-eric@nelint.com>
The FEC receive accelerator (RACC) supports shifting the data payload of
received packets by 16-bits, which aligns the payload (IP header) on a
4-byte boundary, which is, if not required, at least strongly suggested
by the Linux networking layer.
Without this patch, a huge number of alignment faults will be taken by the
IP stack, as seen in /proc/cpu/alignment:
~/$ cat /proc/cpu/alignment
User: 0
System: 72645 (inet_gro_receive+0x104/0x27c)
Skipped: 0
Half: 0
Word: 0
DWord: 0
Multi: 72645
User faults: 3 (fixup+warn)
This patch was suggested by Andrew Lunn in this message to linux-netdev:
http://marc.info/?l=linux-arm-kernel&m=147465452108384&w=2
and adapted from a patch by Russell King from 2014:
http://git.arm.linux.org.uk/cgit/linux-arm.git/commit/?id=70d8a8a
Signed-off-by: Eric Nelson <eric@nelint.com>
---
drivers/net/ethernet/freescale/fec_main.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 0219e79..1fa2d87 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -180,6 +180,7 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
/* FEC receive acceleration */
#define FEC_RACC_IPDIS (1 << 1)
#define FEC_RACC_PRODIS (1 << 2)
+#define FEC_RACC_SHIFT16 BIT(7)
#define FEC_RACC_OPTIONS (FEC_RACC_IPDIS | FEC_RACC_PRODIS)
/*
@@ -945,9 +946,11 @@ fec_restart(struct net_device *ndev)
#if !defined(CONFIG_M5272)
if (fep->quirks & FEC_QUIRK_HAS_RACC) {
- /* set RX checksum */
val = readl(fep->hwp + FEC_RACC);
+ /* align IP header */
+ val |= FEC_RACC_SHIFT16;
if (fep->csum_flags & FLAG_RX_CSUM_ENABLED)
+ /* set RX checksum */
val |= FEC_RACC_OPTIONS;
else
val &= ~FEC_RACC_OPTIONS;
@@ -1428,6 +1431,12 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
prefetch(skb->data - NET_IP_ALIGN);
skb_put(skb, pkt_len - 4);
data = skb->data;
+
+#if !defined(CONFIG_M5272)
+ if (fep->quirks & FEC_QUIRK_HAS_RACC)
+ data = skb_pull_inline(skb, 2);
+#endif
+
if (!is_copybreak && need_swap)
swap_buffer(data, pkt_len);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] net: fec: remove QUIRK_HAS_RACC from i.mx25
From: Eric Nelson @ 2016-09-24 14:42 UTC (permalink / raw)
To: netdev
Cc: linux, andrew, fugang.duan, otavio, edumazet, troy.kisky, davem,
u.kleine-koenig, Eric Nelson
In-Reply-To: <1474728139-9335-1-git-send-email-eric@nelint.com>
According to the i.MX25 reference manual, this SoC does not have support
for the receive accelerator (RACC) register at offset 0x1C4.
http://www.nxp.com/files/dsp/doc/ref_manual/IMX25RM.pdf
Signed-off-by: Eric Nelson <eric@nelint.com>
---
drivers/net/ethernet/freescale/fec_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index fb5c638..d193406 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -89,7 +89,7 @@ static struct platform_device_id fec_devtype[] = {
.driver_data = 0,
}, {
.name = "imx25-fec",
- .driver_data = FEC_QUIRK_USE_GASKET | FEC_QUIRK_HAS_RACC,
+ .driver_data = FEC_QUIRK_USE_GASKET,
}, {
.name = "imx27-fec",
.driver_data = FEC_QUIRK_HAS_RACC,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4/6] isdn/hisax: clean function declaration in hscx.c up
From: Sergei Shtylyov @ 2016-09-24 14:17 UTC (permalink / raw)
To: Baoyou Xie, isdn; +Cc: netdev, linux-kernel, arnd, xie.baoyou
In-Reply-To: <1474694662-7527-1-git-send-email-baoyou.xie@linaro.org>
Hello.
On 9/24/2016 8:24 AM, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/isdn/hisax/hscx.c:175:1: warning: no previous prototype for 'open_hscxstate' [-Wmissing-prototypes]
>
> In fact, this function is declared in
> drivers/isdn/hisax/elsa_ser.c, but should be
> declard in a header file, thus can be recognized in other file.
Declared.
> So this patch moves the declaration into drivers/isdn/hisax/hscx.h.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net v2] ip6_gre: fix flowi6_proto value in ip6gre_xmit_other()
From: David Miller @ 2016-09-24 13:45 UTC (permalink / raw)
To: lrichard; +Cc: netdev, shmulik.ladkani, jbenc
In-Reply-To: <1474660229-5665-1-git-send-email-lrichard@redhat.com>
From: Lance Richardson <lrichard@redhat.com>
Date: Fri, 23 Sep 2016 15:50:29 -0400
> Similar to commit 3be07244b733 ("ip6_gre: fix flowi6_proto value in
> xmit path"), set flowi6_proto to IPPROTO_GRE for output route lookup.
>
> Up until now, ip6gre_xmit_other() has set flowi6_proto to a bogus value.
> This affected output route lookup for packets sent on an ip6gretap device
> in cases where routing was dependent on the value of flowi6_proto.
>
> Since the correct proto is already set in the tunnel flowi6 template via
> commit 252f3f5a1189 ("ip6_gre: Set flowi6_proto as IPPROTO_GRE in xmit
> path."), simply delete the line setting the incorrect flowi6_proto value.
>
> Suggested-by: Jiri Benc <jbenc@redhat.com>
> Fixes: commit c12b395a4664 ("gre: Support GRE over IPv6")
> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> Signed-off-by: Lance Richardson <lrichard@redhat.com>
> ---
> v2: expanded commit description as suggested by Shmulik Ladkani.
Applied and queued up for -stable with Fixes tag fixes up.
Thanks.
^ permalink raw reply
* Re: [PATCH] hv_netvsc: fix comments
From: David Miller @ 2016-09-24 13:36 UTC (permalink / raw)
To: sthemmin, sthemmin; +Cc: kys, haiyangz, netdev
In-Reply-To: <1474675697-22805-1-git-send-email-sthemmin@exchange.microsoft.com>
From: sthemmin@exchange.microsoft.com
Date: Fri, 23 Sep 2016 17:08:17 -0700
> From: Stephen Hemminger <sthemmin@microsoft.com>
>
> Typo's and spelling errors. Also remove old comment from staging era.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied to net-next.
Please properly specify "[PATCH net-next]" or "[PATCH net]" in your
Subject lines in the future. Don't make me guess.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 0/2] BQL support and fix for a regression issue
From: David Miller @ 2016-09-24 12:47 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham
In-Reply-To: <1474621948-9172-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Fri, 23 Sep 2016 14:42:26 +0530
> From: Sunil Goutham <sgoutham@cavium.com>
>
> These patches add byte queue limit support and also fixes a regression
> issue introduced by commit
> 'net: thunderx: Use netdev's name for naming VF's interrupts'
>
> Changes from v1:
> - As suggested added 'Fixes' tag with commit id of previous commit
> which cuased issue.
> - Also fixed the missing netdev_tx_reset_queue() function call in
> byte queue limits support patch.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] cxgb4: fix -ve error check on a signed iq
From: David Miller @ 2016-09-24 12:31 UTC (permalink / raw)
To: colin.king; +Cc: hariprasad, netdev, linux-kernel
In-Reply-To: <20160923134513.21345-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 23 Sep 2016 14:45:13 +0100
> -static unsigned int get_filter_steerq(struct net_device *dev,
> +static int get_filter_steerq(struct net_device *dev,
> struct ch_filter_specification *fs)
If you change the location of the openning parenthesis of the first
line, you must reindent the second line so that the arguments are
placed preciely at the column following that openning parenthesis.
^ permalink raw reply
* Re: [PATCH] mlxsw: spectrum: remove redundant check if err is zero
From: David Miller @ 2016-09-24 12:28 UTC (permalink / raw)
To: colin.king; +Cc: jiri, idosch, netdev, linux-kernel
In-Reply-To: <20160923110245.18977-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 23 Sep 2016 12:02:45 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> There is an earlier check and return if err is non-zero, so
> the check to see if it is zero is redundant in every iteration
> of the loop and hence the check can be removed.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next.
^ permalink raw reply
* Re: Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-24 12:27 UTC (permalink / raw)
To: David Miller
Cc: edumazet, linux-arm-kernel, netdev, rmk+kernel, fugang.duan,
troy.kisky, otavio, cjb.sw.nospam
In-Reply-To: <20160923.224305.942077200829435690.davem@davemloft.net>
Hi David,
On 09/23/2016 07:43 PM, David Miller wrote:
> From: Eric Nelson <eric@nelint.com>
> Date: Fri, 23 Sep 2016 10:33:29 -0700
>
>> Since the hardware requires longword alignment for its' DMA transfers,
>> aligning the IP header will require a memcpy, right?
>
> I wish hardware designers didn't do this.
>
> There is no conflict between DMA alignment and properly offseting
> the packet data by two bytes.
>
> All hardware designers have to do is allow 2 padding bytes to be
> emitted by the chip before the actual packet data.
>
Andrew Lunn pointed out that the hardware does support this,
and I just pushed a patch for the vendor kernel to the meta-freescale
mailing list:
https://lists.yoctoproject.org/pipermail/meta-freescale/2016-September/019228.html
> Then the longword or whatever DMA transfer alignment is met
> whilst still giving the necessary flexibility for where the
> packet data lands.
>
Right. A relatively small change fixes things right up.
Many thanks to Andrew for pointing this out and Russell for providing
the basis for my patch.
I'll re-work this for the up-stream kernel when I get out from
under a couple of unrelated things.
^ permalink raw reply
* Re: [PATCH net-next] Documentation: devicetree: fix typo in MediaTek ethernet device-tree binding
From: David Miller @ 2016-09-24 12:26 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, nbd-p3rKhJxN3npAfugRpC6u6w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
objelf-Re5JQEeQqe8AvxtiuMwx3w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
john-Pj+rj9U5foFAfugRpC6u6w
In-Reply-To: <1474610972-14974-1-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Date: Fri, 23 Sep 2016 14:09:32 +0800
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> fix typo in
> Documentation/devicetree/bindings/net/mediatek-net.txt
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Reported-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] Documentation: devicetree: revise ethernet device-tree binding about TRGMII
From: David Miller @ 2016-09-24 12:26 UTC (permalink / raw)
To: sean.wang
Cc: sergei.shtylyov, nbd, netdev, linux-kernel, devicetree,
linux-mediatek, john, keyhaede, objelf
In-Reply-To: <1474610649-18582-1-git-send-email-sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Fri, 23 Sep 2016 14:04:09 +0800
> From: Sean Wang <sean.wang@mediatek.com>
>
> add phy-mode "trgmii" to
> Documentation/devicetree/bindings/net/ethernet.txt
>
> Cc: devicetree@vger.kernel.org
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 00/15] rxrpc: Bug fixes and tracepoints
From: David Miller @ 2016-09-24 12:24 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, linux-kernel
In-Reply-To: <147464371753.5090.1634919599283321856.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Fri, 23 Sep 2016 16:15:17 +0100
> Here are a bunch of bug fixes:
...
> Tagged thusly:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> rxrpc-rewrite-20160923
Pulled, thanks David.
^ permalink raw reply
* Re: [net-next 00/10][pull request] 10GbE Intel Wired LAN Driver Updates 2016-09-23
From: David Miller @ 2016-09-24 12:22 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1474617103-59530-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Sep 2016 00:51:33 -0700
> This series contains updates to ixgbe and ixgbevf.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2016-09-23
From: David Miller @ 2016-09-24 12:19 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1474614882-25253-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 23 Sep 2016 09:14:40 +0200
> Only two patches this time:
>
> 1) Fix a comment reference to struct xfrm_replay_state_esn.
> From Richard Guy Briggs.
>
> 2) Convert xfrm_state_lookup to rcu, we don't need the
> xfrm_state_lock anymore in the input path.
> From Florian Westphal.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: [net-next v2 00/10][pull request] 40GbE Intel Wired LAN Driver Updates 2016-09-22
From: David Miller @ 2016-09-24 12:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, guru.anbalagane
In-Reply-To: <1474609542-121940-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 22 Sep 2016 22:45:32 -0700
> This series contains updates to i40e and i40evf only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next V3 0/5] mlx4 VF vlan protocol 802.1ad support
From: David Miller @ 2016-09-24 12:11 UTC (permalink / raw)
To: tariqt
Cc: netdev, eranbe, moshe, ogerlitz, john.fastabend, ariel.elior,
sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
jeffrey.t.kirsher, saeedm, Yuval.Mintz, Dept-GELinuxNICDev,
linux-net-drivers, ecree, bkenward
In-Reply-To: <1474535476-10662-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Thu, 22 Sep 2016 12:11:11 +0300
> This patchset adds VF VLAN protocol 802.1ad support to the
> mlx4 driver.
> We extended the VF VLAN API with an additional parameter
> for VLAN protocol, and kept 802.1Q as drivers' default.
>
> We prepared a userspace support (ip link tool).
> The patch will be submitted to the iproute2 mailing list.
>
> The ip link tool VF VLAN protocol parameter is optional (default: 802.1Q).
> A configuration command of VF VLAN that is used prior to this patchset
> will result in same functionality as today's (VST with VLAN protocol 802.1Q).
>
> The series generated against net-next commit:
> 688dc5369a63 "Merge branch 'mlx4-next'"
>
> All maintainers of the modified modules are in cc.
Series applied, thanks.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net-next v2 1/2] i40e: remove superfluous I40E_DEBUG_USER statement
From: Stefan Assmann @ 2016-09-24 11:13 UTC (permalink / raw)
To: Alexander Duyck, David Miller; +Cc: intel-wired-lan, Netdev
In-Reply-To: <CAKgT0UfxYzn1uqHLU+=7V4=NnYQX8rxLosxLg4Orsg_qEpGTKw@mail.gmail.com>
On 24.09.2016 04:48, Alexander Duyck wrote:
> On Fri, Sep 23, 2016 at 6:30 AM, Stefan Assmann <sassmann@kpanic.de> wrote:
>> This debug statement is confusing and never set in the code. Any debug
>> output should be guarded by the proper I40E_DEBUG_* statement which can
>> be enabled via the debug module parameter or ethtool.
>> Remove or convert the I40E_DEBUG_USER cases to I40E_DEBUG_INIT.
>>
>> v2: re-add setting the debug_mask in i40e_set_msglevel() so that the
>> debug level can still be altered via ethtool msglvl.
>>
>> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
>> ---
>> drivers/net/ethernet/intel/i40e/i40e_common.c | 3 ---
>> drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 6 -----
>> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 +--
>> drivers/net/ethernet/intel/i40e/i40e_main.c | 35 +++++++++++++-------------
>> drivers/net/ethernet/intel/i40e/i40e_type.h | 2 --
>> 5 files changed, 18 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/net/ethernet/intel/i40e/i40e_common.c
>> index 2154a34..8ccb09c 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_common.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
>> @@ -3207,9 +3207,6 @@ static void i40e_parse_discover_capabilities(struct i40e_hw *hw, void *buff,
>> break;
>> case I40E_AQ_CAP_ID_MSIX:
>> p->num_msix_vectors = number;
>> - i40e_debug(hw, I40E_DEBUG_INIT,
>> - "HW Capability: MSIX vector count = %d\n",
>> - p->num_msix_vectors);
>> break;
>> case I40E_AQ_CAP_ID_VF_MSIX:
>> p->num_msix_vectors_vf = number;
>
> I'm assuming this is dropped because you considered it redundant with
> the dump in i40e_get_capabilities. If so it would have been nice to
> see this called out in your patch description somewhere as it doesn't
> jive with the rest of the patch since you are stripping something that
> is using I40E_DEBUG_INIT.
Hi Alex,
agreed, it seemed redundant. I'll make a note about it in the next
version when we have decided how to proceed.
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>> index 05cf9a7..e9c6f1c 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
>> @@ -1210,12 +1210,6 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
>> u32 level;
>> cnt = sscanf(&cmd_buf[10], "%i", &level);
>> if (cnt) {
>> - if (I40E_DEBUG_USER & level) {
>> - pf->hw.debug_mask = level;
>> - dev_info(&pf->pdev->dev,
>> - "set hw.debug_mask = 0x%08x\n",
>> - pf->hw.debug_mask);
>> - }
>> pf->msg_enable = level;
>> dev_info(&pf->pdev->dev, "set msg_enable = 0x%08x\n",
>> pf->msg_enable);
>
> From what I can tell the interface is completely redundant as ethtool
> can already do this. I'd say it is okay to just remove this command
> and section entirely from the debugfs interface.
Yes, I didn't want to stray too far from what the description said and
just removed the I40E_DEBUG_USER related code.
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
>> index 1835186..02f55ab 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
>> @@ -987,8 +987,7 @@ static void i40e_set_msglevel(struct net_device *netdev, u32 data)
>> struct i40e_netdev_priv *np = netdev_priv(netdev);
>> struct i40e_pf *pf = np->vsi->back;
>>
>> - if (I40E_DEBUG_USER & data)
>> - pf->hw.debug_mask = data;
>> + pf->hw.debug_mask = data;
>> pf->msg_enable = data;
>> }
>>
>
> So the way I view this is that I40E_DEBUG_USER appears to be a flag
> that is being used to differentiate between some proprietary flags and
> the standard msg level. The problem is that msg_enable and debug_mask
> are playing off of two completely different bit definitions. For
> example how much sense does it make for NETIF_F_MSG_TX_DONE to map to
> I40E_DEBUG_DCB. If anything what should probably happen here is
> instead of dropping the if there probably needs to be an else.
As you said the flags don't match, which is part of the problem. What
tipped me of starting to work on this is, that the debug module
parameter doesn't do a thing atm and I had to debug some stuff during
driver MSI-X initialization. So my main pain point here is to get the
debug parameter in a sane state.
> This is one of many things on my list of items to fix since I have
> come back to Intel. It is just a matter of finding the time.
> Basically what I would really prefer to see here is us move all of the
> flags in i40e_debug_mask so that we didn't have any overlap with the
> NETIF_F_MSG_* flags unless there is a relation between the two.
That sounds like a good idea and I'm happy to join in. So for now, I
could drop the I40E_DEBUG_USER changes and just focus on making the
debug parameter usable. All the non-standard debug output could be
handled by I40E_DEBUG_USER or whatever better name we could for the
flag. The current name doesn't really explain what it's meant for.
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> index 61b0fc4..56369761 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> @@ -6665,16 +6665,19 @@ static int i40e_get_capabilities(struct i40e_pf *pf)
>> }
>> } while (err);
>>
>> - if (pf->hw.debug_mask & I40E_DEBUG_USER)
>> - dev_info(&pf->pdev->dev,
>> - "pf=%d, num_vfs=%d, msix_pf=%d, msix_vf=%d, fd_g=%d, fd_b=%d, pf_max_q=%d num_vsi=%d\n",
>> - pf->hw.pf_id, pf->hw.func_caps.num_vfs,
>> - pf->hw.func_caps.num_msix_vectors,
>> - pf->hw.func_caps.num_msix_vectors_vf,
>> - pf->hw.func_caps.fd_filters_guaranteed,
>> - pf->hw.func_caps.fd_filters_best_effort,
>> - pf->hw.func_caps.num_tx_qp,
>> - pf->hw.func_caps.num_vsis);
>> + i40e_debug(&pf->hw, I40E_DEBUG_INIT,
>> + "HW Capabilities: PF-id[%d] num_vfs=%d, msix_pf=%d, msix_vf=%d\n",
>> + pf->hw.pf_id,
>> + pf->hw.func_caps.num_vfs,
>> + pf->hw.func_caps.num_msix_vectors,
>> + pf->hw.func_caps.num_msix_vectors_vf);
>> + i40e_debug(&pf->hw, I40E_DEBUG_INIT,
>> + "HW Capabilities: PF-id[%d] fd_g=%d, fd_b=%d, pf_max_qp=%d num_vsis=%d\n",
>> + pf->hw.pf_id,
>> + pf->hw.func_caps.fd_filters_guaranteed,
>> + pf->hw.func_caps.fd_filters_best_effort,
>> + pf->hw.func_caps.num_tx_qp,
>> + pf->hw.func_caps.num_vsis);
>>
>> #define DEF_NUM_VSI (1 + (pf->hw.func_caps.fcoe ? 1 : 0) \
>> + pf->hw.func_caps.num_vfs)
>
> I'd say don't bother with this. There isn't any point.
OK, I thought the same thing but wasn't sure if anybody relies on this
info.
>> @@ -8495,14 +8498,10 @@ static int i40e_sw_init(struct i40e_pf *pf)
>> int err = 0;
>> int size;
>>
>> - pf->msg_enable = netif_msg_init(I40E_DEFAULT_MSG_ENABLE,
>> - (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK));
>> - if (debug != -1 && debug != I40E_DEFAULT_MSG_ENABLE) {
>> - if (I40E_DEBUG_USER & debug)
>> - pf->hw.debug_mask = debug;
>> - pf->msg_enable = netif_msg_init((debug & ~I40E_DEBUG_USER),
>> - I40E_DEFAULT_MSG_ENABLE);
>> - }
>> + pf->msg_enable = netif_msg_init(debug,
>> + NETIF_MSG_DRV |
>> + NETIF_MSG_PROBE |
>> + NETIF_MSG_LINK);
>>
>> /* Set default capability flags */
>> pf->flags = I40E_FLAG_RX_CSUM_ENABLED |
>
> Okay so I think I now see why there is confusion about how debug is
> used. The documentation in the driver is wrong for how it worked. It
> wasn't being passed as a 0-16, somebody implemented this as a 32 bit
> bitmask. So the question becomes how to fix it. The problem is with
> the patch as it is so far we end up with pf->msg_enable being
> populated but pf->hw.debug_mask never being populated. The values you
> are passing as the default don't make any sense either since they
> don't really map to the same functionality in I40e. They map to
> DEBUG_INIT, DEBUG_RELEASE, and an unused bit.
>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h
>> index bd5f13b..7e88e35 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_type.h
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
>> @@ -85,8 +85,6 @@ enum i40e_debug_mask {
>> I40E_DEBUG_AQ_COMMAND = 0x06000000,
>> I40E_DEBUG_AQ = 0x0F000000,
>>
>> - I40E_DEBUG_USER = 0xF0000000,
>> -
>> I40E_DEBUG_ALL = 0xFFFFFFFF
>> };
>>
>
> This end piece is where the problem really lies. The problem
> statement for this would essentially be that the i40e driver uses the
> debug module parameter in a non-standard way. It is using a tg3 style
> bitmask to populate the fields, but then documenting it and coding
> part of it like it is expecting the default debug usage. To top it
> off it is doing the same kind of nonsense with the ethtool msg level
> interface.
>
> The one piece we probably need with all this in order to really "fix"
> the issue and still maintain some sense of functionality would be to
> look at adding something that would populate pf->hw.debug_mask. I'm
> half tempted to say that we could try adding another module parameter
> named i40e_debug that we could use like tg3 does with tg3_debug and
> change the debugfs interface to only modify that instead of messing
> with the msg level, but the fact is that would probably just be more
> confusing. For now what I would suggest doing is just splitting
> msg_enable and pf->hw.debug_mask and for now just default the value of
> pf->hw.debug_mask to I40E_DEFAULT_MSG_ENABLE. That way in a week or
> two after netdev/netconf we will hopefully had a chance to hash this
> all out and can find a better way to solve this.
I really appreciate your feedback. What you're suggesting makes sense.
Let's split the generic (msg_enable) debug information provided by the
debug parameter from driver specific debug information. Not sure I'd
like to see another module parameter, but that doesn't have to be
decided right away.
If you agree, I'll rewrite the patches to make a clear separation
between debug_mask and msg_enable, making the debug parameter actually
usable.
And we'll sort out the rest along the way.
Stefan
^ 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