* Re: [PATCH v2 net-next 0/2] net: rename device's sysfs symlinks on name change
From: David Miller @ 2014-01-15 23:17 UTC (permalink / raw)
To: vfalico; +Cc: netdev, dingtianhong, edumazet, nicolas.dichtel, amwang
In-Reply-To: <1389733131-15390-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 14 Jan 2014 21:58:49 +0100
> First patch only adds helper functions and cleans up the code a bit, second
> one already does the renaming.
>
> v1->v2:
> Don't export the function, as it's used only in dev.c.
>
> Reported-by: Ding Tianhong <dingtianhong@huawei.com>
> CC: Ding Tianhong <dingtianhong@huawei.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Eric Dumazet <edumazet@google.com>
> CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> CC: Cong Wang <amwang@redhat.com>
> CC: netdev@vger.kernel.org
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Series applied, thanks Vaeceslav.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_core: Warn if device doesn't have enough PCI bandwidth
From: Keller, Jacob E @ 2014-01-15 23:15 UTC (permalink / raw)
To: Ben Hutchings
Cc: Amir Vadai, Kirsher, Jeffrey T, Bjorn Helgaas, David S. Miller,
netdev@vger.kernel.org, Or Gerlitz, Eyal Perry,
Skidmore, Donald C
In-Reply-To: <1389042955.9947.110.camel@bwh-desktop.uk.level5networks.com>
On Mon, 2014-01-06 at 21:15 +0000, Ben Hutchings wrote:
> On Sat, 2014-01-04 at 21:17 +0200, Amir Vadai wrote:
> > From: Eyal Perry <eyalpe@mellanox.com>
> >
> > Check if the device get enough bandwidth from the entire PCI chain to satisfy
> > its capabilities. This patch determines the PCIe device's bandwidth capabilities
> > by reading its PCIe Link Capabilities registers and then call the
> > pcie_get_minimum_link function to ensure that the adapter is hooked into a slot
> > which is capable of providing the necessary bandwidth capabilities.
> [...]
>
> This is essentially another duplicate of what ixgbe and i40e are
> doing... (And the out-of-tree version of sfc does it too, but I never
> felt that was ready for in-tree.)
>
> We ought to have a generic PCI layer function that warns when a PCIe
> device is running below maximum link width/speed. Maybe even run it as
> soon as the device is enumerated, so that a driver doesn't need to do
> anything.
>
> Ben.
>
Hi,
I was thinking about this again, was wondering a few things. Is this
something you were already investigating?
On an implementation note, how would this function know how much
bandwidth a particular device (or function?) would require? I'm thinking
of something along the lines of a driver essentially saying how much the
devices it supports require?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v2 net-next] stmmac: Add vlan rx for better GRO performance.
From: David Miller @ 2014-01-15 23:13 UTC (permalink / raw)
To: vbridgers2013; +Cc: netdev, peppe.cavallaro, rayagond
In-Reply-To: <1389728525-6989-1-git-send-email-vbridgers2013@gmail.com>
From: Vince Bridgers <vbridgers2013@gmail.com>
Date: Tue, 14 Jan 2014 13:42:05 -0600
> GRO requires VLANs to be removed before aggregation can occur.
> The Synopsys EMAC does not strip VLAN tags so this must be
> done by the driver.
>
> Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
> ---
> V2: remove inline on added function, line up broken lines per review comments
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] net/mlx4_core: clean up cq_res_start_move_to()
From: David Miller @ 2014-01-15 23:12 UTC (permalink / raw)
To: pebolle; +Cc: ogerlitz, jackm, ronye, hadarh, netdev, linux-kernel
In-Reply-To: <1389728736.28068.8.camel@x220>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Tue, 14 Jan 2014 20:45:36 +0100
> Building resource_tracker.o triggers a GCC warning:
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_HW2SW_CQ_wrapper':
> drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3019:16: warning: 'cq' may be used uninitialized in this function [-Wmaybe-uninitialized]
> atomic_dec(&cq->mtt->ref_count);
> ^
>
> This is a false positive. But a cleanup of cq_res_start_move_to() can
> help GCC here. The code currently uses a switch statement where an
> if/else construct would do too, since only two of the switch's four
> cases can ever occur. Dropping that switch makes the warning go away.
>
> While we're at it, add some missing braces.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> v2: adjust to Jack's review.
Can I please get some review of these two patches, thank you.
^ permalink raw reply
* [PATCH] batman-adv: fix batman-adv header overhead calculation
From: Antonio Quartulli @ 2014-01-15 23:10 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Marek Lindner, Antonio Quartulli
In-Reply-To: <1389827444-3911-1-git-send-email-antonio@meshcoding.com>
From: Marek Lindner <mareklindner@neomailbox.ch>
Batman-adv prepends a full ethernet header in addition to its own
header. This has to be reflected in the MTU calculation, especially
since the value is used to set dev->hard_header_len.
Introduced by 411d6ed93a5d0601980d3e5ce75de07c98e3a7de
("batman-adv: consider network coding overhead when calculating required mtu")
Reported-by: cmsv <cmsv@wirelesspt.net>
Reported-by: Martin Hundebøll <martin@hundeboll.net>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index 1511f64..faba0f6 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -277,7 +277,7 @@ int batadv_max_header_len(void)
sizeof(struct batadv_coded_packet));
#endif
- return header_len;
+ return header_len + ETH_HLEN;
}
/**
--
1.8.5.3
^ permalink raw reply related
* pull request [net]: batman-adv 2014-01-16
From: Antonio Quartulli @ 2014-01-15 23:10 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
here you have a very small fix intended for net/linux-3.13.
This patch is fixing the batman-adv overhead computation
(by Marek Lindner).
The result of such operation is used to initialize the
hard_header_len member of the soft-interface netdev object.
Please pull or let me know of any problem!
Thanks a lot,
Antonio
The following changes since commit 51bb352f15595f2dee42b599680809de3d08999d:
qlge: Fix vlan netdev features. (2014-01-14 19:02:35 -0800)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 1df0cbd509bc21b0c331358c1f9d9a6fc94bada8:
batman-adv: fix batman-adv header overhead calculation (2014-01-15 23:54:20 +0100)
----------------------------------------------------------------
Included change:
- properly compute the batman-adv header overhead. Such
result is later used to initialize the hard_header_len
member of the soft-interface netdev object
----------------------------------------------------------------
Marek Lindner (1):
batman-adv: fix batman-adv header overhead calculation
net/batman-adv/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: fix sparse warning
From: David Miller @ 2014-01-15 23:07 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20140114101411.0ac2452e@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 14 Jan 2014 10:14:11 -0800
> Fix new sparse warning about function declared static.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks Stephen.
^ permalink raw reply
* [PATCH net-next 2/2] team: block mtu change before it happens via NETDEV_PRECHANGEMTU
From: Veaceslav Falico @ 2014-01-15 23:02 UTC (permalink / raw)
To: netdev; +Cc: Veaceslav Falico, Jiri Pirko
In-Reply-To: <1389826939-20691-1-git-send-email-vfalico@redhat.com>
Now it catches the NETDEV_CHANGEMTU notification, which is signaled after
the actual change happened on the device, and returns NOTIFY_BAD, so that
the change on the device is reverted.
This might be quite costly and messy, so use the new NETDEV_PRECHANGEMTU to
catch the MTU change before the actual change happens and signal that it's
forbidden to do it.
CC: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/team/team.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index b75ae5b..dff24e3 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2851,7 +2851,7 @@ static int team_device_event(struct notifier_block *unused,
case NETDEV_FEAT_CHANGE:
team_compute_features(port->team);
break;
- case NETDEV_CHANGEMTU:
+ case NETDEV_PRECHANGEMTU:
/* Forbid to change mtu of underlaying device */
return NOTIFY_BAD;
case NETDEV_PRE_TYPE_CHANGE:
--
1.8.4
^ permalink raw reply related
* [PATCH net-next 1/2] net: add NETDEV_PRECHANGEMTU to notify before mtu change happens
From: Veaceslav Falico @ 2014-01-15 23:02 UTC (permalink / raw)
To: netdev
Cc: Veaceslav Falico, David S. Miller, Jiri Pirko, Eric Dumazet,
Nicolas Dichtel, Cong Wang
Currently, if a device changes its mtu, first the change happens (invloving
all the side effects), and after that the NETDEV_CHANGEMTU is sent so that
other devices can catch up with the new mtu. However, if they return
NOTIFY_BAD, then the change is reverted and error returned.
This is a really long and costy operation (sometimes). To fix this, add
NETDEV_PRECHANGEMTU notification which is called prior to any change
actually happening, and if any callee returns NOTIFY_BAD - the change is
aborted. This way we're skipping all the playing with apply/revert the mtu.
CC: "David S. Miller" <davem@davemloft.net>
CC: Jiri Pirko <jiri@resnulli.us>
CC: Eric Dumazet <edumazet@google.com>
CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
CC: Cong Wang <amwang@redhat.com>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
include/linux/netdevice.h | 3 ++-
net/core/dev.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5c88ab1..6fa2c91 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1718,7 +1718,7 @@ struct pcpu_sw_netstats {
#define NETDEV_CHANGE 0x0004 /* Notify device state change */
#define NETDEV_REGISTER 0x0005
#define NETDEV_UNREGISTER 0x0006
-#define NETDEV_CHANGEMTU 0x0007
+#define NETDEV_CHANGEMTU 0x0007 /* notify after mtu change happened */
#define NETDEV_CHANGEADDR 0x0008
#define NETDEV_GOING_DOWN 0x0009
#define NETDEV_CHANGENAME 0x000A
@@ -1734,6 +1734,7 @@ struct pcpu_sw_netstats {
#define NETDEV_JOIN 0x0014
#define NETDEV_CHANGEUPPER 0x0015
#define NETDEV_RESEND_IGMP 0x0016
+#define NETDEV_PRECHANGEMTU 0x0017 /* notify before mtu change happened */
int register_netdevice_notifier(struct notifier_block *nb);
int unregister_netdevice_notifier(struct notifier_block *nb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 20c834e..cb78923 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5360,6 +5360,11 @@ int dev_set_mtu(struct net_device *dev, int new_mtu)
if (!netif_device_present(dev))
return -ENODEV;
+ err = call_netdevice_notifiers(NETDEV_PRECHANGEMTU, dev);
+ err = notifier_to_errno(err);
+ if (err)
+ return err;
+
orig_mtu = dev->mtu;
err = __dev_set_mtu(dev, new_mtu);
--
1.8.4
^ permalink raw reply related
* Re: [PATCH net-next v3 2/2] stmmac: Fix kernel crashes for jumbo frames
From: David Miller @ 2014-01-15 22:57 UTC (permalink / raw)
To: vbridgers2013
Cc: bhutchings, devicetree, netdev, peppe.cavallaro, robh+dt,
pawel.moll, mark.rutland, ijc+devicetree, galak, dinguyen,
rayagond
In-Reply-To: <CAOwfj2Ne1oRU1z6BaH4g2_EJJFtJOWbgs2oMzSq5nNpz9G6LsA@mail.gmail.com>
From: Vince Bridgers <vbridgers2013@gmail.com>
Date: Tue, 14 Jan 2014 14:44:35 -0600
> On Tue, Jan 14, 2014 at 1:53 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
>> On Tue, 2014-01-14 at 11:17 -0600, Vince Bridgers wrote:
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>>> @@ -51,6 +51,10 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
>>> plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
>>> sizeof(struct stmmac_mdio_bus_data),
>>> GFP_KERNEL);
>>> + /* Set the maxmtu to a default of 1500 in case the
>>> + * parameter is not present in the device tree
>>> + */
>>> + plat->maxmtu = JUMBO_LEN;
>>
>> The comment disagrees with the definition of JUMBO_LEN.
>
> ok, I'll address the comment inconsistency.
Therefore I'm expecting to see a v4 of this series at some point,
thanks.
^ permalink raw reply
* Re: [PATCH] [trivial] ixgbe: Fix format string in ixgbe_fcoe.c
From: David Miller @ 2014-01-15 22:55 UTC (permalink / raw)
To: standby24x7
Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan, e1000-devel,
netdev, linux-kernel, trivial
In-Reply-To: <1389716082-23395-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Wed, 15 Jan 2014 01:14:42 +0900
> cppcheck detected following warning in ixgbe_fcoe.c
> (warning) %d in format string (no. 1) requires 'int' but the
> argument type is 'unsigned int'.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Intel folks, please be sure to pick this up.
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: Pad OVS_PACKET_ATTR_PACKET if linear copy was performed
From: Jesse Gross @ 2014-01-15 22:53 UTC (permalink / raw)
To: David Miller
Cc: Thomas Graf, Zoltan Kiss, Thomas Graf, dev@openvswitch.org,
netdev
In-Reply-To: <20140114.190354.1862604735799307127.davem@davemloft.net>
On Tue, Jan 14, 2014 at 7:03 PM, David Miller <davem@davemloft.net> wrote:
> From: Thomas Graf <tgraf@suug.ch>
> Date: Tue, 14 Jan 2014 16:27:49 +0000
>
>> While the zerocopy method is correctly omitted if user space
>> does not support unaligned Netlink messages. The attribute is
>> still not padded correctly as skb_zerocopy() will not ensure
>> padding and the attribute size is no longer pre calculated
>> though nla_reserve() which ensured padding previously.
>>
>> This patch applies appropriate padding if a linear data copy
>> was performed in skb_zerocopy().
>>
>> Signed-off-by: Thomas Graf <tgraf@suug.ch>
>> ---
>> v2: initialize padding to 0's
>
> Jesse do you want to queue this up or should I apply it directly?
I queued it up, thanks.
^ permalink raw reply
* Re: [PATCH 1/7] ptp_pch: Add dependency on HAS_IOMEM
From: David Miller @ 2014-01-15 22:51 UTC (permalink / raw)
To: richard
Cc: marex, lars, driverdev-devel, linux-iio, lidza.louina,
richardcochran, anton, linux-kernel, kishon, netdev, acourbot,
gregkh, devel, dwmw2, florian, jic23, sebastian.hesselbarth
In-Reply-To: <1389714345-20165-1-git-send-email-richard@nod.at>
All 7 patches applied, thank you.
^ permalink raw reply
* Re: [PATCH V2 net-next 3/3] ipv6: add ip6_flowlabel_consistency sysctl
From: Hannes Frederic Sowa @ 2014-01-15 22:49 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1389785403-6401-3-git-send-email-florent.fourcot@enst-bretagne.fr>
On Wed, Jan 15, 2014 at 12:30:03PM +0100, Florent Fourcot wrote:
> With the introduction of IPV6_FL_F_REFLECT, there is no guarantee of
> flow label unicity. This patch introduces a new sysctl to protect the old
> behaviour, enable by default.
>
> Changelog of the V2:
> * Remove useless hunk in sysctl_binary.c
> * Rebase on net-next
Seems still to generate conflicts on my branch. :/
The conflicts are simple to clean up, but if you decide to rebase, please
check the patches with ./scripts/checkpatch --strict and eliminate all those
small nitpicks.
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
> ---
> Documentation/networking/ip-sysctl.txt | 8 ++++++++
> include/net/netns/ipv6.h | 1 +
> net/ipv6/af_inet6.c | 1 +
> net/ipv6/ip6_flowlabel.c | 7 +++++++
> net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
> 5 files changed, 25 insertions(+)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index c97932c..7453640 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1118,6 +1118,14 @@ bindv6only - BOOLEAN
>
> Default: FALSE (as specified in RFC3493)
>
> +ip6_flowlabel_consistency - BOOLEAN
> + Protect the consistency (and unicity) of flow label.
> + You have to disable it to use IPV6_FL_F_REFLECT flag on the
> + flow label manager.
> + TRUE: enabled
> + FALSE: disabled
> + Default: TRUE
> +
> anycast_src_echo_reply - BOOLEAN
> Controls the use of anycast addresses as source addresses for ICMPv6
> echo reply
> diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
> index 76fc7d1..3cc291b 100644
> --- a/include/net/netns/ipv6.h
> +++ b/include/net/netns/ipv6.h
> @@ -27,6 +27,7 @@ struct netns_sysctl_ipv6 {
> int ip6_rt_gc_elasticity;
> int ip6_rt_mtu_expires;
> int ip6_rt_min_advmss;
> + int ip6_flowlabel_consistency;
> int icmpv6_time;
> };
>
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index c921d5d..943c796 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -775,6 +775,7 @@ static int __net_init inet6_net_init(struct net *net)
>
> net->ipv6.sysctl.bindv6only = 0;
> net->ipv6.sysctl.icmpv6_time = 1*HZ;
> + net->ipv6.sysctl.ip6_flowlabel_consistency = 1;
> atomic_set(&net->ipv6.rt_genid, 0);
>
> err = ipv6_init_mibs(net);
> diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
> index 2c0f9dc..85f0453 100644
> --- a/net/ipv6/ip6_flowlabel.c
> +++ b/net/ipv6/ip6_flowlabel.c
> @@ -587,8 +587,15 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
>
> case IPV6_FL_A_GET:
> if (freq.flr_flags & IPV6_FL_F_REFLECT) {
> + struct net *net = sock_net(sk);
> + if (net->ipv6.sysctl.ip6_flowlabel_consistency) {
> + pr_info("Can not set IPV6_FL_F_REFLECT if ip6_flowlabel_consistency sysctl is enable \n");
Maybe we should do rate-limiting here, so a user cannot spam kmsg.
> + return -EPERM;
> + }
> +
> if (sk->sk_protocol != IPPROTO_TCP)
> return -ENOPROTOOPT;
> +
> np->repflow = 1;
> return 0;
> }
> diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
> index 6b6a2c8..8c99cf0 100644
> --- a/net/ipv6/sysctl_net_ipv6.c
> +++ b/net/ipv6/sysctl_net_ipv6.c
> @@ -31,6 +31,13 @@ static struct ctl_table ipv6_table_template[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec
> },
> + {
> + .procname = "ip6_flowlabel_consistency",
> + .data = &init_net.ipv6.sysctl.ip6_flowlabel_consistency,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec
> + },
> { }
> };
>
> @@ -59,6 +66,7 @@ static int __net_init ipv6_sysctl_net_init(struct net *net)
> goto out;
> ipv6_table[0].data = &net->ipv6.sysctl.bindv6only;
> ipv6_table[1].data = &net->ipv6.anycast_src_echo_reply;
> + ipv6_table[2].data = &net->ipv6.sysctl.ip6_flowlabel_consistency;
>
> ipv6_route_table = ipv6_route_sysctl_init(net);
> if (!ipv6_route_table)
^ permalink raw reply
* Re: [patch 0/3] s390: network patches for net-next
From: David Miller @ 2014-01-15 22:48 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20140114145410.453840919@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Tue, 14 Jan 2014 15:54:10 +0100
> here are some s390 related patches for net-next
Series applied, thanks Frank.
^ permalink raw reply
* Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Hannes Frederic Sowa @ 2014-01-15 22:47 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1389785403-6401-1-git-send-email-florent.fourcot@enst-bretagne.fr>
On Wed, Jan 15, 2014 at 12:30:01PM +0100, Florent Fourcot wrote:
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index ffd5fa8..f61bedc 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -483,6 +483,8 @@ static int tcp_v6_send_synack(struct sock *sk, struct dst_entry *dst,
> &ireq->ir_v6_rmt_addr);
>
> fl6->daddr = ireq->ir_v6_rmt_addr;
> + if (np->repflow)
> + fl6->flowlabel = np->flow_label;
> skb_set_queue_mapping(skb, queue_mapping);
> err = ip6_xmit(sk, skb, fl6, np->opt, np->tclass);
> err = net_xmit_eval(err);
> @@ -1000,6 +1002,8 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
> ireq = inet_rsk(req);
> ireq->ir_v6_rmt_addr = ipv6_hdr(skb)->saddr;
> ireq->ir_v6_loc_addr = ipv6_hdr(skb)->daddr;
> + if (np->repflow)
> + np->flow_label = ip6_flowlabel(ipv6_hdr(skb));
> if (!want_cookie || tmp_opt.tstamp_ok)
> TCP_ECN_create_request(req, skb, sock_net(sk));
>
> @@ -1138,6 +1142,8 @@ static struct sock *tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
> newnp->mcast_oif = inet6_iif(skb);
> newnp->mcast_hops = ipv6_hdr(skb)->hop_limit;
> newnp->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(skb));
> + if (np->repflow)
> + newnp->flow_label = ip6_flowlabel(ipv6_hdr(skb));
Just asking:
Was there a specific reason you did not use np->flow_label here and just
mirroring the flowlabel from the first packet of the connection for the
whole connection?
I don't know if it makes a difference, but maybe it was done on purpose?
Otherwise looks good.
> /*
> * No need to charge this sock to the relevant IPv6 refcnt debug socks count
> @@ -1218,6 +1224,8 @@ static struct sock *tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
> newnp->mcast_oif = inet6_iif(skb);
> newnp->mcast_hops = ipv6_hdr(skb)->hop_limit;
> newnp->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(skb));
> + if (np->repflow)
> + newnp->flow_label = ip6_flowlabel(ipv6_hdr(skb));
>
> /* Clone native IPv6 options from listening socket (if any)
>
> @@ -1429,6 +1437,8 @@ ipv6_pktoptions:
> np->mcast_hops = ipv6_hdr(opt_skb)->hop_limit;
> if (np->rxopt.bits.rxflow || np->rxopt.bits.rxtclass)
> np->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(opt_skb));
> + if (np->repflow)
> + np->flow_label = ip6_flowlabel(ipv6_hdr(opt_skb));
> if (ipv6_opt_accepted(sk, opt_skb)) {
> skb_set_owner_r(opt_skb, sk);
> opt_skb = xchg(&np->pktoptions, opt_skb);
> --
> 1.8.5.2
^ permalink raw reply
* Re: [patch net-next] neigh: split lines for NEIGH_VAR_SET so they are not too long
From: David Miller @ 2014-01-15 22:46 UTC (permalink / raw)
To: jiri; +Cc: netdev
In-Reply-To: <1389710767-2727-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 14 Jan 2014 15:46:07 +0100
> introduced by:
> commit 1f9248e5606afc6485255e38ad57bdac08fa7711
> "neigh: convert parms to an array"
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied, thanks a lot Jiri.
^ permalink raw reply
* Re: [PATCH v4 net-next 2/4] sh_eth: Add support for r7s72100
From: Sergei Shtylyov @ 2014-01-15 22:43 UTC (permalink / raw)
To: Simon Horman
Cc: David S. Miller, netdev, linux-sh, linux-arm-kernel, Magnus Damm
In-Reply-To: <20140109050351.GE2132@verge.net.au>
Hello.
On 01/09/2014 08:03 AM, Simon Horman wrote:
>>> This is a fast ethernet controller.
>>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> [...]
>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
>>> index 4b38533..cc6d4af 100644
>>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
>>> @@ -190,6 +190,59 @@ static const u16 sh_eth_offset_fast_rcar[SH_ETH_MAX_REGISTER_OFFSET] = {
[...]
>>> @@ -701,6 +762,35 @@ static struct sh_eth_cpu_data r8a7740_data = {
>>> .shift_rd0 = 1,
>>> };
>>>
>>> +/* R7S72100 */
>>> +static struct sh_eth_cpu_data r7s72100_data = {
>>> + .chip_reset = sh_eth_chip_reset,
>>> + .set_duplex = sh_eth_set_duplex,
>>> +
>>> + .register_type = SH_ETH_REG_FAST_RZ,
>>> +
>>> + .ecsr_value = ECSR_ICD,
>>> + .ecsipr_value = ECSIPR_ICDIP,
>>> + .eesipr_value = 0xff7f009f,
>>> +
>>> + .tx_check = EESR_TC1 | EESR_FTC,
>>> + .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
>>> + EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
>>> + EESR_TDE | EESR_ECI,
>>> + .fdr_value = 0x0000070f,
>>> + .rmcr_value = RMCR_RNC,
>>> +
>>> + .apr = 1,
>>> + .mpr = 1,
>>> + .tpauser = 1,
>>> + .hw_swap = 1,
>>> + .rpadir = 1,
>>> + .rpadir_value = 2 << 16,
>>> + .no_trimd = 1,
>>> + .tsu = 1,
>>> + .shift_rd0 = 1,
>> Perhaps this field should be renamed to something talking about
>> check summing support (since bits 0..15 of RD0 contain a frame check
>> sum for those SoCs). Or maybe it should be just merged with the
>> 'hw_crc' field...
> I have no feelings about that one way or another.
Do you happen to have R8A7740 manual by chance? If so, does it talk about
RX check summing support and using RD0 for that?
> But it seems to be orthogonal to this patch.
Of course, was a note to self. :-)
[...]
>>> @@ -880,6 +970,8 @@ static unsigned long sh_eth_get_edtrr_trns(struct sh_eth_private *mdp)
>>> {
>>> if (sh_eth_is_gether(mdp))
>>> return EDTRR_TRNS_GETHER;
>>> + else if (sh_eth_is_rz_fast_ether(mdp))
>>> + return EDTRR_TRNS_RZ_ETHER;
>> I'd just merge this with the GEther case.
> Sure, but in that case should we change the name.
> As both you and Magnus pointed out to me, the rz is not gigabit.
See below.
>>> else
>>> return EDTRR_TRNS_ETHER;
>>> }
>> [...]
>>> @@ -1062,7 +1155,8 @@ static void sh_eth_ring_format(struct net_device *ndev)
>>> if (i == 0) {
>>> /* Tx descriptor address set */
>>> sh_eth_write(ndev, mdp->tx_desc_dma, TDLAR);
>>> - if (sh_eth_is_gether(mdp))
>>> + if (sh_eth_is_gether(mdp) ||
>>> + sh_eth_is_rz_fast_ether(mdp))
>>> sh_eth_write(ndev, mdp->tx_desc_dma, TDFAR);
>> Hmm, TDFAR exists also on SH4 Ethers...
> Lets fix that separately.
Of course, was just another not to self.
[...]
>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
>>> index 0fe35b7..0bcde90 100644
>>> --- a/drivers/net/ethernet/renesas/sh_eth.h
>>> +++ b/drivers/net/ethernet/renesas/sh_eth.h
[...]
>>> @@ -191,6 +192,7 @@ enum DMAC_M_BIT {
>>> /* EDTRR */
>>> enum DMAC_T_BIT {
>>> EDTRR_TRNS_GETHER = 0x03,
>>> + EDTRR_TRNS_RZ_ETHER = 0x03,
>> I doubt we need a special case here. You didn't introduce one for
>> the software reset bits.
> True, but RZ is not Gigabit. So I think we either need two names
> or to choose a more generic name.
Well, R7S72100 manual calls these bits just TR[1:0]. Don't know what SoCs
having Gigabit call it in the manuals...
>>> EDTRR_TRNS_ETHER = 0x01,
R-Car manuals seem to call the bit TRNS (as well as the prehistoric SH
manuals probably). Perhaps we could use that difference, TRNS vs TR, don't know...
>>> };
WBR, Sergei
^ permalink raw reply
* Re: [PATCH][net-next] gianfar: Fix portabilty issues for ethtool and ptp
From: David Miller @ 2014-01-15 22:39 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev
In-Reply-To: <1389706500-1990-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Tue, 14 Jan 2014 15:35:00 +0200
> Fixes unhandled register write in gianfar_ethtool.c.
> Fixes following endianess related functional issues,
> reported by sparse as well, i.e.:
>
> gianfar_ethtool.c:1058:33: warning:
> incorrect type in argument 1 (different base types)
> expected unsigned int [unsigned] [usertype] value
> got restricted __be32 [usertype] ip4src
>
> gianfar_ethtool.c:1164:33: warning:
> restricted __be16 degrades to integer
>
> gianfar_ethtool.c:1669:32: warning:
> invalid assignment: ^=
> left side has type restricted __be16
> right side has type int
>
> Solves all the sparse warnings for mixig normal pointers
> with __iomem pointers for gianfar_ptp.c, i.e.:
> gianfar_ptp.c:163:32: warning:
> incorrect type in argument 1 (different address spaces)
> expected unsigned int [noderef] <asn:2>*addr
> got unsigned int *<noident>
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v5 net-next 2/4] sh_eth: Add support for r7s72100
From: Sergei Shtylyov @ 2014-01-15 22:26 UTC (permalink / raw)
To: Simon Horman, David S. Miller, netdev, linux-sh
Cc: linux-arm-kernel, Magnus Damm
In-Reply-To: <1389766341-14001-3-git-send-email-horms+renesas@verge.net.au>
Hello.
On 01/15/2014 09:12 AM, Simon Horman wrote:
> This is a fast ethernet controller.
I have to say it's not exact enough patch description: R7S72100 is not
Ethernet controller itself, it's a SoC containing the Ethernet controller.
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v5
> * As suggested by Sergei Shtylyov
> - Do not use sh_eth_chip_reset_r8a7740 as it accesses non-existent
> RMII registers. Instead use sh_eth_chip_reset.
> - Do not use sh_eth_set_rate_gether as it accesses non-existent registers.
> - Do not use reserved LCHNG bit of ECSR
> - Do not use reserved LCHNGIP bit of ECSIPR
> - Document that R8A779x also needs a 16 bit shift of the RFS bits
> - Do not document that the R7S72100 has GECMR, it does not
The above change list was moved from v2 section and doesn't match the real
changes done in v5. ;-)
> v4
> * As requested by David Miller
> - Use a boolean for the return value of sh_eth_is_rz_fast_ether()
> - Correct coding style in sh_eth_get_stats()
> v3
> * No change
> v2
> * As suggested by Magnus Damm and Sergei Shtylyov
> - r7s72100 ethernet is not gigabit so do not refer to it as such
> * As suggested by Magnus Damm
> - As RZ specific register layout rather than using the gigabit layout
> which includes registers that do not exist on this chip.
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 126 ++++++++++++++++++++++++++++++++--
> drivers/net/ethernet/renesas/sh_eth.h | 3 +-
> 2 files changed, 121 insertions(+), 8 deletions(-)
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index 4f5cfad..a7a0555 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -190,6 +190,64 @@ static const u16 sh_eth_offset_fast_rcar[SH_ETH_MAX_REGISTER_OFFSET] = {
> [TRIMD] = 0x027c,
> };
>
> +static const u16 sh_eth_offset_fast_rz[SH_ETH_MAX_REGISTER_OFFSET] = {
Shouldn't this map precede R-Car one since this SoC is newer the same way
you've reordered *enum* values, etc.? Sorry for not noticing in the previous
review...
[...]
> + [ARSTR] = 0x0000,
> + [TSU_CTRST] = 0x0004,
> + [TSU_VTAG0] = 0x0058,
> + [TSU_ADSBSY] = 0x0060,
> + [TSU_TEN] = 0x0064,
> + [TXNLCR0] = 0x0080,
> + [TXALCR0] = 0x0084,
> + [RXNLCR0] = 0x0088,
> + [RXALCR0] = 0x008C,
Well, the above counter register subgroup stands out from the TSU_*
registers in the Gigabit mapping, not sure if we should follow that. These
registers are not currently used anyway...
> + [TSU_ADRH0] = 0x0100,
> + [TSU_ADRL0] = 0x0104,
> + [TSU_ADRH31] = 0x01f8,
> + [TSU_ADRL31] = 0x01fc,
> +};
> +
> static const u16 sh_eth_offset_fast_sh4[SH_ETH_MAX_REGISTER_OFFSET] = {
> [ECMR] = 0x0100,
> [RFLR] = 0x0108,
> @@ -318,6 +376,14 @@ static bool sh_eth_is_gether(struct sh_eth_private *mdp)
> return false;
> }
>
> +static bool sh_eth_is_rz_fast_ether(struct sh_eth_private *mdp)
> +{
> + if (mdp->reg_offset == sh_eth_offset_fast_rz)
> + return true;
> + else
> + return false;
Perhaps you should compress the above functions to one-liners as Joe has
suggested. Or I/you could do it in a separate patch...
> +}
> +
> static void sh_eth_select_mii(struct net_device *ndev)
> {
> u32 value = 0x0;
[...]
> @@ -1309,9 +1409,9 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
>
> /* In case of almost all GETHER/ETHERs, the Receive Frame State
> * (RFS) bits in the Receive Descriptor 0 are from bit 9 to
> - * bit 0. However, in case of the R8A7740's GETHER, the RFS
> - * bits are from bit 25 to bit 16. So, the driver needs right
> - * shifting by 16.
> + * bit 0. However, in case of the R8A7740, R8A779x and
Small nit: comma needed before "and" as far as I know English grammar.
> + * R7S72100 the RFS bits are from bit 25 to bit 16. So, the
> + * driver needs right shifting by 16.
> */
> if (mdp->cd->shift_rd0)
> desc_status >>= 16;
Other than that, this looks fine now, you can add my:
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2 v3] ixgbe: define IXGBE_MAX_VFS_DRV_LIMIT macro and cleanup const 63
From: Brown, Aaron F @ 2014-01-15 22:00 UTC (permalink / raw)
To: ethan.kernel@gmail.com
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, Allan, Bruce W,
Wyborny, Carolyn, davem@davemloft.net,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1389795148-341-1-git-send-email-ethan.kernel@gmail.com>
On Wed, 2014-01-15 at 22:12 +0800, Ethan Zhao wrote:
> Because ixgbe driver limit the max number of VF functions could be enabled
> to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
> in code.
>
> v2: fix a typo.
> v3: fix a encoding issue.
>
> Signed-off-by: Ethan Zhao <ethan.kernel@gmail.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 5 +++++
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 0ade0cd..47e9b44 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -4818,7 +4818,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
> #ifdef CONFIG_PCI_IOV
> /* assign number of SR-IOV VFs */
> if (hw->mac.type != ixgbe_mac_82598EB)
> - adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
Unfortunately the if statement got changed considerably with a recent
commit:
commit 170e85430bcbe4d18e81b5a70bb163c741381092
ixgbe: add warning when max_vfs is out of range.
And the pattern no longer exists to make a match. In other words, this
patch no longer applies to net-next and I have to ask you for yet
another spin if you still want to squash the magic number.
Thanks,
Aaron
^ permalink raw reply
* Re: [PATCH v4 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: David Miller @ 2014-01-15 21:53 UTC (permalink / raw)
To: jiri; +Cc: thaller, hannes, netdev, stephen, dcbw
In-Reply-To: <20140113153110.GA2499@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 13 Jan 2014 16:31:10 +0100
> Sat, Jan 11, 2014 at 12:10:30AM CET, davem@davemloft.net wrote:
>>From: Thomas Haller <thaller@redhat.com>
>>Date: Thu, 9 Jan 2014 01:30:02 +0100
>>
>>> v1 -> v2: add a second commit, handling NOPREFIXROUTE in ip6_del_addr.
>>> v2 -> v3: reword commit messages, code comments and some refactoring.
>>> v3 -> v4: refactor, rename variables, add enum
>>>
>>> Thomas Haller (2):
>>> ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of
>>> IP6 routes
>>> ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE
>>
>>Series applied, thanks Thomas.
>
> Hi Dave. Have you pushed this already? I can't see these patches in
> net-next.
Sorry, I must have forgotten to push these changes out before I travelled
on Saturday.
Please respin and resubmit and I'll make sure they get integrated properly.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC 0/9]net: stmmac PM related fixes.
From: David Miller @ 2014-01-15 21:49 UTC (permalink / raw)
To: srinivas.kandagatla; +Cc: peppe.cavallaro, netdev, linux-kernel
In-Reply-To: <52D50C02.3040708@st.com>
From: srinivas kandagatla <srinivas.kandagatla@st.com>
Date: Tue, 14 Jan 2014 10:05:54 +0000
> Do you have any plans to take this series?
>
> Peppe already Acked these series.
>
> Please let me know if you want me to rebase these patches to a
> particular branch.
Please respin them against net-next and be sure to include Peppe's
ACKs.
^ permalink raw reply
* Re: [PATCH net-next] net: make dev_set_mtu() honor notification return code
From: David Miller @ 2014-01-15 21:48 UTC (permalink / raw)
To: vfalico; +Cc: netdev, jiri, edumazet, alexander.h.duyck, nicolas.dichtel
In-Reply-To: <20140114121354.GI4132@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 14 Jan 2014 13:13:54 +0100
> As, currently, only team can signal NOTIFY_BAD on mtu change, it's
> really easy to implement. What do you think?
Looks great, and I agree that RTNL should solve all the other issues.
^ permalink raw reply
* Re: [PATCH 1/4] ksz884x: delete useless variable
From: David Miller @ 2014-01-15 21:43 UTC (permalink / raw)
To: Julia.Lawall; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <1389629847-5330-2-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Mon, 13 Jan 2014 17:17:24 +0100
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Delete a variable that is at most only assigned to a constant, but never
> used otherwise. In this code, it is the variable result that is used for
> the return code, not rc.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied, thank you.
^ 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