Re: [RFC PATCH 4/5] bnxt: Add support for segmentation of tunnels with outer checksums

[Michael Chan]

On Tue, Apr 19, 2016 at 12:06 PM, Alexander Duyck  wrote:
> This patch assumes that the bnxt hardware will ignore existing IPv4/v6
> header fields for length and checksum as well as the length and checksum
> fields for outer UDP and GRE headers.
>
> I have no means of testing this as I do not have any bnx2x hardware but
> thought I would submit it as an RFC to see if anyone out there wants to
> test this and see if this does in fact enable this functionality allowing
> us to to segment tunneled frames that have an outer checksum.
>
> Signed-off-by: Alexander Duyck 

Hi Alex, I just did a very quick test of this patch on our bnxt
hardware and it seemed to work.

I created a vxlan endpoint with udpcsum enabled and I saw TSO packets
getting through.  I've verified that our hardware can be programmed to
either ignore outer UDP checksum or to calculate it.  Current default
is to ignore ipv4 UDP checksum and calculate ipv6 UDP checksum.
Thanks.

> ---
>  drivers/net/ethernet/broadcom/bnxt/bnxt.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>

[PATCH v2] net: Add Qualcomm IPC router

[Bjorn Andersson]

From: Courtney Cavin 

Add an implementation of Qualcomm's IPC router protocol, used to
communicate with service providing remote processors.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
[bjorn: Cope with 0 being a valid node id and implement RTM_NEWADDR]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Made node 0 (normally the Qualcomm modem) a valid node
- Implemented RTM_NEWADDR for specifying the local node id

 include/linux/socket.h|4 +-
 include/uapi/linux/qrtr.h |   12 +
 net/Kconfig   |1 +
 net/Makefile  |1 +
 net/qrtr/Kconfig  |   24 ++
 net/qrtr/Makefile |2 +
 net/qrtr/qrtr.c   | 1007 +
 net/qrtr/qrtr.h   |   31 ++
 net/qrtr/smd.c|  117 ++
 9 files changed, 1198 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/qrtr.h
 create mode 100644 net/qrtr/Kconfig
 create mode 100644 net/qrtr/Makefile
 create mode 100644 net/qrtr/qrtr.c
 create mode 100644 net/qrtr/qrtr.h
 create mode 100644 net/qrtr/smd.c

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 73bf6c6a833b..b5cc5a6d7011 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -201,8 +201,9 @@ struct ucred {
 #define AF_NFC 39  /* NFC sockets  */
 #define AF_VSOCK   40  /* vSockets */
 #define AF_KCM 41  /* Kernel Connection Multiplexor*/
+#define AF_QIPCRTR 42  /* Qualcomm IPC Router  */
 
-#define AF_MAX 42  /* For now.. */
+#define AF_MAX 43  /* For now.. */
 
 /* Protocol families, same as address families. */
 #define PF_UNSPEC  AF_UNSPEC
@@ -249,6 +250,7 @@ struct ucred {
 #define PF_NFC AF_NFC
 #define PF_VSOCK   AF_VSOCK
 #define PF_KCM AF_KCM
+#define PF_QIPCRTR AF_QIPCRTR
 #define PF_MAX AF_MAX
 
 /* Maximum queue length specifiable by listen.  */
diff --git a/include/uapi/linux/qrtr.h b/include/uapi/linux/qrtr.h
new file mode 100644
index ..66c0748d26e2
--- /dev/null
+++ b/include/uapi/linux/qrtr.h
@@ -0,0 +1,12 @@
+#ifndef _LINUX_QRTR_H
+#define _LINUX_QRTR_H
+
+#include 
+
+struct sockaddr_qrtr {
+   __kernel_sa_family_t sq_family;
+   __u32 sq_node;
+   __u32 sq_port;
+};
+
+#endif /* _LINUX_QRTR_H */
diff --git a/net/Kconfig b/net/Kconfig
index a8934d8c8fda..b841c42e5c9b 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -236,6 +236,7 @@ source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
 source "net/switchdev/Kconfig"
 source "net/l3mdev/Kconfig"
+source "net/qrtr/Kconfig"
 
 config RPS
bool
diff --git a/net/Makefile b/net/Makefile
index 81d14119eab5..bdd14553a774 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -78,3 +78,4 @@ endif
 ifneq ($(CONFIG_NET_L3_MASTER_DEV),)
 obj-y  += l3mdev/
 endif
+obj-$(CONFIG_QRTR) += qrtr/
diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
new file mode 100644
index ..f053cc25f621
--- /dev/null
+++ b/net/qrtr/Kconfig
@@ -0,0 +1,24 @@
+# Qualcomm IPC Router configuration
+#
+
+config QRTR
+   bool "Qualcomm IPC Router support"
+   depends on ARCH_QCOM || COMPILE_TEST
+   ---help---
+ Say Y if you intend to use Qualcomm IPC router protocol.  The
+ protocol is used to communicate with services provided by other
+ hardware blocks in the system.
+
+ In order to do service lookups, a userspace daemon is required to
+ maintain a service listing.
+
+if QRTR
+
+config QRTR_SMD
+   tristate "SMD IPC Router channels"
+   depends on QRTR && QCOM_SMD && OF
+   ---help---
+ Say Y here to support SMD based ipcrouter channels.  SMD is the
+ most common transport for IPC Router.
+
+endif # QRTR
diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile
new file mode 100644
index ..e282a84ffc5c
--- /dev/null
+++ b/net/qrtr/Makefile
@@ -0,0 +1,2 @@
+obj-y := qrtr.o
+obj-$(CONFIG_QRTR_SMD) += smd.o
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
new file mode 100644
index ..c985ecbe9bd6
--- /dev/null
+++ b/net/qrtr/qrtr.c
@@ -0,0 +1,1007 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include  /* 

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Anup Patel]

On Wed, Apr 27, 2016 at 1:11 AM, Andrew Lunn  wrote:
> On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote:
>> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
>> > > A more complex problem would be having a PHY driver for a device
>> > > that can be either an ethernet phy or some other phy.
>> >
>> > I doubt that ever happens. You can have up to 32 different devices on
>> > an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
>> > completely different things, why would a hardware engineer place them
>> > on the same address? It is like saying your ATA controller and VGA
>> > controller share the same slot on the PCI bus...
>>
>> To clarify: what I meant is a device that is designed as a PHY for
>> similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
>> register set and a single driver, but that driver can operate
>> in multiple modes. You typically have multiple instances of
>> such hardware, with each instance linked to exactly one host
>> device, but one driver for all of them.
>>
>> See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
>> and drivers/phy/phy-xgene.c for one such example.
>
> Interesting. Also, that this lists SGMII. I assume this is a phy in
> the MAC in order to talk to the Ethernet PHY.
>
> I still don't see it being a big problem if a phy driver implements an
> Ethernet PHY. It just needs to call phy_device_create() and
> phy_device_register().
>
> Andrew

It is really interesting to see the evolution of MDIO bus:

1. Traditionally, MDIO controller used to be part of each ethernet controller
itself so each ethernet controller used to have it's own 2 wire MDIO bus

2. Next, we saw SoC with multiple ethernet controllers sharing same MDIO
bus. In other words, we saw multiple MDIO bus being muxed over single
MDIO bus with additional bus select lines (I think this is when
drivers/net/phy/mdio-mux.c APIs were implemented but at this point all
PHYs on muxed MDIO bus were ethernet PHYs).

3. Then, we saw SoC with ethernet switch devices also accessible over
shared MDIO bus (or Muxed MDIO bus) along with ethernet PHYs (I guess
this is why we have drivers/net/phy/mdio_device.c which adds
"mdio_device" for non-ethernet-PHY devices on MDIO bus).

4. Now, we have SoC with SATA PHYs, PCIe PHYs, USB PHYs, and Ethernet
PHYs all accessible over same shared MDIO bus (or Muxed MDIO bus). The
SATA PHYs and PCIe PHYs are registered to "Generic PHY framework". For
USB PHYs, we can either register to "Generic PHY framework" or "USB PHY
framework". For Ethernet PHYs, we register MDIO bus instance to "Ethernet
MDIO framework".

The devices on ARM64 SoC has to be within first 4GB and RAM has to start
from first 4GB to be ARM compliant because ARM64 CPUs have 32bit mode and
all devices and RAM should be available to 32bit mode with MMU disabled.
This means that we only have 4GB to fit all devices registers and some
portion of RAM. Some of these non-Ethernet PHYs have tons of registers so
as number of PHYs increase in a SoC they will eat-up lot of first 4GB
address space. Using same MDIO bus for all types of PHYs (SATA, PCIe, USB,
and Ethernet) is actually a good approach because it actually saves lot of
first 4GB address space. In future, more devices will be moved to a shared
MDIO bus which are less frequently accessed.

For Broadcom iProc SoCs, the design choice has already been made to use
shared MDIO bus for all PHYs. In fact, Broadcom iProc NS2 SoC already has
a shared MDIO bus for SATA PHYs, USB PHYs, PCIe PHYs, and Ethernet
PHYs and more Broadcom iProc SoCs are on their way. Of course, there are
few exceptions in iProc SoCs such as SATA PHYs where we also have memory
mapped registers to access PHYs but other PHYs don't have such memory
mapped registers.

Clearly from above, the traditional 2 wire MDIO bus is now a shared MDIO
bus with 2-wire plus additional select lines. Also, now we have SoCs (such
as Broadcom iProc SoCs) which has such shared MDIO bus and I think
in-future we will have SoCs with a shared MDIO bus for variety of devices.

For long term, we really need a clean solution to fit shared MDIO based
PHY drivers in Linux kernel. Also, shared MDIO based PHY drivers should
not be dependent on any particular IO subsystem (such as Linux Ethernet)
because there are lot of use-cases where people want strip down kernel
image by not-compiling IO subsystems which are not required.

IMHO, we have several options in front of us:
1. Use some light-weight framework (such as shared_mdio.c implemented
by this patchset) under drivers/bus
2. Extend "Generic PHY framework" to allow something like shared MDIO
bus (as-per Arnd's suggestion)
3. Move-out "MDIO-mux APIs" from drivers/net/phy to something like
drivers/mdio-mux and make it independent of "Linux Ethernet subsystem".
(... may be more options ...)

Regards,
Anup

Re: [PATCH -next] net: w5100: support W5500

[David Miller]

From: Akinobu Mita 
Date: Wed, 27 Apr 2016 05:43:48 +0900

> This adds support for W5500 chip.

Applied, thanks.

Re: [PATCH net-next] net-rfs: fix false sharing accessing sd->input_queue_head

[David Miller]

From: Eric Dumazet 
Date: Tue, 26 Apr 2016 15:30:07 -0700

> From: Eric Dumazet 
> 
> sd->input_queue_head is incremented for each processed packet
> in process_backlog(), and read from other cpus performing
> Out Of Order avoidance in get_rps_cpu()
> 
> Moving this field in a separate cache line keeps it mostly
> hot for the cpu in process_backlog(), as other cpus will
> only read it.
> 
> In a stress test, process_backlog() was consuming 6.80 % of cpu cycles,
> and the patch reduced the cost to 0.65 %
> 
> Signed-off-by: Eric Dumazet 

Applied, nice work Eric.

Re: [net-next 08/15] i40e: Allow user to change input set mask for flow director

[David Miller]

From: Jeff Kirsher 
Date: Tue, 26 Apr 2016 13:55:41 -0700

> From: Kiran Patil 
> 
> This patch implements feature, which allows user to change
> input set mask for flow director using side-band channel.
> This patch adds definition of FLOW_TYPE_MASK into the header file.
> With this patch, user can now specify less than 4 tuple(src ip, dsp ip,
> src port, dst port) for flow type TCP4/UDP4.
> 
> Change-Id: I90052508f8c172c0da5a4b78b949704b4a59ea78
> Signed-off-by: Kiran Patil 
> Tested-by: Andrew Bowers 
> Signed-off-by: Jeff Kirsher 

If you want to do this, you have to define the semantics generically
in include/uapi/linux/ethtool.h so that other drivers can implement
this too.

Please don't ever implement private, driver specific, interpretations
of the generic ethtool facilitites.

The semantics and interpretations of the values must absolutely be
consistent across all drivers in the tree.

Otherwise the user experience is terrible.

Thanks.

Re: [PATCH v5 09/21] IB/hns: Add hca support

[oulijun]

On 2016/4/26 22:18, Leon Romanovsky wrote:
> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>> On 2016/4/24 15:54, Leon Romanovsky wrote:
>>> On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
 This patch mainly setup hca for RoCE. it will do a series of
 initial works as follows:
   1. init uar table, allocate uar resource
   2. init pd table
   3. init cq table
   4. init mr table
   5. init qp table

 Signed-off-by: Lijun Ou 
 Signed-off-by: Wei Hu(Xavier) 
 ---
  drivers/infiniband/hw/hns/hns_roce_alloc.c  | 104 
  drivers/infiniband/hw/hns/hns_roce_cq.c |  25 
  drivers/infiniband/hw/hns/hns_roce_device.h |  69 ++
  drivers/infiniband/hw/hns/hns_roce_eq.c |   1 -
  drivers/infiniband/hw/hns/hns_roce_icm.c|  88 +
  drivers/infiniband/hw/hns/hns_roce_icm.h|   9 ++
  drivers/infiniband/hw/hns/hns_roce_main.c   |  79 
  drivers/infiniband/hw/hns/hns_roce_mr.c | 187 
 
  drivers/infiniband/hw/hns/hns_roce_pd.c |  65 ++
  drivers/infiniband/hw/hns/hns_roce_qp.c |  30 +
  10 files changed, 656 insertions(+), 1 deletion(-)
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
  create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c

 diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c 
 b/drivers/infiniband/hw/hns/hns_roce_alloc.c
 new file mode 100644
 index 000..0c76f1b
 --- /dev/null
 +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
 @@ -0,0 +1,104 @@
 +/*
 + * Copyright (c) 2016 Hisilicon Limited.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include "hns_roce_device.h"
 +
 +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
 +{
 +  int ret = 0;
 +
 +  spin_lock(>lock);
 +  *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
 +  if (*obj >= bitmap->max) {
 +  bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
 + & bitmap->mask;
 +  *obj = find_first_zero_bit(bitmap->table, bitmap->max);
>>>
>>> find_first_zero_bit function returns "unsigned long" which may or may
>>> not be equal to u32 on some architectures.
>>>
>> Hi Leon,
>> I appreciate your keen eye. this code is meant for ARM64bit therefore 
>> should run corretly for 64-bit AARCH64.
>> I will consider changing it as part of good partice and better portability "
>> I will give a primary plan to modified it.
>> for example:
>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
>> Beause the max size of bitmap->table is u32 in current version.
>>
>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>>   u32 reserved_bot, u32 reserved_top)
>> {
>>  u32 i;
>>
>>  if (num != roundup_pow_of_two(num))
>>  return -EINVAL;
>>
>>  bitmap->last = 0;
>>  bitmap->top = 0;
>>  bitmap->max = num - reserved_top;
>>  bitmap->mask = mask;
>>  bitmap->reserved_top = reserved_top;
>>  spin_lock_init(>lock);
>>  bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>>  GFP_KERNEL);
>>
>> Is this plan ok?
> 
> No,
> You are submitting new driver, please do it properly (without casting)
> from the beginning.
> 
oh, i see. I will give a better plan to modify it.

Thanks
Lijun Ou
>>
>> Thanks
>> Lijun Ou
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 net-next 11/13] Documentation: Bindings: Update DT binding for separating dsaf dev support

[Yisen Zhuang]

Hi Rob and David,

Please see my comments inline.

David have merged this series to net-next, but we need to modify some codes 
according
to Rob's comments. I am not sure if i need to send V3 for this series, or 
separate
patches of documentation to independent series and generate a new patch for hns 
base
on current net-next?

Thanks,

Yisen

在 2016/4/26 20:48, Rob Herring 写道:
> On Sat, Apr 23, 2016 at 05:05:15PM +0800, Yisen Zhuang wrote:
>> Because debug dsaf port was separated from service dsaf port, this patch
>> updates the related information of DT binding.
> 
> Separated when? New version of the h/w? If so, where's the new 
> compatible string? This is quite a big binding change. 

There isn't any change of h/w. I separated debug dsaf port from sevice dsaf
port to make the code more simple and readability.

> 
>> Signed-off-by: Yisen Zhuang 
>>
>> ---
>>  .../devicetree/bindings/net/hisilicon-hns-dsaf.txt | 59 
>> ++
>>  1 file changed, 49 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt 
>> b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
>> index ecacfa4..5ccd4f0 100644
>> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
>> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
>> @@ -7,19 +7,47 @@ Required properties:
>>  - mode: dsa fabric mode string. only support one of dsaf modes like these:
>>  "2port-64vf",
>>  "6port-16rss",
>> -"6port-16vf".
>> +"6port-16vf",
>> +"single-port".
>>  - interrupt-parent: the interrupt parent of this device.
>>  - interrupts: should contain the DSA Fabric and rcb interrupt.
>>  - reg: specifies base physical address(es) and size of the device registers.
>> -  The first region is external interface control register base and size.
>> -  The second region is SerDes base register and size.
>> +  The first region is external interface control register base and 
>> size(optional,
>> +  only be used when subctrl-syscon is not exists). It is recommended using
> 
> only used when subctrl-syscon does not exist

Agree, thanks.

> 
>> +  subctrl-syscon rather than this address.
>> +  The second region is SerDes base register and size(optional, only be used 
>> when
>> +  serdes-syscon in port node is not exists. It is recommended using
> 
> similar rewording needed here.

Agree, thanks.

> 
>> +  serdes-syscon rather than this address.
>>The third region is the PPE register base and size.
>> -  The fourth region is dsa fabric base register and size.
>> -  The fifth region is cpld base register and size, it is not required if do 
>> not use cpld.
>> -- phy-handle: phy handle of physicl port, 0 if not any phy device. see 
>> ethernet.txt [1].
>> +  The fourth region is dsa fabric base register and size. It is not 
>> required for
>> +  single-port mode.
>> +- reg-names: may be ppe-base and(or) dsaf-base. It is used to find the
>> +  corresponding reg's index.
> 
> But you have up to 5 regions.
> 
> The variable nature of what regions you have tells me you need more 
> specific compatible strings for each chip.

we didn't add support of new h/w. We added these regions to make code simple 
and readability.
If we need to add support of next h/w version next time, we don't need to add 
many branches
for these attributes. So we didn't add a new compatible here.

> 
>> +
>> +- phy-handle: phy handle of physicl port, 0 if not any phy device. It is 
>> optional
> 
> s/physicl/physical/

Agree, thanks.

> 
>> +  attribute. If port node is exists, phy-handle in each port node will be 
>> used.
>> +  see ethernet.txt [1].
>> +- subctrl-syscon: is syscon handle for external interface control register.
>> +- reset-field-offset: is offset of reset field. Its value depends on the 
>> hardware
>> +  user manual.
>>  - buf-size: rx buffer size, should be 16-1024.
>>  - desc-num: number of description in TX and RX queue, should be 512, 1024, 
>> 2048 or 4096.
>>  
>> +- port: subnodes of dsaf. A dsaf node may contain several port 
>> nodes(Depending
>> +  on mode of dsaf). Port node contain some attributes listed below:
>> +- port-id: is physical port index in one dsaf.
> 
> Indexes should generally be avoided. What does the number correspond 
> to in h/w (if anything)?

port-id is index for a port in dsaf, it is correspond to index of PHY showed 
below.

 CPU
  |
---
| |   |
---   -
| |  ||   |   |   |   |
|PPE ||  PPE  |   |  PPE  |
| | 

Re: [PATCH v5 09/21] IB/hns: Add hca support

[oulijun]

On 2016/4/26 22:25, Jiri Pirko wrote:
> Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote:
>> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>>> On 2016/4/24 15:54, Leon Romanovsky wrote:
> 
> 
> 
> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> +{
> + int ret = 0;
> +
> + spin_lock(>lock);
> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> + if (*obj >= bitmap->max) {
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> +& bitmap->mask;
> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);

 find_first_zero_bit function returns "unsigned long" which may or may
 not be equal to u32 on some architectures.

>>> Hi Leon,
>>> I appreciate your keen eye. this code is meant for ARM64bit therefore 
>>> should run corretly for 64-bit AARCH64.
> 
> The driver should run correctly on any arch.
> 
 Hi Jiri Pirko,
Our driver run in ARM64 platform by depending on Kconfig. It will be 
configure in Kconfig file.

Thanks
Lijun Ou
> 
>>> I will consider changing it as part of good partice and better portability "
>>> I will give a primary plan to modified it.
>>> for example:
>>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, 
>>> bitmap->last);
>>> Beause the max size of bitmap->table is u32 in current version.
>>>
>>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>>>  u32 reserved_bot, u32 reserved_top)
>>> {
>>> u32 i;
>>>
>>> if (num != roundup_pow_of_two(num))
>>> return -EINVAL;
>>>
>>> bitmap->last = 0;
>>> bitmap->top = 0;
>>> bitmap->max = num - reserved_top;
>>> bitmap->mask = mask;
>>> bitmap->reserved_top = reserved_top;
>>> spin_lock_init(>lock);
>>> bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>>> GFP_KERNEL);
>>>
>>> Is this plan ok?
>>
>> No,
>> You are submitting new driver, please do it properly (without casting)
>>from the beginning.
>>
>>>
>>> Thanks
>>> Lijun Ou
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> .
> 

RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[Dexuan Cui]

> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Wednesday, April 27, 2016 0:19
> To: Dexuan Cui ; gre...@linuxfoundation.org;
> da...@davemloft.net; netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; Jason Wang
> ; KY Srinivasan ; Haiyang Zhang
> ; vkuzn...@redhat.com; j...@perches.com
> Subject: Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets
> 
> Hi,
> 
> I will be working with Dexuan to possibly port this functionality into RHEL.
> 
> Here are my initial comments. Mostly stylistic. They are prefaced by CAA.
> 
> Cathy Avery

Thank you very much, Cathy!

I'll take your pretty good suggestions and post a new version.

Thanks,
-- Dexuan

Re: [PATCH] net: phy: at803x: only the AT8030 needs a hardware reset on link change

[Florian Fainelli]

Le 26/04/2016 10:44, Timur Tabi a écrit :
> Commit 13a56b44 ("at803x: Add support for hardware reset") added a
> work-around for a hardware bug on the AT8030.  However, the work-around
> was being called for all 803x PHYs, even those that don't need it.
> Function at803x_link_change_notify() checks to make sure that it only
> resets the PHY on the 8030, but it makes more sense to not call that
> function at all if it isn't needed.
> 
> Signed-off-by: Timur Tabi 

Reviewed-by: Florian Fainelli 

This looks nicer indeed!
-- 
Florian

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/mellanox/mlx5/core/en_main.c

between commit:

  d8edd2469ace ("et/mlx5e: Fix minimum MTU")

from the net tree and commit:

  0e405443e803 ("net/mlx5e: Improve set features ndo resiliency")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 67d548b70e14,5bad17d37d7b..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -2025,9 -2214,49 +2240,52 @@@ static int set_feature_rx_vlan(struct n
return err;
  }
  
+ static int mlx5e_handle_feature(struct net_device *netdev,
+   netdev_features_t wanted_features,
+   netdev_features_t feature,
+   mlx5e_feature_handler feature_handler)
+ {
+   netdev_features_t changes = wanted_features ^ netdev->features;
+   bool enable = !!(wanted_features & feature);
+   int err;
+ 
+   if (!(changes & feature))
+   return 0;
+ 
+   err = feature_handler(netdev, enable);
+   if (err) {
+   netdev_err(netdev, "%s feature 0x%llx failed err %d\n",
+  enable ? "Enable" : "Disable", feature, err);
+   return err;
+   }
+ 
+   MLX5E_SET_FEATURE(netdev, feature, enable);
+   return 0;
+ }
+ 
+ static int mlx5e_set_features(struct net_device *netdev,
+ netdev_features_t features)
+ {
+   int err;
+ 
+   err  = mlx5e_handle_feature(netdev, features, NETIF_F_LRO,
+   set_feature_lro);
+   err |= mlx5e_handle_feature(netdev, features,
+   NETIF_F_HW_VLAN_CTAG_FILTER,
+   set_feature_vlan_filter);
+   err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_TC,
+   set_feature_tc_num_filters);
+   err |= mlx5e_handle_feature(netdev, features, NETIF_F_RXALL,
+   set_feature_rx_all);
+   err |= mlx5e_handle_feature(netdev, features, NETIF_F_HW_VLAN_CTAG_RX,
+   set_feature_rx_vlan);
+ 
+   return err ? -EINVAL : 0;
+ }
+ 
 +#define MXL5_HW_MIN_MTU 64
 +#define MXL5E_MIN_MTU (MXL5_HW_MIN_MTU + ETH_FCS_LEN)
 +
  static int mlx5e_change_mtu(struct net_device *netdev, int new_mtu)
  {
struct mlx5e_priv *priv = netdev_priv(netdev);
@@@ -2633,18 -2966,10 +2997,19 @@@ static void mlx5e_destroy_netdev(struc
schedule_work(>set_rx_mode_work);
mlx5e_disable_async_events(priv);
flush_scheduled_work();
 -  unregister_netdev(netdev);
 +  if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, >intf_state)) {
 +  netif_device_detach(netdev);
 +  mutex_lock(>state_lock);
 +  if (test_bit(MLX5E_STATE_OPENED, >state))
 +  mlx5e_close_locked(netdev);
 +  mutex_unlock(>state_lock);
 +  } else {
 +  unregister_netdev(netdev);
 +  }
 +
mlx5e_tc_cleanup(priv);
mlx5e_vxlan_cleanup(priv);
+   mlx5e_destroy_q_counter(priv);
mlx5e_destroy_flow_tables(priv);
mlx5e_destroy_tirs(priv);
mlx5e_destroy_rqt(priv, MLX5E_SINGLE_RQ_RQT);

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/macsec.c

between commit:

  748164802c1b ("macsec: add missing macsec prefix in uapi")

from the net tree and commit:

  f60d94c00968 ("macsec: use nla_put_u64_64bit()")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/macsec.c
index c6385617bfb2,a172a1ffa151..
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@@ -2231,9 -2271,11 +2276,11 @@@ static int nla_put_secy(struct macsec_s
if (!secy_nest)
return 1;
  
-   if (nla_put_sci(skb, MACSEC_SECY_ATTR_SCI, secy->sci) ||
-   nla_put_u64(skb, MACSEC_SECY_ATTR_CIPHER_SUITE,
-   MACSEC_DEFAULT_CIPHER_ID) ||
+   if (nla_put_sci(skb, MACSEC_SECY_ATTR_SCI, secy->sci,
+   MACSEC_SECY_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_SECY_ATTR_CIPHER_SUITE,
 -DEFAULT_CIPHER_ID,
++MACSEC_DEFAULT_CIPHER_ID,
+ MACSEC_SECY_ATTR_PAD) ||
nla_put_u8(skb, MACSEC_SECY_ATTR_ICV_LEN, secy->icv_len) ||
nla_put_u8(skb, MACSEC_SECY_ATTR_OPER, secy->operational) ||
nla_put_u8(skb, MACSEC_SECY_ATTR_PROTECT, secy->protect_frames) ||
@@@ -3184,10 -3219,11 +3236,11 @@@ static int macsec_fill_info(struct sk_b
struct macsec_secy *secy = _priv(dev)->secy;
struct macsec_tx_sc *tx_sc = >tx_sc;
  
-   if (nla_put_sci(skb, IFLA_MACSEC_SCI, secy->sci) ||
+   if (nla_put_sci(skb, IFLA_MACSEC_SCI, secy->sci,
+   IFLA_MACSEC_PAD) ||
nla_put_u8(skb, IFLA_MACSEC_ICV_LEN, secy->icv_len) ||
-   nla_put_u64(skb, IFLA_MACSEC_CIPHER_SUITE,
-   MACSEC_DEFAULT_CIPHER_ID) ||
+   nla_put_u64_64bit(skb, IFLA_MACSEC_CIPHER_SUITE,
 -DEFAULT_CIPHER_ID, IFLA_MACSEC_PAD) ||
++MACSEC_DEFAULT_CIPHER_ID, IFLA_MACSEC_PAD) ||
nla_put_u8(skb, IFLA_MACSEC_ENCODING_SA, tx_sc->encoding_sa) ||
nla_put_u8(skb, IFLA_MACSEC_ENCRYPT, tx_sc->encrypt) ||
nla_put_u8(skb, IFLA_MACSEC_PROTECT, secy->protect_frames) ||

Re: [PATCH net-next 9/9] taskstats: use the libnl API to align nlattr on 64-bit

[Balbir Singh]

On 23/04/16 01:31, Nicolas Dichtel wrote:
> Goal of this patch is to use the new libnl API to align netlink attribute
> when needed.
> The layout of the netlink message will be a bit different after the patch,
> because the padattr (TASKSTATS_TYPE_STATS) will be inside the nested
> attribute instead of before it.
> 
> Signed-off-by: Nicolas Dichtel 

The layout will change/break user space -- I've not tested the patch though..

Balbir Singh.
 

[PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[Ben Hutchings]

3.2.80-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Vijay Pandurangan 

[ Upstream commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f ]

Packets that arrive from real hardware devices have ip_summed ==
CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
current version of veth will replace CHECKSUM_NONE with
CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
a veth device to be delivered to the application. This caused applications
at Twitter to receive corrupt data when network hardware was corrupting
packets.

We believe this was added as an optimization to skip computing and
verifying checksums for communication between containers. However, locally
generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
written does nothing for them. As far as we can tell, after removing this
code, these packets are transmitted from one stack to another unmodified
(tcpdump shows invalid checksums on both sides, as expected), and they are
delivered correctly to applications. We didn’t test every possible network
configuration, but we tried a few common ones such as bridging containers,
using NAT between the host and a container, and routing from hardware
devices to containers. We have effectively deployed this in production at
Twitter (by disabling RX checksum offloading on veth devices).

This code dates back to the first version of the driver, commit
 ("[NET]: Virtual ethernet device driver"), so I
suspect this bug occurred mostly because the driver API has evolved
significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
packet checksumming") (in December 2010) fixed this for packets that get
created locally and sent to hardware devices, by not changing
CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
in from hardware devices.

Co-authored-by: Evan Jones 
Signed-off-by: Evan Jones 
Cc: Nicolas Dichtel 
Cc: Phil Sutter 
Cc: Toshiaki Makita 
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vijay Pandurangan 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/net/veth.c | 6 --
 1 file changed, 6 deletions(-)

--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -126,11 +126,6 @@ static netdev_tx_t veth_xmit(struct sk_b
stats = this_cpu_ptr(priv->stats);
rcv_stats = this_cpu_ptr(rcv_priv->stats);
 
-   /* don't change ip_summed == CHECKSUM_PARTIAL, as that
-  will cause bad checksum on forwarded packets */
-   if (skb->ip_summed == CHECKSUM_NONE &&
-   rcv->features & NETIF_F_RXCSUM)
-   skb->ip_summed = CHECKSUM_UNNECESSARY;
 
length = skb->len;
if (dev_forward_skb(rcv, skb) != NET_RX_SUCCESS)

Re: [PATCH net-next] net-rfs: fix false sharing accessing sd->input_queue_head

[Tom Herbert]

On Tue, Apr 26, 2016 at 3:30 PM, Eric Dumazet  wrote:
> From: Eric Dumazet 
>
> sd->input_queue_head is incremented for each processed packet
> in process_backlog(), and read from other cpus performing
> Out Of Order avoidance in get_rps_cpu()
>
> Moving this field in a separate cache line keeps it mostly
> hot for the cpu in process_backlog(), as other cpus will
> only read it.
>
> In a stress test, process_backlog() was consuming 6.80 % of cpu cycles,
> and the patch reduced the cost to 0.65 %
>
> Signed-off-by: Eric Dumazet 

Very nice!

Acked-by: Tom Herbert 

> ---
>  include/linux/netdevice.h |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 18d8394f2e5d..934ca866562d 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2747,11 +2747,15 @@ struct softnet_data {
> struct sk_buff  *completion_queue;
>
>  #ifdef CONFIG_RPS
> -   /* Elements below can be accessed between CPUs for RPS */
> +   /* input_queue_head should be written by cpu owning this struct,
> +* and only read by other cpus. Worth using a cache line.
> +*/
> +   unsigned intinput_queue_head cacheline_aligned_in_smp;
> +
> +   /* Elements below can be accessed between CPUs for RPS/RFS */
> struct call_single_data csd cacheline_aligned_in_smp;
> struct softnet_data *rps_ipi_next;
> unsigned intcpu;
> -   unsigned intinput_queue_head;
> unsigned intinput_queue_tail;
>  #endif
> unsigned intdropped;
>
>

[PATCH net-next 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock

[Francois Romieu]

pch_gbe_tx_ring.tx_lock is only used in the hard_xmit handler and
in the transmit completion reaper called from NAPI context.

Signed-off-by: Francois Romieu 
---
 CONFIG_COMPILE_TESTed

 drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h  |  2 --
 drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 10 ++
 2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h 
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
index 2a55d6d..8d710a3 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
@@ -481,7 +481,6 @@ struct pch_gbe_buffer {
 
 /**
  * struct pch_gbe_tx_ring - tx ring information
- * @tx_lock:   spinlock structs
  * @desc:  pointer to the descriptor ring memory
  * @dma:   physical address of the descriptor ring
  * @size:  length of descriptor ring in bytes
@@ -491,7 +490,6 @@ struct pch_gbe_buffer {
  * @buffer_info:   array of buffer information structs
  */
 struct pch_gbe_tx_ring {
-   spinlock_t tx_lock;
struct pch_gbe_tx_desc *desc;
dma_addr_t dma;
unsigned int size;
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c 
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index ca4add7..5c8e2f1 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -1640,7 +1640,7 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
   cleaned_count);
if (cleaned_count > 0)  { /*skip this if nothing cleaned*/
/* Recover from running out of Tx resources in xmit_frame */
-   spin_lock(_ring->tx_lock);
+   netif_tx_lock(adapter->netdev);
if (unlikely(cleaned && (netif_queue_stopped(adapter->netdev
{
netif_wake_queue(adapter->netdev);
@@ -1652,7 +1652,7 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
 
netdev_dbg(adapter->netdev, "next_to_clean : %d\n",
   tx_ring->next_to_clean);
-   spin_unlock(_ring->tx_lock);
+   netif_tx_lock(adapter->netdev);
}
return cleaned;
 }
@@ -1805,7 +1805,6 @@ int pch_gbe_setup_tx_resources(struct pch_gbe_adapter 
*adapter,
 
tx_ring->next_to_use = 0;
tx_ring->next_to_clean = 0;
-   spin_lock_init(_ring->tx_lock);
 
for (desNo = 0; desNo < tx_ring->count; desNo++) {
tx_desc = PCH_GBE_TX_DESC(*tx_ring, desNo);
@@ -2135,13 +2134,9 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, 
struct net_device *netdev)
 {
struct pch_gbe_adapter *adapter = netdev_priv(netdev);
struct pch_gbe_tx_ring *tx_ring = adapter->tx_ring;
-   unsigned long flags;
-
-   spin_lock_irqsave(_ring->tx_lock, flags);
 
if (unlikely(!PCH_GBE_DESC_UNUSED(tx_ring))) {
netif_stop_queue(netdev);
-   spin_unlock_irqrestore(_ring->tx_lock, flags);
netdev_dbg(netdev,
   "Return : BUSY  next_to use : 0x%08x  next_to clean 
: 0x%08x\n",
   tx_ring->next_to_use, tx_ring->next_to_clean);
@@ -2150,7 +2145,6 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, struct 
net_device *netdev)
 
/* CRC,ITAG no support */
pch_gbe_tx_queue(adapter, tx_ring, skb);
-   spin_unlock_irqrestore(_ring->tx_lock, flags);
return NETDEV_TX_OK;
 }
 
-- 
2.5.5

Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller

[Marek Vasut]

On 04/26/2016 11:22 PM, Joachim Eastwood wrote:
> On 26 April 2016 at 14:47, Marek Vasut  wrote:
>> On 04/26/2016 02:26 PM, Joachim Eastwood wrote:
>>> On 26 April 2016 at 00:55, Marek Vasut  wrote:
 On 04/25/2016 08:11 PM, Joachim Eastwood wrote:
> On 21 April 2016 at 14:11, Marek Vasut  wrote:
>>
>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>> since the functionality is already performed by the stmmac core.
>
> I am trying to rebase my changes on top of your two patches and
> noticed a couple of things.
>
>>  static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>  {
>> -   struct socfpga_dwmac*dwmac = priv;
>> +   struct socfpga_dwmac *dwmac = priv;
>> struct net_device *ndev = platform_get_drvdata(pdev);
>> struct stmmac_priv *stpriv = NULL;
>> int ret = 0;
>>
>> -   if (ndev)
>> -   stpriv = netdev_priv(ndev);
>> +   if (!ndev)
>> +   return -EINVAL;
>
> ndev can never be NULL here. socfpga_dwmac_init() is only called if
> stmmac_dvr_probe() succeeds or we are running the resume callback. So
> I don't see how this could ever be NULL.

 That's a good point, this check can indeed be removed. While you're at
 the patching, can you remove this one ?
>>>
>>> Yes, my patch will refactor the init() function so this will go away.
>>
>> Thanks!
>>
>> +
>> +   stpriv = netdev_priv(ndev);
>
> It's not really nice to access 'stmmac_priv' as it should be private
> to the core driver, but I don't see any other good solution right now.

 I guess some stmmac_reset_assert() wrapper would be nicer, yes. What do
 you think ?

>> +   if (!stpriv)
>> +   return -EINVAL;
>>
>> /* Assert reset to the enet controller before changing the phy 
>> mode */
>> -   if (dwmac->stmmac_rst)
>> -   reset_control_assert(dwmac->stmmac_rst);
>> +   if (stpriv->stmmac_rst)
>> +   reset_control_assert(stpriv->stmmac_rst);
>>
>> /* Setup the phy mode in the system manager registers according 
>> to
>>  * devicetree configuration
>> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device 
>> *pdev, void *priv)
>> /* Deassert reset for the phy configuration to be sampled by
>>  * the enet controller, and operation to start in requested mode
>>  */
>> -   if (dwmac->stmmac_rst)
>> -   reset_control_deassert(dwmac->stmmac_rst);
>> +   if (stpriv->stmmac_rst)
>> +   reset_control_deassert(stpriv->stmmac_rst);
>>
>> /* Before the enet controller is suspended, the phy is suspended.
>>  * This causes the phy clock to be gated. The enet controller is
>> @@ -245,7 +228,7 @@ static int socfpga_dwmac_init(struct platform_device 
>> *pdev, void *priv)
>>  * control register 0, and can be modified by the phy driver
>>  * framework.
>>  */
>> -   if (stpriv && stpriv->phydev)
>> +   if (stpriv->phydev)
>> phy_resume(stpriv->phydev);
>
> Before this change phy_resume() was only called during driver resume
> when , but your patches cause phy_resume() to called at probe time as
> well. Is this okey?

 I _hope_ it's OK. The cryptic comment above is not very helpful in this
 aspect. Dinh ? :)
>>>
>>> My patches will move phy_resume() to the resume callback so it
>>> preserves the previous behavior. But if someone knows more about this
>>> that would be useful.
>>>
>>>
 btw I wish you reviewed my patch a bit earlier to catch these bits.
>>>
>>> Sorry, about that. I have been really busy with other things lately.
>>
>> Oh I'm real happy someone is doing the refactoring :) I appreciate your
>> work, sorry if that was unclear.
>>
>>> My patches based on next from Friday can be found here now:
>>> https://github.com/manabian/linux-lpc/tree/net-socfpga-dwmac-on-next
>>>
>>> I had to add your latest patch as well since the next version I used
>>> didn't have it. I'll post the patches on netdev later today or
>>> tomorrow.
>>
>> Looks like next wasn't synced for a few days, yeah.
>>
>> You can add my:
>>
>> On SoCFPGA Cyclone V SoC (DENX MCVEVK):
>> Tested-by: Marek Vasut 
>>
>> to those patches
> 
> Excellent. Thanks Marek.
> 
> btw, did you also test suspend/resume?

No, I believe that is unsupported on SoCFPGA Cyclone V in general.

-- 
Best regards,
Marek Vasut

[PATCH net-next] net-rfs: fix false sharing accessing sd->input_queue_head

[Eric Dumazet]

From: Eric Dumazet 

sd->input_queue_head is incremented for each processed packet
in process_backlog(), and read from other cpus performing
Out Of Order avoidance in get_rps_cpu()

Moving this field in a separate cache line keeps it mostly
hot for the cpu in process_backlog(), as other cpus will
only read it.

In a stress test, process_backlog() was consuming 6.80 % of cpu cycles,
and the patch reduced the cost to 0.65 %

Signed-off-by: Eric Dumazet 
---
 include/linux/netdevice.h |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 18d8394f2e5d..934ca866562d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2747,11 +2747,15 @@ struct softnet_data {
struct sk_buff  *completion_queue;
 
 #ifdef CONFIG_RPS
-   /* Elements below can be accessed between CPUs for RPS */
+   /* input_queue_head should be written by cpu owning this struct,
+* and only read by other cpus. Worth using a cache line.
+*/
+   unsigned intinput_queue_head cacheline_aligned_in_smp;
+
+   /* Elements below can be accessed between CPUs for RPS/RFS */
struct call_single_data csd cacheline_aligned_in_smp;
struct softnet_data *rps_ipi_next;
unsigned intcpu;
-   unsigned intinput_queue_head;
unsigned intinput_queue_tail;
 #endif
unsigned intdropped;

[GIT] Networking

[David Miller]

1) Handle v4/v6 mixed sockets properly in soreuseport, from Craig Gallak.

2) Bug fixes for the new macsec facility (missing kmalloc NULL checks,
   missing locking around netdev list traversal, etc.) from Sabrina
   Dubroca.

3) Fix handling of host routes on ifdown in ipv6, from David Ahern.

4) Fix double-fdput in bpf verifier.  From Jann Horn.

Please pull, thanks a lot!

The following changes since commit 5f44abd041c5f3be76d57579ab254d78e601315b:

  Merge tag 'rtc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux (2016-04-21 
15:41:13 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 8358b02bf67d3a5d8a825070e1aa73f25fb2e4c7:

  bpf: fix double-fdput in replace_map_fd_with_map_ptr() (2016-04-26 17:37:21 
-0400)


David Ahern (1):
  net: ipv6: Delete host routes on an ifdown

David S. Miller (5):
  Merge branch 'bridge-mdb-fixes'
  Merge branch 'macsec-fixes'
  Merge branch 'mlx5-fixes'
  ipv6: Revert optional address flusing on ifdown.
  Revert "ipv6: Revert optional address flusing on ifdown."

Elad Raz (3):
  switchdev: Adding complete operation to deferred switchdev ops
  bridge: mdb: Common function for mdb entry translation
  bridge: mdb: Marking port-group as offloaded

Eli Cohen (1):
  net/mlx5_core: Remove static from local variable

Eric Dumazet (1):
  net/mlx4_en: fix spurious timestamping callbacks

Grygorii Strashko (1):
  MAINTAINERS: net: add entry for TI Ethernet Switch drivers

Ivan Babrou (1):
  net: dummy: remove note about being Y by default

Jann Horn (1):
  bpf: fix double-fdput in replace_map_fd_with_map_ptr()

Jiri Benc (1):
  cxgbi: fix uninitialized flowi6

Majd Dibbiny (2):
  net/mlx5_core: Add ConnectX-5 to list of supported devices
  net/mlx5: Add pci shutdown callback

Manish Chopra (1):
  qlcnic: Update version to 5.3.64

Maor Gottlieb (1):
  net/mlx5_core: Fix soft lockup in steering error flow

Marek Vasut (1):
  net: stmmac: socfpga: Remove re-registration of reset controller

Paolo Abeni (1):
  ipv4/fib: don't warn when primary address is missing if in_dev is dead

Rana Shahout (1):
  net/mlx5e: Fix MLX5E_100BASE_T define

Sabrina Dubroca (9):
  macsec: add missing NULL check after kmalloc
  macsec: take rtnl lock before for_each_netdev
  macsec: don't put a NULL rxsa
  macsec: fix rx_sa refcounting with decrypt callback
  macsec: add consistency check to netlink dumps
  macsec: fix memory leaks around rx_handler (un)registration
  macsec: fix SA leak if initialization fails
  macsec: add missing macsec prefix in uapi
  macsec: fix netlink attribute validation

Saeed Mahameed (3):
  net/mlx5e: Device's mtu field is u16 and not int
  net/mlx5e: Fix minimum MTU
  net/mlx5e: Use vport MTU rather than physical port MTU

 MAINTAINERS  |   9 +
 drivers/infiniband/hw/mlx5/main.c|   4 +--
 drivers/net/Kconfig  |   5 ++-
 drivers/net/ethernet/mellanox/mlx4/en_tx.c   |   6 ++--
 drivers/net/ethernet/mellanox/mlx5/core/en.h |   2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c |   8 ++---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c|  72 
+
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c|  48 
++---
 drivers/net/ethernet/mellanox/mlx5/core/main.c   |  25 ++---
 drivers/net/ethernet/mellanox/mlx5/core/port.c   |  10 +++---
 drivers/net/ethernet/mellanox/mlx5/core/vport.c  |  40 
+
 drivers/net/ethernet/qlogic/qlcnic/qlcnic.h  |   4 +--
 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c  |  50 
+-
 drivers/net/macsec.c |  65 
++
 drivers/scsi/cxgbi/libcxgbi.c|   1 +
 include/linux/mlx5/driver.h  |   7 ++--
 include/linux/mlx5/port.h|   6 ++--
 include/linux/mlx5/vport.h   |   2 ++
 include/net/switchdev.h  |   4 +++
 include/uapi/linux/if_macsec.h   |   4 +--
 kernel/bpf/verifier.c|   1 -
 net/bridge/br_mdb.c  | 124 
+---
 net/bridge/br_multicast.c|   8 +++--
 net/bridge/br_private.h  |   4 +--
 net/ipv4/fib_frontend.c  |   6 +++-
 net/ipv6/addrconf.c  |  48 
-
 net/switchdev/switchdev.c|   6 
 27 files 

Darlehen anbieten. Kontaktieren Sie uns für weitere Informationen

[Kredit-Firma]

Guten Tag,
Wir möchten Sie darüber informieren, dass wir anbieten, Geschäftdarlehen, 
Projektfinanzierung und Immobilienfinanzierung bei 1% Jahreszins. Für weitere 
Informationen kontaktieren Sie uns bitte über unsere offizielle E-Mail: 
eurofinanc...@gmail.com. Sie sind verpflichtet, Ihre Kreditanfrage mit Ihren 
vollständigen Namen, den Kreditbetrag erforderlich, Darlehenslaufzeit und 
Adresse / Telefonnummer zu senden. Wir werden Ihnen die Darlehensbedingungen 
und die Rückzahlung nach Erhalt Ihrer E-Mail senden. Bitte haben Sie Ihren 
Kreditantrag über unsere offizielle E-Mail einreichen: eurofinanc...@gmail.com. 
Grüße, Josef Pani
Este mensaje (y sus adjuntos), en adelante mensaje, ha sido enviado 
exclusivamente a su(s) destinatario(s) y es confidencial. Si usted recibe este 
mensaje por error, por favor b��rrelo y comunique inmediatamente al remitente. 
Toda utilizaci��n o publicaci��n, total o parcial, queda prohibida salvo 
autorizaci��n expresa. El MEDUCA no podr�� ser considerado responsable si el 
mensaje ha sido modificado y/o utilizado sin autorizaci��n. This message (and 
any attachments), are confidential intended solely for the people whose 
addresses appear. If you have received this message by error, please delete it 
and immediately notify the sender. Any use, dissemination or disclosure, either 
whole or partial, without formal approval is prohibited. The MEDUCA will not 
therefore be liable for the message if modified and/or used without approval.

Quote Request

[Al Waleed Co.]

Hi,

My name is Al Waleed From Al Waleed trading company Dubai we got you 
recommendation from one of your customer, so we decided to order a product from 
you.

Kindly get back to us if you can ship to us in Dubai so that we can get back to 
you with our products needed from you and other requirement Looking forward 
hearing back from you

Thank you,

Al Waleed trading company
Customer Service

Quote Request

[Al Waleed Co.]

Hi,

My name is Al Waleed From Al Waleed trading company Dubai we got you 
recommendation from one of your customer, so we decided to order a product from 
you.

Kindly get back to us if you can ship to us in Dubai so that we can get back to 
you with our products needed from you and other requirement Looking forward 
hearing back from you

Thank you,

Al Waleed trading company
Customer Service

Quote Request

[Al Waleed Co.]

Hi,

My name is Al Waleed From Al Waleed trading company Dubai we got you 
recommendation from one of your customer, so we decided to order a product from 
you.

Kindly get back to us if you can ship to us in Dubai so that we can get back to 
you with our products needed from you and other requirement Looking forward 
hearing back from you

Thank you,

Al Waleed trading company
Customer Service

Re: [PATCH -next] pch_gbe: fix bogus trylock conversion

[David Miller]

From: Florian Westphal 
Date: Tue, 26 Apr 2016 23:14:30 +0200

> Should have converted 'if (trylock)' to 'lock'.
> 
> Fixes: a6086a893718db ("drivers: net: remove NETDEV_TX_LOCKED")
> Signed-off-by: Florian Westphal 
> ---
>  I re-checked the series and this was the only place where I messed up.

Applied.

Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

[David Miller]

From: Saeed Mahameed 
Date: Tue, 26 Apr 2016 23:55:03 +0300

> It will be a nightmare to rollback in such case.  What if the rollback failed 
> ?

It is absolutely essential to handle this properly.

Which means you must have a prepare/commit model, wherein the prepare
phase makes sure to pre-allocate all necessary resources, and only if
all the prepare phase preparations succeed will the commit phase run.

The commit phase cannot error, because all of the resources have been
allocated successfully already.

This way there are no issues of "rolling back" because you never
actually move the state forward until you can guarantee that you can
do everything.

Re: [PATCH] bpf: fix double-fdput in replace_map_fd_with_map_ptr()

[David Miller]

From: Jann Horn 
Date: Tue, 26 Apr 2016 22:26:26 +0200

> When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode
> references a non-map file descriptor as a map file descriptor, the error
> handling code called fdput() twice instead of once (in __bpf_map_get() and
> in replace_map_fd_with_map_ptr()). If the file descriptor table of the
> current task is shared, this causes f_count to be decremented too much,
> allowing the struct file to be freed while it is still in use
> (use-after-free). This can be exploited to gain root privileges by an
> unprivileged user.
> 
> This bug was introduced in
> commit 0246e64d9a5f ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only
> exploitable since
> commit 1be7f75d1668 ("bpf: enable non-root eBPF programs") because
> previously, CAP_SYS_ADMIN was required to reach the vulnerable code.
> 
> (posted publicly according to request by maintainer)
> 
> Signed-off-by: Jann Horn 
> Signed-off-by: Linus Torvalds 

Applied and queued up for -stable, thanks Jann.

Re: [PATCH net-next] macvlan: fix failure during registration v3

[Mahesh Bandewar]

[...]
>> > -destroy_port:
>> > -   port->count -= 1;
>> > -   if (!port->count)
>> > -   macvlan_port_destroy(lowerdev);
>> I think you still need this when it fails netdev_upper_dev_link(). The
>> only thing you should remove is the label.
>
> I don't think so. I think the double decrement also occurred in this case.
> unregister_netdevice invokes rollback_registered/macvlan_uninit
> which does the decrement.
>
I thought macvlan_port_destroy() does not get called but it is called
from macvlan_uninit(). So it's all good. Thanks.

> Thanks,
> Francesco
>
>> >
>> > return err;
>> >  }
>> > --
>> > 1.8.1.4
>> >

[PATCH net-next 0/5] stmmac: dwmac-socfpga refactor+cleanup

[Joachim Eastwood]

This patch aims to remove the init/exit callbacks from the dwmac-
socfpga driver and instead use standard PM callbacks. Doing this
will also allow us to cleanup the driver.

Eventually the init/exit callbacks will be deprecated and removed
from all drivers dwmac-* except for dwmac-generic. Drivers will be
refactored to use standard PM and remove callbacks.

This patch set should not change the behavior of the driver itself,
it only moves code around. The only exception to this is patch
number 4 which restores the resume callback behavior which was
changed in the "net: stmmac: socfpga: Remove re-registration of
reset controller" patch. I belive calling phy_resume() only
from the resume callback and not probe is the right thing to do.


Couple of heads-up here:
 1. This patch set depend on Marek's "Remove re-registration of
reset controller" patch [1] which is not in net-next yet.
Without that patch this set will not apply!

 2. The first patch changes the prototype of a couple of
functions used in Alexandre's "add Ethernet glue logic for
stm32 chip" patch [2] and will cause build failures for
dwmac-stm32.c if not fixed up!
If Alexandre's patch set is applied first I will gladly
rebase my patch set to account for his driver as well.

So at the moment there are issues here :/

I guess one way of handing this would just be wait for all
the bits to come together in net-next and resend.

Dave: Please let me know if you have any preferred way of
  handling this.


[1] https://patchwork.ozlabs.org/patch/613085/
[2] https://patchwork.ozlabs.org/patch/614405/


Joachim Eastwood (5):
  stmmac: let remove/resume/suspend functions take device pointer
  stmmac: dwmac-socfpga: add PM ops and resume function
  stmmac: dwmac-socfpga: keep a copy of stmmac_rst in driver priv data
  stmmac: dwmac-socfpga: call phy_resume() only in resume callback
  stmmac: dwmac-socfpga: kill init() and rename setup() to set_phy_mode()

 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 106 +++--
 drivers/net/ethernet/stmicro/stmmac/stmmac.h   |   6 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  15 +--
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c   |  24 +
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   6 +-
 5 files changed, 71 insertions(+), 86 deletions(-)

-- 
2.8.0

[PATCH net-next 1/5] stmmac: let remove/resume/suspend functions take device pointer

[Joachim Eastwood]

Change stmmac_remove/resume/suspend to take a device pointer so
they can be used directly by drivers that doesn't need to perform
anything device specific.

This lets us remove the PCI pm functions and later simplifiy the
platform drivers.

Signed-off-by: Joachim Eastwood 
Tested-by: Marek Vasut 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h   |  6 +++---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 15 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c   | 24 ++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  6 +++---
 4 files changed, 17 insertions(+), 34 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index ff67506..59ae608 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -148,9 +148,9 @@ void stmmac_set_ethtool_ops(struct net_device *netdev);
 
 int stmmac_ptp_register(struct stmmac_priv *priv);
 void stmmac_ptp_unregister(struct stmmac_priv *priv);
-int stmmac_resume(struct net_device *ndev);
-int stmmac_suspend(struct net_device *ndev);
-int stmmac_dvr_remove(struct net_device *ndev);
+int stmmac_resume(struct device *dev);
+int stmmac_suspend(struct device *dev);
+int stmmac_dvr_remove(struct device *dev);
 int stmmac_dvr_probe(struct device *device,
 struct plat_stmmacenet_data *plat_dat,
 struct stmmac_resources *res);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b87edb7..fd5ab7b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3350,12 +3350,13 @@ EXPORT_SYMBOL_GPL(stmmac_dvr_probe);
 
 /**
  * stmmac_dvr_remove
- * @ndev: net device pointer
+ * @dev: device pointer
  * Description: this function resets the TX/RX processes, disables the MAC 
RX/TX
  * changes the link status, releases the DMA descriptor rings.
  */
-int stmmac_dvr_remove(struct net_device *ndev)
+int stmmac_dvr_remove(struct device *dev)
 {
+   struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
 
pr_info("%s:\n\tremoving driver", __func__);
@@ -3381,13 +3382,14 @@ EXPORT_SYMBOL_GPL(stmmac_dvr_remove);
 
 /**
  * stmmac_suspend - suspend callback
- * @ndev: net device pointer
+ * @dev: device pointer
  * Description: this is the function to suspend the device and it is called
  * by the platform driver to stop the network queue, release the resources,
  * program the PMT register (for WoL), clean and release driver resources.
  */
-int stmmac_suspend(struct net_device *ndev)
+int stmmac_suspend(struct device *dev)
 {
+   struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned long flags;
 
@@ -3430,12 +3432,13 @@ EXPORT_SYMBOL_GPL(stmmac_suspend);
 
 /**
  * stmmac_resume - resume callback
- * @ndev: net device pointer
+ * @dev: device pointer
  * Description: when resume this function is invoked to setup the DMA and CORE
  * in a usable state.
  */
-int stmmac_resume(struct net_device *ndev)
+int stmmac_resume(struct device *dev)
 {
+   struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned long flags;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index ae43887..56c8a23 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -231,30 +231,10 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
  */
 static void stmmac_pci_remove(struct pci_dev *pdev)
 {
-   struct net_device *ndev = pci_get_drvdata(pdev);
-
-   stmmac_dvr_remove(ndev);
-}
-
-#ifdef CONFIG_PM_SLEEP
-static int stmmac_pci_suspend(struct device *dev)
-{
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *ndev = pci_get_drvdata(pdev);
-
-   return stmmac_suspend(ndev);
-}
-
-static int stmmac_pci_resume(struct device *dev)
-{
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct net_device *ndev = pci_get_drvdata(pdev);
-
-   return stmmac_resume(ndev);
+   stmmac_dvr_remove(>dev);
 }
-#endif
 
-static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_pci_suspend, stmmac_pci_resume);
+static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
 
 #define STMMAC_VENDOR_ID 0x700
 #define STMMAC_QUARK_ID  0x0937
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index effaa4f..409db91 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -386,7 +386,7 @@ int stmmac_pltfr_remove(struct platform_device *pdev)
 {
struct net_device 

[PATCH net-next 2/5] stmmac: dwmac-socfpga: add PM ops and resume function

[Joachim Eastwood]

Implement the needed PM callbacks in the driver instead of
relying on the init/exit hooks in stmmac_platform. This gives
the driver more flexibility in how the code is organized.

Eventually the init/exit callbacks will be deprecated in favor
of the standard PM callbacks and driver remove function.

Signed-off-by: Joachim Eastwood 
Tested-by: Marek Vasut 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 784eb53..789013a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -261,7 +261,6 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
}
 
plat_dat->bsp_priv = dwmac;
-   plat_dat->init = socfpga_dwmac_init;
plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
 
ret = stmmac_dvr_probe(>dev, plat_dat, _res);
@@ -271,6 +270,21 @@ static int socfpga_dwmac_probe(struct platform_device 
*pdev)
return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int socfpga_dwmac_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct net_device *ndev = dev_get_drvdata(dev);
+   struct stmmac_priv *priv = netdev_priv(ndev);
+
+   socfpga_dwmac_init(pdev, priv->plat->bsp_priv);
+
+   return stmmac_resume(dev);
+}
+#endif /* CONFIG_PM_SLEEP */
+
+SIMPLE_DEV_PM_OPS(socfpga_dwmac_pm_ops, stmmac_suspend, socfpga_dwmac_resume);
+
 static const struct of_device_id socfpga_dwmac_match[] = {
{ .compatible = "altr,socfpga-stmmac" },
{ }
@@ -282,7 +296,7 @@ static struct platform_driver socfpga_dwmac_driver = {
.remove = stmmac_pltfr_remove,
.driver = {
.name   = "socfpga-dwmac",
-   .pm = _pltfr_pm_ops,
+   .pm = _dwmac_pm_ops,
.of_match_table = socfpga_dwmac_match,
},
 };
-- 
2.8.0

[PATCH net-next 5/5] stmmac: dwmac-socfpga: kill init() and rename setup() to set_phy_mode()

[Joachim Eastwood]

Remove old init callback which now contains only a call to
socfpga_dwmac_setup(). Also rename socfpga_dwmac_setup() to indicate
what the function really does.

Signed-off-by: Joachim Eastwood 
Tested-by: Marek Vasut 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index ba49d8c..cd9764a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -136,7 +136,7 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac 
*dwmac, struct device *
return 0;
 }
 
-static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
+static int socfpga_dwmac_set_phy_mode(struct socfpga_dwmac *dwmac)
 {
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
int phymode = dwmac->interface;
@@ -195,16 +195,6 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
return 0;
 }
 
-static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
-{
-   struct socfpga_dwmac *dwmac = priv;
-
-   /* Setup the phy mode in the system manager registers according to
-* devicetree configuration
-*/
-   return socfpga_dwmac_setup(dwmac);
-}
-
 static int socfpga_dwmac_probe(struct platform_device *pdev)
 {
struct plat_stmmacenet_data *plat_dat;
@@ -245,7 +235,7 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
 */
dwmac->stmmac_rst = stpriv->stmmac_rst;
 
-   ret = socfpga_dwmac_init(pdev, dwmac);
+   ret = socfpga_dwmac_set_phy_mode(dwmac);
}
 
return ret;
@@ -254,11 +244,10 @@ static int socfpga_dwmac_probe(struct platform_device 
*pdev)
 #ifdef CONFIG_PM_SLEEP
 static int socfpga_dwmac_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
 
-   socfpga_dwmac_init(pdev, priv->plat->bsp_priv);
+   socfpga_dwmac_set_phy_mode(priv->plat->bsp_priv);
 
/* Before the enet controller is suspended, the phy is suspended.
 * This causes the phy clock to be gated. The enet controller is
-- 
2.8.0

[PATCH net-next 4/5] stmmac: dwmac-socfpga: call phy_resume() only in resume callback

[Joachim Eastwood]

Calling phy_resume() should only be need during driver resume to
workaround a hardware errata.

Signed-off-by: Joachim Eastwood 
Tested-by: Marek Vasut 
---
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 50 --
 1 file changed, 19 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index ba0b793..ba49d8c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -198,41 +198,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac 
*dwmac)
 static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
 {
struct socfpga_dwmac *dwmac = priv;
-   struct net_device *ndev = platform_get_drvdata(pdev);
-   struct stmmac_priv *stpriv = NULL;
-   int ret = 0;
-
-   if (!ndev)
-   return -EINVAL;
-
-   stpriv = netdev_priv(ndev);
-   if (!stpriv)
-   return -EINVAL;
 
/* Setup the phy mode in the system manager registers according to
 * devicetree configuration
 */
-   ret = socfpga_dwmac_setup(dwmac);
-
-   /* Before the enet controller is suspended, the phy is suspended.
-* This causes the phy clock to be gated. The enet controller is
-* resumed before the phy, so the clock is still gated "off" when
-* the enet controller is resumed. This code makes sure the phy
-* is "resumed" before reinitializing the enet controller since
-* the enet controller depends on an active phy clock to complete
-* a DMA reset. A DMA reset will "time out" if executed
-* with no phy clock input on the Synopsys enet controller.
-* Verified through Synopsys Case #8000711656.
-*
-* Note that the phy clock is also gated when the phy is isolated.
-* Phy "suspend" and "isolate" controls are located in phy basic
-* control register 0, and can be modified by the phy driver
-* framework.
-*/
-   if (stpriv->phydev)
-   phy_resume(stpriv->phydev);
-
-   return ret;
+   return socfpga_dwmac_setup(dwmac);
 }
 
 static int socfpga_dwmac_probe(struct platform_device *pdev)
@@ -290,6 +260,24 @@ static int socfpga_dwmac_resume(struct device *dev)
 
socfpga_dwmac_init(pdev, priv->plat->bsp_priv);
 
+   /* Before the enet controller is suspended, the phy is suspended.
+* This causes the phy clock to be gated. The enet controller is
+* resumed before the phy, so the clock is still gated "off" when
+* the enet controller is resumed. This code makes sure the phy
+* is "resumed" before reinitializing the enet controller since
+* the enet controller depends on an active phy clock to complete
+* a DMA reset. A DMA reset will "time out" if executed
+* with no phy clock input on the Synopsys enet controller.
+* Verified through Synopsys Case #8000711656.
+*
+* Note that the phy clock is also gated when the phy is isolated.
+* Phy "suspend" and "isolate" controls are located in phy basic
+* control register 0, and can be modified by the phy driver
+* framework.
+*/
+   if (priv->phydev)
+   phy_resume(priv->phydev);
+
return stmmac_resume(dev);
 }
 #endif /* CONFIG_PM_SLEEP */
-- 
2.8.0

[PATCH net-next 3/5] stmmac: dwmac-socfpga: keep a copy of stmmac_rst in driver priv data

[Joachim Eastwood]

The dwmac-socfpga driver needs to control the reset usually managed
by the core driver to set the PHY mode. Take a copy of the reset
handle from core priv data so it can be used by the driver later.

This also allow us to move reset handling into socfpga_dwmac_setup()
where the code that needs it is located.

Signed-off-by: Joachim Eastwood 
Tested-by: Marek Vasut 
---
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 33 ++
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 789013a..ba0b793 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -49,6 +49,7 @@ struct socfpga_dwmac {
u32 reg_shift;
struct  device *dev;
struct regmap *sys_mgr_base_addr;
+   struct reset_control *stmmac_rst;
void __iomem *splitter_base;
bool f2h_ptp_ref_clk;
 };
@@ -164,6 +165,10 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
if (dwmac->splitter_base)
val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
 
+   /* Assert reset to the enet controller before changing the phy mode */
+   if (dwmac->stmmac_rst)
+   reset_control_assert(dwmac->stmmac_rst);
+
regmap_read(sys_mgr_base_addr, reg_offset, );
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
ctrl |= val << reg_shift;
@@ -181,6 +186,12 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
 
regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
 
+   /* Deassert reset for the phy configuration to be sampled by
+* the enet controller, and operation to start in requested mode
+*/
+   if (dwmac->stmmac_rst)
+   reset_control_deassert(dwmac->stmmac_rst);
+
return 0;
 }
 
@@ -198,21 +209,11 @@ static int socfpga_dwmac_init(struct platform_device 
*pdev, void *priv)
if (!stpriv)
return -EINVAL;
 
-   /* Assert reset to the enet controller before changing the phy mode */
-   if (stpriv->stmmac_rst)
-   reset_control_assert(stpriv->stmmac_rst);
-
/* Setup the phy mode in the system manager registers according to
 * devicetree configuration
 */
ret = socfpga_dwmac_setup(dwmac);
 
-   /* Deassert reset for the phy configuration to be sampled by
-* the enet controller, and operation to start in requested mode
-*/
-   if (stpriv->stmmac_rst)
-   reset_control_deassert(stpriv->stmmac_rst);
-
/* Before the enet controller is suspended, the phy is suspended.
 * This causes the phy clock to be gated. The enet controller is
 * resumed before the phy, so the clock is still gated "off" when
@@ -264,8 +265,18 @@ static int socfpga_dwmac_probe(struct platform_device 
*pdev)
plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
 
ret = stmmac_dvr_probe(>dev, plat_dat, _res);
-   if (!ret)
+   if (!ret) {
+   struct net_device *ndev = platform_get_drvdata(pdev);
+   struct stmmac_priv *stpriv = netdev_priv(ndev);
+
+   /* The socfpga driver needs to control the stmmac reset to
+* set the phy mode. Create a copy of the core reset handel
+* so it can be used by the driver later.
+*/
+   dwmac->stmmac_rst = stpriv->stmmac_rst;
+
ret = socfpga_dwmac_init(pdev, dwmac);
+   }
 
return ret;
 }
-- 
2.8.0

Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller

[Joachim Eastwood]

On 26 April 2016 at 14:47, Marek Vasut  wrote:
> On 04/26/2016 02:26 PM, Joachim Eastwood wrote:
>> On 26 April 2016 at 00:55, Marek Vasut  wrote:
>>> On 04/25/2016 08:11 PM, Joachim Eastwood wrote:
 On 21 April 2016 at 14:11, Marek Vasut  wrote:
>
> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
> since the functionality is already performed by the stmmac core.

 I am trying to rebase my changes on top of your two patches and
 noticed a couple of things.

>  static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>  {
> -   struct socfpga_dwmac*dwmac = priv;
> +   struct socfpga_dwmac *dwmac = priv;
> struct net_device *ndev = platform_get_drvdata(pdev);
> struct stmmac_priv *stpriv = NULL;
> int ret = 0;
>
> -   if (ndev)
> -   stpriv = netdev_priv(ndev);
> +   if (!ndev)
> +   return -EINVAL;

 ndev can never be NULL here. socfpga_dwmac_init() is only called if
 stmmac_dvr_probe() succeeds or we are running the resume callback. So
 I don't see how this could ever be NULL.
>>>
>>> That's a good point, this check can indeed be removed. While you're at
>>> the patching, can you remove this one ?
>>
>> Yes, my patch will refactor the init() function so this will go away.
>
> Thanks!
>
> +
> +   stpriv = netdev_priv(ndev);

 It's not really nice to access 'stmmac_priv' as it should be private
 to the core driver, but I don't see any other good solution right now.
>>>
>>> I guess some stmmac_reset_assert() wrapper would be nicer, yes. What do
>>> you think ?
>>>
> +   if (!stpriv)
> +   return -EINVAL;
>
> /* Assert reset to the enet controller before changing the phy 
> mode */
> -   if (dwmac->stmmac_rst)
> -   reset_control_assert(dwmac->stmmac_rst);
> +   if (stpriv->stmmac_rst)
> +   reset_control_assert(stpriv->stmmac_rst);
>
> /* Setup the phy mode in the system manager registers according to
>  * devicetree configuration
> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device 
> *pdev, void *priv)
> /* Deassert reset for the phy configuration to be sampled by
>  * the enet controller, and operation to start in requested mode
>  */
> -   if (dwmac->stmmac_rst)
> -   reset_control_deassert(dwmac->stmmac_rst);
> +   if (stpriv->stmmac_rst)
> +   reset_control_deassert(stpriv->stmmac_rst);
>
> /* Before the enet controller is suspended, the phy is suspended.
>  * This causes the phy clock to be gated. The enet controller is
> @@ -245,7 +228,7 @@ static int socfpga_dwmac_init(struct platform_device 
> *pdev, void *priv)
>  * control register 0, and can be modified by the phy driver
>  * framework.
>  */
> -   if (stpriv && stpriv->phydev)
> +   if (stpriv->phydev)
> phy_resume(stpriv->phydev);

 Before this change phy_resume() was only called during driver resume
 when , but your patches cause phy_resume() to called at probe time as
 well. Is this okey?
>>>
>>> I _hope_ it's OK. The cryptic comment above is not very helpful in this
>>> aspect. Dinh ? :)
>>
>> My patches will move phy_resume() to the resume callback so it
>> preserves the previous behavior. But if someone knows more about this
>> that would be useful.
>>
>>
>>> btw I wish you reviewed my patch a bit earlier to catch these bits.
>>
>> Sorry, about that. I have been really busy with other things lately.
>
> Oh I'm real happy someone is doing the refactoring :) I appreciate your
> work, sorry if that was unclear.
>
>> My patches based on next from Friday can be found here now:
>> https://github.com/manabian/linux-lpc/tree/net-socfpga-dwmac-on-next
>>
>> I had to add your latest patch as well since the next version I used
>> didn't have it. I'll post the patches on netdev later today or
>> tomorrow.
>
> Looks like next wasn't synced for a few days, yeah.
>
> You can add my:
>
> On SoCFPGA Cyclone V SoC (DENX MCVEVK):
> Tested-by: Marek Vasut 
>
> to those patches

Excellent. Thanks Marek.

btw, did you also test suspend/resume?


regards,
Joachim Eastwood

[PATCH -next] pch_gbe: fix bogus trylock conversion

[Florian Westphal]

Should have converted 'if (trylock)' to 'lock'.

Fixes: a6086a893718db ("drivers: net: remove NETDEV_TX_LOCKED")
Signed-off-by: Florian Westphal 
---
 I re-checked the series and this was the only place where I messed up.

diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c 
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 4475dcc..ca4add7 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -2137,7 +2137,7 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, struct 
net_device *netdev)
struct pch_gbe_tx_ring *tx_ring = adapter->tx_ring;
unsigned long flags;
 
-   spin_trylock_irqsave(_ring->tx_lock, flags);
+   spin_lock_irqsave(_ring->tx_lock, flags);
 
if (unlikely(!PCH_GBE_DESC_UNUSED(tx_ring))) {
netif_stop_queue(netdev);
-- 
2.7.3

Re: [net-next PATCH 6/8] mlx4: Add support for inner IPv6 checksum offloads and TSO

[Alexander Duyck]

On Tue, Apr 26, 2016 at 1:23 PM, Saeed Mahameed
 wrote:
> On Tue, Apr 26, 2016 at 6:50 PM, Alex Duyck  wrote:
>>
>> The setup is pretty straight forward.  Basically I left the first port
>> in the default namespace and moved the second int a secondary
>> namespace referred to below as $netns.  I then assigned the IPv6
>> addresses fec0::10:1 and fec0::10:2. After that I ran the following:
>>
>> VXLAN=vx$net
>> echo $VXLAN ${test_options[$i]}
>> ip link add $VXLAN type vxlan id $net \
>> local fec0::10:1 remote $addr6 dev $PF0 \
>> ${test_options[$i]} dstport `expr 8800 + $net`
>> ip netns exec $netns ip link add $VXLAN type vxlan id $net \
>>   local $addr6 remote fec0::10:1 dev $port \
>>   ${test_options[$i]} dstport `expr 8800 + 
>> $net`
>> ifconfig $VXLAN 192.168.${net}.1/24
>> ip netns exec $netns ifconfig $VXLAN 192.168.${net}.2/24
>>
>
> Thanks, indeed i see that GSO is not working with vxlan over IPv6 over
> mlx5 device.
> We will test out those patches on both mlx4 and mlx5, and debug mlx4
> IPv6 issue you see.
>
>>
>>> Anyway, I suspect it might be related to a driver bug most likely in
>>> get_real_size function @en_tx.c
>>> specifically in : *lso_header_size = (skb_inner_transport_header(skb) -
>>> skb->data) + inner_tcp_hdrlen(skb);
>>>
>>> will check this and get back to you.
>>
>> I'm not entirely convinced.  What I was seeing is t hat the hardware
>> itself was performing Rx checksum offload only on tunnels with an
>> outer IPv4 header and ignoring tunnels with an outer IPv6 header.
>
> I don't get it, are you trying to say that the issue is in the RX side ?
> what do you mean by ignoring ? Dropping ? or just not validating checksum ?
> if so why would you disable GSO and IPv6 checksumming on TX ?

I'm suspecting that whatever parsing logic exists in either the
hardware or firmware may not be configured to parse tunnels with outer
IPv6 headers.  The tell-tale sign is what occurs with an IPv6 based
tunnel with no outer checksum.  The hardware is not performing a
checksum on the inner headers so it reports it as a UDP frame with no
checksum to the stack which ends up preventing us from doing GRO.
That tells me that the hardware is not parsing IPv6 based tunnels on
Rx.  I am assuming that if the Rx side doesn't work then there is a
good chance that the Tx won't.

   @@ -2431,7 +2435,18 @@ static netdev_features_t
 mlx4_en_features_check(struct sk_buff *skb,
 netdev_features_t
 features)
   {
 features = vlan_features_check(skb, features);
 -   return vxlan_features_check(skb, features);
 +   features = vxlan_features_check(skb, features);
 +
 +   /* The ConnectX-3 doesn't support outer IPv6 checksums but it does
 +* support inner IPv6 checksums and segmentation so  we need to
 +* strip that feature if this is an IPv6 encapsulated frame.
 +*/
 +   if (skb->encapsulation &&
 +   (skb->ip_summed == CHECKSUM_PARTIAL) &&
 +   (ip_hdr(skb)->version != 4))
 +   features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
>>>
>>> Dejavu, didn't you fix this already in harmonize_features, in
>>> i.e, it is enough to do here:
>>>
>>> if (skb->encapsulation && (skb->ip_summed == CHECKSUM_PARTIAL))
>>> features &= ~NETIF_F_IPV6_CSUM;
>>>
>>
>> So what this patch is doing is enabling an inner IPv6 header offloads.
>> Up above we set the NETIF_F_IPV6_CSUM bit and we want it to stay set
>> unless we have an outer IPv6 header because the inner headers may
>> still need that bit set.  If I did what you suggest it strips IPv6
>> checksum support for inner headers and if we have to use GSO partial I
>> ended up encountering some of the other bugs that I have fixed for GSO
>> partial where either sg or csum are not defined.
>>
>
> I see, you mean that you want to disable checksumming and GSO only for
> packets with Outer(IPv6):Inner(X) and keep it in case for
> Outer(IPv4):Inner(IPv6)
> but i think it is weird that the driver decides to disable features it
> didn't declare in first place (NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK)
>
> Retry:
>
> if (skb->encapsulation && (skb->ip_summed == CHECKSUM_PARTIAL) &&
> (ip_hdr(skb)->version != 4))
> features &= ~NETIF_F_IPV6_CSUM;
>
> will this work ?

Sort of.  All that would happen is that you would fall through to
harmonize_features where NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK gets
cleared.  I just figured I would short-cut things since we cannot
support inner checksum or any GSO offloads if the tunnel has an outer
IPv6 header.  In addition this happens to effectively be the same code
I am using in vxlan_features_check to disable things if we cannot
checksum a protocol so it 

[net-next 12/15] i40e/i40evf: Only offload VLAN tag if enabled

[Jeff Kirsher]

From: Jesse Brandeburg 

The driver was offloading the VLAN tag into the skb
any time there was a VLAN tag and the hardware stripping was
enabled.  Just check to make sure it's enabled before put_tag.

Change-Id: Ife95290c06edd9a616393b38679923938b382241
Signed-off-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_txrx.c   | 3 ++-
 drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c 
b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 57af5f6..be51a28 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -1370,7 +1370,8 @@ static void i40e_receive_skb(struct i40e_ring *rx_ring,
 {
struct i40e_q_vector *q_vector = rx_ring->q_vector;
 
-   if (vlan_tag & VLAN_VID_MASK)
+   if ((rx_ring->netdev->features & NETIF_F_HW_VLAN_CTAG_RX) &&
+   (vlan_tag & VLAN_VID_MASK))
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);
 
napi_gro_receive(_vector->napi, skb);
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c 
b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index f101895..4633235 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -842,7 +842,8 @@ static void i40e_receive_skb(struct i40e_ring *rx_ring,
 {
struct i40e_q_vector *q_vector = rx_ring->q_vector;
 
-   if (vlan_tag & VLAN_VID_MASK)
+   if ((rx_ring->netdev->features & NETIF_F_HW_VLAN_CTAG_RX) &&
+   (vlan_tag & VLAN_VID_MASK))
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tag);
 
napi_gro_receive(_vector->napi, skb);
-- 
2.5.5

[net-next 10/15] i40e: Add DeviceID for X722 QSFP+

[Jeff Kirsher]

From: Kamil Krawczyk 

Change-ID: I1370fbc7774e815ac1ad56561e97488e829592fc
Signed-off-by: Kamil Krawczyk 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_common.c   | 1 +
 drivers/net/ethernet/intel/i40e/i40e_devids.h   | 1 +
 drivers/net/ethernet/intel/i40evf/i40e_common.c | 1 +
 drivers/net/ethernet/intel/i40evf/i40e_devids.h | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c 
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 34e86f5..1db4790 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -61,6 +61,7 @@ static i40e_status i40e_set_mac_type(struct i40e_hw *hw)
case I40E_DEV_ID_1G_BASE_T_X722:
case I40E_DEV_ID_10G_BASE_T_X722:
case I40E_DEV_ID_SFP_I_X722:
+   case I40E_DEV_ID_QSFP_I_X722:
hw->mac.type = I40E_MAC_X722;
break;
default:
diff --git a/drivers/net/ethernet/intel/i40e/i40e_devids.h 
b/drivers/net/ethernet/intel/i40e/i40e_devids.h
index dd4457d..d701861 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_devids.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_devids.h
@@ -45,6 +45,7 @@
 #define I40E_DEV_ID_1G_BASE_T_X722 0x37D1
 #define I40E_DEV_ID_10G_BASE_T_X7220x37D2
 #define I40E_DEV_ID_SFP_I_X722 0x37D3
+#define I40E_DEV_ID_QSFP_I_X7220x37D4
 
 #define i40e_is_40G_device(d)  ((d) == I40E_DEV_ID_QSFP_A  || \
 (d) == I40E_DEV_ID_QSFP_B  || \
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_common.c 
b/drivers/net/ethernet/intel/i40evf/i40e_common.c
index 4db0c03..8f64204 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_common.c
@@ -59,6 +59,7 @@ i40e_status i40e_set_mac_type(struct i40e_hw *hw)
case I40E_DEV_ID_1G_BASE_T_X722:
case I40E_DEV_ID_10G_BASE_T_X722:
case I40E_DEV_ID_SFP_I_X722:
+   case I40E_DEV_ID_QSFP_I_X722:
hw->mac.type = I40E_MAC_X722;
break;
case I40E_DEV_ID_X722_VF:
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_devids.h 
b/drivers/net/ethernet/intel/i40evf/i40e_devids.h
index 7023570..d34972b 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_devids.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_devids.h
@@ -45,6 +45,7 @@
 #define I40E_DEV_ID_1G_BASE_T_X722 0x37D1
 #define I40E_DEV_ID_10G_BASE_T_X7220x37D2
 #define I40E_DEV_ID_SFP_I_X722 0x37D3
+#define I40E_DEV_ID_QSFP_I_X7220x37D4
 #define I40E_DEV_ID_X722_VF0x37CD
 #define I40E_DEV_ID_X722_VF_HV 0x37D9
 
-- 
2.5.5

[net-next 09/15] i40e: Add device capability which defines if update is available

[Jeff Kirsher]

From: Michal Kosiarz 

Add device capability which defines if update is available and security
check is needed during update process.

Change-ID: I380787c878275e1df18b39198df3ee3666342282
Signed-off-by: Michal Kosiarz 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h   | 1 +
 drivers/net/ethernet/intel/i40e/i40e_common.c   | 6 ++
 drivers/net/ethernet/intel/i40e/i40e_type.h | 5 +
 drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h | 1 +
 drivers/net/ethernet/intel/i40evf/i40e_type.h   | 5 +
 5 files changed, 18 insertions(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h 
b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
index 8d5c65a..5179b3b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
@@ -429,6 +429,7 @@ struct i40e_aqc_list_capabilities_element_resp {
 #define I40E_AQ_CAP_ID_SDP 0x0062
 #define I40E_AQ_CAP_ID_MDIO0x0063
 #define I40E_AQ_CAP_ID_WSR_PROT0x0064
+#define I40E_AQ_CAP_ID_NVM_MGMT0x0080
 #define I40E_AQ_CAP_ID_FLEX10  0x00F1
 #define I40E_AQ_CAP_ID_CEM 0x00F2
 
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c 
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index f3c1d88..34e86f5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -3138,6 +3138,12 @@ static void i40e_parse_discover_capabilities(struct 
i40e_hw *hw, void *buff,
p->wr_csr_prot = (u64)number;
p->wr_csr_prot |= (u64)logical_id << 32;
break;
+   case I40E_AQ_CAP_ID_NVM_MGMT:
+   if (number & I40E_NVM_MGMT_SEC_REV_DISABLED)
+   p->sec_rev_disabled = true;
+   if (number & I40E_NVM_MGMT_UPDATE_DISABLED)
+   p->update_disabled = true;
+   break;
default:
break;
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h 
b/drivers/net/ethernet/intel/i40e/i40e_type.h
index bb57cd9..8aa14aa 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_type.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
@@ -275,6 +275,11 @@ struct i40e_hw_capabilities {
 #define I40E_FLEX10_STATUS_DCC_ERROR   0x1
 #define I40E_FLEX10_STATUS_VC_MODE 0x2
 
+   bool sec_rev_disabled;
+   bool update_disabled;
+#define I40E_NVM_MGMT_SEC_REV_DISABLED 0x1
+#define I40E_NVM_MGMT_UPDATE_DISABLED  0x2
+
bool mgmt_cem;
bool ieee_1588;
bool iwarp;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h 
b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
index aad8d62..1bcb8cf 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
@@ -426,6 +426,7 @@ struct i40e_aqc_list_capabilities_element_resp {
 #define I40E_AQ_CAP_ID_SDP 0x0062
 #define I40E_AQ_CAP_ID_MDIO0x0063
 #define I40E_AQ_CAP_ID_WSR_PROT0x0064
+#define I40E_AQ_CAP_ID_NVM_MGMT0x0080
 #define I40E_AQ_CAP_ID_FLEX10  0x00F1
 #define I40E_AQ_CAP_ID_CEM 0x00F2
 
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_type.h 
b/drivers/net/ethernet/intel/i40evf/i40e_type.h
index b720713..bfc97c2 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_type.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_type.h
@@ -258,6 +258,11 @@ struct i40e_hw_capabilities {
 #define I40E_FLEX10_STATUS_DCC_ERROR   0x1
 #define I40E_FLEX10_STATUS_VC_MODE 0x2
 
+   bool sec_rev_disabled;
+   bool update_disabled;
+#define I40E_NVM_MGMT_SEC_REV_DISABLED 0x1
+#define I40E_NVM_MGMT_UPDATE_DISABLED  0x2
+
bool mgmt_cem;
bool ieee_1588;
bool iwarp;
-- 
2.5.5

[net-next 04/15] i40evf: Don't Panic

[Jeff Kirsher]

From: Mitch Williams 

Under some circumstances the driver remove function may be called before
the driver is fully initialized. So we can't assume that we know where
our towel is at, or that all of the data structures are initialized.

To ensure that we don't panic, check that the vsi_res pointer is valid
before dereferencing it. Then drink beer and eat peanuts.

Change-ID: If697b4db57348e39f9538793e16aa755e3e1af03
Signed-off-by: Mitch Williams 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40evf/i40evf.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf.h 
b/drivers/net/ethernet/intel/i40evf/i40evf.h
index e657ecc..017c83b 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf.h
+++ b/drivers/net/ethernet/intel/i40evf/i40evf.h
@@ -256,8 +256,10 @@ struct i40evf_adapter {
bool netdev_registered;
bool link_up;
enum i40e_virtchnl_ops current_op;
-#define CLIENT_ENABLED(_a) ((_a)->vf_res->vf_offload_flags & \
-   I40E_VIRTCHNL_VF_OFFLOAD_IWARP)
+#define CLIENT_ENABLED(_a) ((_a)->vf_res ? \
+   (_a)->vf_res->vf_offload_flags & \
+   I40E_VIRTCHNL_VF_OFFLOAD_IWARP : \
+   0)
 #define RSS_AQ(_a) ((_a)->vf_res->vf_offload_flags & \
I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ)
 #define VLAN_ALLOWED(_a) ((_a)->vf_res->vf_offload_flags & \
-- 
2.5.5

[net-next 03/15] i40e: Add support for configuring VF RSS

[Jeff Kirsher]

From: Mitch Williams 

Add support for configuring RSS on behalf of the VFs. This removes the
burden of dealing with different hardware interfaces from the VF
drivers, allowing for better future compatibility.

Change-ID: Icea75d3f37241ee8e447be5779e5abb53ddf04c0
Signed-off-by: Mitch Williams 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e.h |   1 +
 drivers/net/ethernet/intel/i40e/i40e_main.c|  35 +++-
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 193 -
 3 files changed, 217 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e.h 
b/drivers/net/ethernet/intel/i40e/i40e.h
index d25b3be..e312adf 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -202,6 +202,7 @@ struct i40e_lump_tracking {
 
 #define I40E_HKEY_ARRAY_SIZE ((I40E_PFQF_HKEY_MAX_INDEX + 1) * 4)
 #define I40E_HLUT_ARRAY_SIZE ((I40E_PFQF_HLUT_MAX_INDEX + 1) * 4)
+#define I40E_VF_HLUT_ARRAY_SIZE ((I40E_VFQF_HLUT1_MAX_INDEX + 1) * 4)
 
 enum i40e_fd_stat_idx {
I40E_FD_STAT_ATR,
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ec94ad6c..39b3b56 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -8082,24 +8082,45 @@ static int i40e_config_rss_reg(struct i40e_vsi *vsi, 
const u8 *seed,
 {
struct i40e_pf *pf = vsi->back;
struct i40e_hw *hw = >hw;
+   u16 vf_id = vsi->vf_id;
u8 i;
 
/* Fill out hash function seed */
if (seed) {
u32 *seed_dw = (u32 *)seed;
 
-   for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
-   i40e_write_rx_ctl(hw, I40E_PFQF_HKEY(i), seed_dw[i]);
+   if (vsi->type == I40E_VSI_MAIN) {
+   for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
+   i40e_write_rx_ctl(hw, I40E_PFQF_HKEY(i),
+ seed_dw[i]);
+   } else if (vsi->type == I40E_VSI_SRIOV) {
+   for (i = 0; i <= I40E_VFQF_HKEY1_MAX_INDEX; i++)
+   i40e_write_rx_ctl(hw,
+ I40E_VFQF_HKEY1(i, vf_id),
+ seed_dw[i]);
+   } else {
+   dev_err(>pdev->dev, "Cannot set RSS seed - invalid 
VSI type\n");
+   }
}
 
if (lut) {
u32 *lut_dw = (u32 *)lut;
 
-   if (lut_size != I40E_HLUT_ARRAY_SIZE)
-   return -EINVAL;
-
-   for (i = 0; i <= I40E_PFQF_HLUT_MAX_INDEX; i++)
-   wr32(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
+   if (vsi->type == I40E_VSI_MAIN) {
+   if (lut_size != I40E_HLUT_ARRAY_SIZE)
+   return -EINVAL;
+   for (i = 0; i <= I40E_PFQF_HLUT_MAX_INDEX; i++)
+   wr32(hw, I40E_PFQF_HLUT(i), lut_dw[i]);
+   } else if (vsi->type == I40E_VSI_SRIOV) {
+   if (lut_size != I40E_VF_HLUT_ARRAY_SIZE)
+   return -EINVAL;
+   for (i = 0; i <= I40E_VFQF_HLUT_MAX_INDEX; i++)
+   i40e_write_rx_ctl(hw,
+ I40E_VFQF_HLUT1(i, vf_id),
+ lut_dw[i]);
+   } else {
+   dev_err(>pdev->dev, "Cannot set RSS LUT - invalid 
VSI type\n");
+   }
}
i40e_flush(hw);
 
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 30f8cbe..c364588 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1348,12 +1348,16 @@ static int i40e_vc_get_vf_resources_msg(struct i40e_vf 
*vf, u8 *msg)
set_bit(I40E_VF_STAT_IWARPENA, >vf_states);
}
 
-   if (pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
-   if (vf->driver_caps & I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ)
-   vfres->vf_offload_flags |=
-   I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ;
+   if (vf->driver_caps & I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF) {
+   vfres->vf_offload_flags |= I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF;
} else {
-   vfres->vf_offload_flags |= I40E_VIRTCHNL_VF_OFFLOAD_RSS_REG;
+   if ((pf->flags & I40E_FLAG_RSS_AQ_CAPABLE) &&
+   (vf->driver_caps & I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ))
+   vfres->vf_offload_flags |=
+   

[net-next 08/15] i40e: Allow user to change input set mask for flow director

[Jeff Kirsher]

From: Kiran Patil 

This patch implements feature, which allows user to change
input set mask for flow director using side-band channel.
This patch adds definition of FLOW_TYPE_MASK into the header file.
With this patch, user can now specify less than 4 tuple(src ip, dsp ip,
src port, dst port) for flow type TCP4/UDP4.

Change-Id: I90052508f8c172c0da5a4b78b949704b4a59ea78
Signed-off-by: Kiran Patil 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e.h |   6 ++
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 116 +
 drivers/net/ethernet/intel/i40e/i40e_txrx.c|   2 +-
 3 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e.h 
b/drivers/net/ethernet/intel/i40e/i40e.h
index e312adf..c2ac73d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -240,6 +240,12 @@ struct i40e_fdir_filter {
u32 fd_id;
 };
 
+#ifndef FLOW_TYPE_MASK
+#define FLOW_TYPE_MASK 0xFF
+#else
+#error FLOW_TYPE_MASK already defined elsewhere
+#endif
+
 #define I40E_ETH_P_LLDP0x88cc
 
 #define I40E_DCB_PRIO_TYPE_STRICT  0
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c 
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 8e56c43..ada448b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -2488,6 +2488,116 @@ static int i40e_del_fdir_entry(struct i40e_vsi *vsi,
 }
 
 /**
+ * i40e_handle_input_set - Detect and handle input set changes
+ * @vsi: pointer to the targeted VSI
+ * @fsp: pointer to RX flow classification spec
+ *
+ * Reads register, detect change in input set based on existing register
+ * value and what user has passed. Update input set mask register if needed.
+ **/
+static int i40e_handle_input_set(struct i40e_vsi *vsi,
+struct ethtool_rx_flow_spec *fsp)
+{
+   bool inset_mask_change = false;
+   struct i40e_pf *pf;
+   u64 val;
+   u8 idx;
+
+   if (unlikely(!vsi))
+   return -EINVAL;
+
+   pf = vsi->back;
+   switch (fsp->flow_type & FLOW_TYPE_MASK) {
+   case TCP_V4_FLOW:
+   idx = I40E_FILTER_PCTYPE_NONF_IPV4_TCP;
+   break;
+   case UDP_V4_FLOW:
+   idx = I40E_FILTER_PCTYPE_NONF_IPV4_UDP;
+   break;
+   default:
+   /* for all other flow types */
+   return 0;
+   }
+
+   val = ((u64)i40e_read_rx_ctl(>hw,
+I40E_PRTQF_FD_INSET(idx, 1)) << 32) |
+  (u64)i40e_read_rx_ctl(>hw,
+I40E_PRTQF_FD_INSET(idx, 0));
+
+   /* Default input set (TCP/UDP/SCTP) contains following
+* fields: srcip + dest ip + src port + dest port
+* For SCTP, there is one extra field, "verification tag"
+*/
+   if (val & I40E_L3_SRC_MASK) {
+   if (!fsp->h_u.tcp_ip4_spec.ip4src) {
+   val &= ~I40E_L3_SRC_MASK;
+   inset_mask_change = true;
+   }
+   } else {
+   if (fsp->h_u.tcp_ip4_spec.ip4src) {
+   val |= I40E_L3_SRC_MASK;
+   inset_mask_change = true;
+   }
+   }
+   if (val & I40E_L3_DST_MASK) {
+   if (!fsp->h_u.tcp_ip4_spec.ip4dst) {
+   val &= ~I40E_L3_DST_MASK;
+   inset_mask_change = true;
+   }
+   } else {
+   if (fsp->h_u.tcp_ip4_spec.ip4dst) {
+   val |= I40E_L3_DST_MASK;
+   inset_mask_change = true;
+   }
+   }
+   if (val & I40E_L4_SRC_MASK) {
+   if (!fsp->h_u.tcp_ip4_spec.psrc) {
+   val &= ~I40E_L4_SRC_MASK;
+   inset_mask_change = true;
+   }
+   } else {
+   if (fsp->h_u.tcp_ip4_spec.psrc) {
+   val |= I40E_L4_SRC_MASK;
+   inset_mask_change = true;
+   }
+   }
+   if (val & I40E_L4_DST_MASK) {
+   if (!fsp->h_u.tcp_ip4_spec.pdst) {
+   val &= ~I40E_L4_DST_MASK;
+   inset_mask_change = true;
+   }
+   } else {
+   if (fsp->h_u.tcp_ip4_spec.pdst) {
+   val |= I40E_L4_DST_MASK;
+   inset_mask_change = true;
+   }
+   }
+
+   if (inset_mask_change) {
+   if (pf->flags & I40E_FLAG_MFP_ENABLED) {
+   netif_err(pf, drv, vsi->netdev, "Change of input set is 
not supported when MFP mode is enabled\n");
+   return -EOPNOTSUPP;
+   }
+   if 

[net-next 15/15] i40evf: Add driver support for promiscuous mode

[Jeff Kirsher]

From: Anjali Singhai Jain 

Add necessary Linux Ethernet driver support for promiscuous mode
operation. Add a flag so the VF knows it is in promiscuous mode
and two state flags to discreetly track multicast and unicast
promiscuous states.

Change-Id: Ib2f2dc7a7582304fec90fc917ebb7ded21ba1de4
Signed-off-by: Anjali Singhai Jain 
Signed-off-by: Greg Rose 
Signed-off-by: Jesse Brandeburg 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c  | 14 +++---
 drivers/net/ethernet/intel/i40evf/i40evf.h  |  3 +++
 drivers/net/ethernet/intel/i40evf/i40evf_main.c | 19 +++
 drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 11 +++
 4 files changed, 40 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index f47b0e8..c226c2d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1489,13 +1489,13 @@ static int i40e_vc_config_promiscuous_mode_msg(struct 
i40e_vf *vf,
NULL);
} else if (i40e_getnum_vf_vsi_vlan_filters(vsi)) {
list_for_each_entry(f, >mac_filter_list, list) {
-   if (f->vlan >= 0 && f->vlan <= I40E_MAX_VLANID)
-   aq_ret = i40e_aq_set_vsi_mc_promisc_on_vlan
-  (hw,
-  vsi->seid,
-  allmulti,
-  f->vlan,
-  NULL);
+   if (f->vlan < 0 || f->vlan > I40E_MAX_VLANID)
+   continue;
+   aq_ret = i40e_aq_set_vsi_mc_promisc_on_vlan(hw,
+   vsi->seid,
+   allmulti,
+   f->vlan,
+   NULL);
aq_err = pf->hw.aq.asq_last_status;
if (aq_ret) {
dev_err(>pdev->dev,
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf.h 
b/drivers/net/ethernet/intel/i40evf/i40evf.h
index 63f7aae..25afabf 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf.h
+++ b/drivers/net/ethernet/intel/i40evf/i40evf.h
@@ -220,6 +220,7 @@ struct i40evf_adapter {
 #define I40EVF_FLAG_WB_ON_ITR_CAPABLE  BIT(11)
 #define I40EVF_FLAG_OUTER_UDP_CSUM_CAPABLE BIT(12)
 #define I40EVF_FLAG_ADDR_SET_BY_PF BIT(13)
+#define I40EVF_FLAG_PROMISC_ON BIT(15)
 /* duplicates for common code */
 #define I40E_FLAG_FDIR_ATR_ENABLED  0
 #define I40E_FLAG_DCB_ENABLED   0
@@ -244,6 +245,8 @@ struct i40evf_adapter {
 #define I40EVF_FLAG_AQ_SET_HENABIT(12)
 #define I40EVF_FLAG_AQ_SET_RSS_KEY BIT(13)
 #define I40EVF_FLAG_AQ_SET_RSS_LUT BIT(14)
+#define I40EVF_FLAG_AQ_REQUEST_PROMISC BIT(15)
+#define I40EVF_FLAG_AQ_RELEASE_PROMISC BIT(16)
 
/* OS defined structs */
struct net_device *netdev;
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c 
b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index af53159..d1c4afd 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -943,6 +943,14 @@ static void i40evf_set_rx_mode(struct net_device *netdev)
 bottom_of_search_loop:
continue;
}
+
+   if (netdev->flags & IFF_PROMISC &&
+   !(adapter->flags & I40EVF_FLAG_PROMISC_ON))
+   adapter->aq_required |= I40EVF_FLAG_AQ_REQUEST_PROMISC;
+   else if (!(netdev->flags & IFF_PROMISC) &&
+adapter->flags & I40EVF_FLAG_PROMISC_ON)
+   adapter->aq_required |= I40EVF_FLAG_AQ_RELEASE_PROMISC;
+
clear_bit(__I40EVF_IN_CRITICAL_TASK, >crit_section);
 }
 
@@ -1622,6 +1630,17 @@ static void i40evf_watchdog_task(struct work_struct 
*work)
goto watchdog_done;
}
 
+   if (adapter->aq_required & I40EVF_FLAG_AQ_REQUEST_PROMISC) {
+   i40evf_set_promiscuous(adapter, I40E_FLAG_VF_UNICAST_PROMISC |
+  I40E_FLAG_VF_MULTICAST_PROMISC);
+   goto watchdog_done;
+   }
+
+   if (adapter->aq_required & I40EVF_FLAG_AQ_RELEASE_PROMISC) {
+   

[net-next 06/15] i40e: Specify AQ event opcode to wait for

[Jeff Kirsher]

From: Shannon Nelson 

To add a little flexibility to the nvmupdate facility, this code adds the
ability to specify an AQ event opcode to wait on after the Exec_AQ request.

Change-ID: Iddbfd63c3de8df3edb9d3e90678b08989bc4946e
Signed-off-by: Shannon Nelson 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_nvm.c| 49 +++
 drivers/net/ethernet/intel/i40e/i40e_type.h   |  1 +
 drivers/net/ethernet/intel/i40evf/i40e_type.h |  1 +
 3 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_nvm.c 
b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
index f2cea3d..954efe3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -693,10 +693,10 @@ i40e_status i40e_nvmupd_command(struct i40e_hw *hw,
/* early check for status command and debug msgs */
upd_cmd = i40e_nvmupd_validate_command(hw, cmd, perrno);
 
-   i40e_debug(hw, I40E_DEBUG_NVM, "%s state %d nvm_release_on_hold %d cmd 
0x%08x config 0x%08x offset 0x%08x data_size 0x%08x\n",
+   i40e_debug(hw, I40E_DEBUG_NVM, "%s state %d nvm_release_on_hold %d opc 
0x%04x cmd 0x%08x config 0x%08x offset 0x%08x data_size 0x%08x\n",
   i40e_nvm_update_state_str[upd_cmd],
   hw->nvmupd_state,
-  hw->nvm_release_on_done,
+  hw->nvm_release_on_done, hw->nvm_wait_opcode,
   cmd->command, cmd->config, cmd->offset, cmd->data_size);
 
if (upd_cmd == I40E_NVMUPD_INVALID) {
@@ -710,7 +710,18 @@ i40e_status i40e_nvmupd_command(struct i40e_hw *hw,
 * going into the state machine
 */
if (upd_cmd == I40E_NVMUPD_STATUS) {
+   if (!cmd->data_size) {
+   *perrno = -EFAULT;
+   return I40E_ERR_BUF_TOO_SHORT;
+   }
+
bytes[0] = hw->nvmupd_state;
+
+   if (cmd->data_size >= 4) {
+   bytes[1] = 0;
+   *((u16 *)[2]) = hw->nvm_wait_opcode;
+   }
+
return 0;
}
 
@@ -729,6 +740,14 @@ i40e_status i40e_nvmupd_command(struct i40e_hw *hw,
 
case I40E_NVMUPD_STATE_INIT_WAIT:
case I40E_NVMUPD_STATE_WRITE_WAIT:
+   /* if we need to stop waiting for an event, clear
+* the wait info and return before doing anything else
+*/
+   if (cmd->offset == 0x) {
+   i40e_nvmupd_check_wait_event(hw, hw->nvm_wait_opcode);
+   return 0;
+   }
+
status = I40E_ERR_NOT_READY;
*perrno = -EBUSY;
break;
@@ -800,6 +819,7 @@ static i40e_status i40e_nvmupd_state_init(struct i40e_hw 
*hw,
i40e_release_nvm(hw);
} else {
hw->nvm_release_on_done = true;
+   hw->nvm_wait_opcode = i40e_aqc_opc_nvm_erase;
hw->nvmupd_state = I40E_NVMUPD_STATE_INIT_WAIT;
}
}
@@ -816,6 +836,7 @@ static i40e_status i40e_nvmupd_state_init(struct i40e_hw 
*hw,
i40e_release_nvm(hw);
} else {
hw->nvm_release_on_done = true;
+   hw->nvm_wait_opcode = i40e_aqc_opc_nvm_update;
hw->nvmupd_state = I40E_NVMUPD_STATE_INIT_WAIT;
}
}
@@ -828,10 +849,12 @@ static i40e_status i40e_nvmupd_state_init(struct i40e_hw 
*hw,
 hw->aq.asq_last_status);
} else {
status = i40e_nvmupd_nvm_write(hw, cmd, bytes, perrno);
-   if (status)
+   if (status) {
i40e_release_nvm(hw);
-   else
+   } else {
+   hw->nvm_wait_opcode = i40e_aqc_opc_nvm_update;
hw->nvmupd_state = I40E_NVMUPD_STATE_WRITE_WAIT;
+   }
}
break;
 
@@ -850,6 +873,7 @@ static i40e_status i40e_nvmupd_state_init(struct i40e_hw 
*hw,
i40e_release_nvm(hw);
} else {
hw->nvm_release_on_done = true;
+   hw->nvm_wait_opcode = i40e_aqc_opc_nvm_update;
hw->nvmupd_state = I40E_NVMUPD_STATE_INIT_WAIT;
}
}
@@ -940,8 +964,10 @@ retry:
switch (upd_cmd) {
case I40E_NVMUPD_WRITE_CON:
status = i40e_nvmupd_nvm_write(hw, cmd, bytes, perrno);
-   

[net-next 02/15] i40e/i40evf: Add support for IPIP and SIT offloads

[Jeff Kirsher]

From: Alexander Duyck 

Looking over the documentation it turns out enabling IPIP and SIT offloads
for i40e is pretty straightforward.  As such I decided to enable them with
this patch.  In my testing I am seeing an improvement of 8 to 10 Gb/s
for IPIP and SIT tunnels with this offload enabled.

Signed-off-by: Alexander Duyck 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_main.c |  2 ++
 drivers/net/ethernet/intel/i40e/i40e_txrx.c | 24 
 drivers/net/ethernet/intel/i40evf/i40e_txrx.c   | 24 
 drivers/net/ethernet/intel/i40evf/i40evf_main.c |  2 ++
 4 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index f2e83fe..ec94ad6c 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9120,6 +9120,8 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
   NETIF_F_TSO_ECN  |
   NETIF_F_TSO6 |
   NETIF_F_GSO_GRE  |
+  NETIF_F_GSO_IPIP |
+  NETIF_F_GSO_SIT  |
   NETIF_F_GSO_UDP_TUNNEL   |
   NETIF_F_GSO_UDP_TUNNEL_CSUM  |
   NETIF_F_SCTP_CRC |
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c 
b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 39efba0..6e44cf1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2299,7 +2299,10 @@ static int i40e_tso(struct sk_buff *skb, u8 *hdr_len, 
u64 *cd_type_cmd_tso_mss)
ip.v6->payload_len = 0;
}
 
-   if (skb_shinfo(skb)->gso_type & (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE |
+   if (skb_shinfo(skb)->gso_type & (SKB_GSO_GRE |
+SKB_GSO_IPIP |
+SKB_GSO_SIT |
+SKB_GSO_UDP_TUNNEL |
 SKB_GSO_UDP_TUNNEL_CSUM)) {
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM) {
/* determine offset of outer transport header */
@@ -2442,13 +2445,6 @@ static int i40e_tx_enable_csum(struct sk_buff *skb, u32 
*tx_flags,
 _proto, _off);
}
 
-   /* compute outer L3 header size */
-   tunnel |= ((l4.hdr - ip.hdr) / 4) <<
- I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT;
-
-   /* switch IP header pointer from outer to inner header */
-   ip.hdr = skb_inner_network_header(skb);
-
/* define outer transport */
switch (l4_proto) {
case IPPROTO_UDP:
@@ -2459,6 +2455,11 @@ static int i40e_tx_enable_csum(struct sk_buff *skb, u32 
*tx_flags,
tunnel |= I40E_TXD_CTX_GRE_TUNNELING;
*tx_flags |= I40E_TX_FLAGS_UDP_TUNNEL;
break;
+   case IPPROTO_IPIP:
+   case IPPROTO_IPV6:
+   *tx_flags |= I40E_TX_FLAGS_UDP_TUNNEL;
+   l4.hdr = skb_inner_network_header(skb);
+   break;
default:
if (*tx_flags & I40E_TX_FLAGS_TSO)
return -1;
@@ -2467,6 +2468,13 @@ static int i40e_tx_enable_csum(struct sk_buff *skb, u32 
*tx_flags,
return 0;
}
 
+   /* compute outer L3 header size */
+   tunnel |= ((l4.hdr - ip.hdr) / 4) <<
+ I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT;
+
+   /* switch IP header pointer from outer to inner header */
+   ip.hdr = skb_inner_network_header(skb);
+
/* compute tunnel header size */
tunnel |= ((ip.hdr - l4.hdr) / 2) <<
  I40E_TXD_CTX_QW0_NATLEN_SHIFT;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c 
b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index fc22818..f101895 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1564,7 +1564,10 @@ static int i40e_tso(struct sk_buff *skb, u8 *hdr_len, 
u64 *cd_type_cmd_tso_mss)
ip.v6->payload_len = 0;
}
 
-   if (skb_shinfo(skb)->gso_type & (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE |
+   if (skb_shinfo(skb)->gso_type & (SKB_GSO_GRE |
+SKB_GSO_IPIP |
+SKB_GSO_SIT |
+

[net-next 11/15] i40e: Remove zero check

[Jeff Kirsher]

From: Greg Rose 

A mirror rule ID may be zero so do not return invalid parameter when the
user passes in a zero value for a rule ID.

Change-ID: I261b8c24725ce2c6ed32f859da81093dfcbe2970
Signed-off-by: Greg Rose 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_common.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c 
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 1db4790..25872f2 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -2668,10 +2668,7 @@ i40e_status i40e_aq_delete_mirrorrule(struct i40e_hw 
*hw, u16 sw_seid,
u16 *rules_used, u16 *rules_free)
 {
/* Rule ID has to be valid except rule_type: INGRESS VLAN mirroring */
-   if (rule_type != I40E_AQC_MIRROR_RULE_TYPE_VLAN) {
-   if (!rule_id)
-   return I40E_ERR_PARAM;
-   } else {
+   if (rule_type == I40E_AQC_MIRROR_RULE_TYPE_VLAN) {
/* count and mr_list shall be valid for rule_type INGRESS VLAN
 * mirroring. For other rule_type, count and rule_type should
 * not matter.
-- 
2.5.5

[net-next 13/15] i40e: Add promiscuous on VLAN support

[Jeff Kirsher]

From: Greg Rose 

NFV use cases require the ability to steer packets to VSIs by VLAN tag
alone while being in promiscuous mode for multicast and unicast MAC
addresses.  These two new functions support that ability.

Signed-off-by: Greg Rose 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_common.c| 70 
 drivers/net/ethernet/intel/i40e/i40e_prototype.h |  8 +++
 2 files changed, 78 insertions(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c 
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 25872f2..0e8552b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -2039,6 +2039,76 @@ i40e_status i40e_aq_set_vsi_multicast_promiscuous(struct 
i40e_hw *hw,
 }
 
 /**
+ * i40e_aq_set_vsi_mc_promisc_on_vlan
+ * @hw: pointer to the hw struct
+ * @seid: vsi number
+ * @enable: set MAC L2 layer unicast promiscuous enable/disable for a given 
VLAN
+ * @vid: The VLAN tag filter - capture any multicast packet with this VLAN tag
+ * @cmd_details: pointer to command details structure or NULL
+ **/
+enum i40e_status_code i40e_aq_set_vsi_mc_promisc_on_vlan(struct i40e_hw *hw,
+u16 seid, bool enable,
+u16 vid,
+   struct i40e_asq_cmd_details *cmd_details)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_set_vsi_promiscuous_modes *cmd =
+   (struct i40e_aqc_set_vsi_promiscuous_modes *)
+   enum i40e_status_code status;
+   u16 flags = 0;
+
+   i40e_fill_default_direct_cmd_desc(,
+ 
i40e_aqc_opc_set_vsi_promiscuous_modes);
+
+   if (enable)
+   flags |= I40E_AQC_SET_VSI_PROMISC_MULTICAST;
+
+   cmd->promiscuous_flags = cpu_to_le16(flags);
+   cmd->valid_flags = cpu_to_le16(I40E_AQC_SET_VSI_PROMISC_MULTICAST);
+   cmd->seid = cpu_to_le16(seid);
+   cmd->vlan_tag = cpu_to_le16(vid | I40E_AQC_SET_VSI_VLAN_VALID);
+
+   status = i40e_asq_send_command(hw, , NULL, 0, cmd_details);
+
+   return status;
+}
+
+/**
+ * i40e_aq_set_vsi_uc_promisc_on_vlan
+ * @hw: pointer to the hw struct
+ * @seid: vsi number
+ * @enable: set MAC L2 layer unicast promiscuous enable/disable for a given 
VLAN
+ * @vid: The VLAN tag filter - capture any unicast packet with this VLAN tag
+ * @cmd_details: pointer to command details structure or NULL
+ **/
+enum i40e_status_code i40e_aq_set_vsi_uc_promisc_on_vlan(struct i40e_hw *hw,
+u16 seid, bool enable,
+u16 vid,
+   struct i40e_asq_cmd_details *cmd_details)
+{
+   struct i40e_aq_desc desc;
+   struct i40e_aqc_set_vsi_promiscuous_modes *cmd =
+   (struct i40e_aqc_set_vsi_promiscuous_modes *)
+   enum i40e_status_code status;
+   u16 flags = 0;
+
+   i40e_fill_default_direct_cmd_desc(,
+ 
i40e_aqc_opc_set_vsi_promiscuous_modes);
+
+   if (enable)
+   flags |= I40E_AQC_SET_VSI_PROMISC_UNICAST;
+
+   cmd->promiscuous_flags = cpu_to_le16(flags);
+   cmd->valid_flags = cpu_to_le16(I40E_AQC_SET_VSI_PROMISC_UNICAST);
+   cmd->seid = cpu_to_le16(seid);
+   cmd->vlan_tag = cpu_to_le16(vid | I40E_AQC_SET_VSI_VLAN_VALID);
+
+   status = i40e_asq_send_command(hw, , NULL, 0, cmd_details);
+
+   return status;
+}
+
+/**
  * i40e_aq_set_vsi_broadcast
  * @hw: pointer to the hw struct
  * @seid: vsi number
diff --git a/drivers/net/ethernet/intel/i40e/i40e_prototype.h 
b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
index 134035f..8afb237 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
@@ -133,6 +133,14 @@ i40e_status i40e_aq_set_vsi_unicast_promiscuous(struct 
i40e_hw *hw,
u16 vsi_id, bool set, struct i40e_asq_cmd_details *cmd_details);
 i40e_status i40e_aq_set_vsi_multicast_promiscuous(struct i40e_hw *hw,
u16 vsi_id, bool set, struct i40e_asq_cmd_details *cmd_details);
+enum i40e_status_code i40e_aq_set_vsi_mc_promisc_on_vlan(struct i40e_hw *hw,
+u16 seid, bool enable,
+u16 vid,
+   struct i40e_asq_cmd_details *cmd_details);
+enum i40e_status_code i40e_aq_set_vsi_uc_promisc_on_vlan(struct i40e_hw *hw,
+u16 seid, bool enable,
+u16 vid,
+   struct i40e_asq_cmd_details *cmd_details);
 

[net-next 01/15] i40e/i40evf: Clean up feature flags

[Jeff Kirsher]

From: Alexander Duyck 

The feature flags list for i40e and i40evf is beginning to become pretty
massive.  I plan to add another 4 or so features to these drivers and
duplicating the flags for each and every flags list is becoming a bit
repetitive.

The primary change here is that we now build our features list around
hw_encap_features.  After that we assign that to vlan_features,
hw_features, and finally map that onto features.  In addition we end up
throwing features onto hw_encap_features that end up having no effect such
as the Rx offloads and SCTP_CRC.  However that should have no impact and
makes things a bit easier for us as hw_encap_features is one of the less
updated features maps available.

For i40evf I went through and sanity checked a few features as well.
Specifically RXCSUM was being set as a read-only feature which didn't make
much sense.  I have updated things so we can clear the NETIF_F_RXCSUM flag
since that is really a software feature and not a hardware one anyway so
disabling it is just a matter of ignoring the result from the hardware.

Signed-off-by: Alexander Duyck 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 61 ++-
 drivers/net/ethernet/intel/i40evf/i40evf_main.c | 66 -
 2 files changed, 58 insertions(+), 69 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 0b071ce..f2e83fe 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9111,40 +9111,36 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
np = netdev_priv(netdev);
np->vsi = vsi;
 
-   netdev->hw_enc_features |= NETIF_F_IP_CSUM |
-  NETIF_F_IPV6_CSUM   |
-  NETIF_F_TSO |
-  NETIF_F_TSO6|
-  NETIF_F_TSO_ECN |
-  NETIF_F_GSO_GRE |
-  NETIF_F_GSO_UDP_TUNNEL  |
-  NETIF_F_GSO_UDP_TUNNEL_CSUM |
+   netdev->hw_enc_features |= NETIF_F_SG   |
+  NETIF_F_IP_CSUM  |
+  NETIF_F_IPV6_CSUM|
+  NETIF_F_HIGHDMA  |
+  NETIF_F_SOFT_FEATURES|
+  NETIF_F_TSO  |
+  NETIF_F_TSO_ECN  |
+  NETIF_F_TSO6 |
+  NETIF_F_GSO_GRE  |
+  NETIF_F_GSO_UDP_TUNNEL   |
+  NETIF_F_GSO_UDP_TUNNEL_CSUM  |
+  NETIF_F_SCTP_CRC |
+  NETIF_F_RXHASH   |
+  NETIF_F_RXCSUM   |
   0;
 
-   netdev->features = NETIF_F_SG  |
-  NETIF_F_IP_CSUM |
-  NETIF_F_SCTP_CRC|
-  NETIF_F_HIGHDMA |
-  NETIF_F_GSO_UDP_TUNNEL  |
-  NETIF_F_GSO_GRE |
-  NETIF_F_HW_VLAN_CTAG_TX |
-  NETIF_F_HW_VLAN_CTAG_RX |
-  NETIF_F_HW_VLAN_CTAG_FILTER |
-  NETIF_F_IPV6_CSUM   |
-  NETIF_F_TSO |
-  NETIF_F_TSO_ECN |
-  NETIF_F_TSO6|
-  NETIF_F_RXCSUM  |
-  NETIF_F_RXHASH  |
-  0;
+   if (!(pf->flags & I40E_FLAG_OUTER_UDP_CSUM_CAPABLE))
+   netdev->hw_enc_features ^= NETIF_F_GSO_UDP_TUNNEL_CSUM;
+
+   /* record features VLANs can make use of */
+   netdev->vlan_features |= netdev->hw_enc_features;
 
if (!(pf->flags & I40E_FLAG_MFP_ENABLED))
-   netdev->features |= NETIF_F_NTUPLE;
-   if (pf->flags & I40E_FLAG_OUTER_UDP_CSUM_CAPABLE)
-   netdev->features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
+   netdev->hw_features |= NETIF_F_NTUPLE;
+
+   netdev->hw_features |= netdev->hw_enc_features  |
+  NETIF_F_HW_VLAN_CTAG_TX  |
+  NETIF_F_HW_VLAN_CTAG_RX;
 
-   /* copy netdev features into list of user selectable features */
-   

[net-next 05/15] i40e: Code cleanup in i40e_add_fdir_ethtool

[Jeff Kirsher]

From: Shannon Nelson 

A little bit of code cleanup in prep for more cloud filter work.

Change-ID: I0dc33ce0d4c207944336a07437640fef920c100c
Signed-off-by: Shannon Nelson 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c 
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 8a83d45..8e56c43 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -2506,7 +2506,6 @@ static int i40e_add_fdir_ethtool(struct i40e_vsi *vsi,
 
if (!vsi)
return -EINVAL;
-
pf = vsi->back;
 
if (!(pf->flags & I40E_FLAG_FD_SB_ENABLED))
@@ -2564,15 +2563,18 @@ static int i40e_add_fdir_ethtool(struct i40e_vsi *vsi,
input->src_ip[0] = fsp->h_u.tcp_ip4_spec.ip4dst;
 
if (ntohl(fsp->m_ext.data[1])) {
-   if (ntohl(fsp->h_ext.data[1]) >= pf->num_alloc_vfs) {
-   netif_info(pf, drv, vsi->netdev, "Invalid VF id\n");
+   vf_id = ntohl(fsp->h_ext.data[1]);
+   if (vf_id >= pf->num_alloc_vfs) {
+   netif_info(pf, drv, vsi->netdev,
+  "Invalid VF id %d\n", vf_id);
goto free_input;
}
-   vf_id = ntohl(fsp->h_ext.data[1]);
/* Find vsi id from vf id and override dest vsi */
input->dest_vsi = pf->vf[vf_id].lan_vsi_id;
if (input->q_index >= pf->vf[vf_id].num_queue_pairs) {
-   netif_info(pf, drv, vsi->netdev, "Invalid queue id\n");
+   netif_info(pf, drv, vsi->netdev,
+  "Invalid queue id %d for VF %d\n",
+  input->q_index, vf_id);
goto free_input;
}
}
-- 
2.5.5

[net-next 07/15] i40evf: Allow PF driver to configure RSS

[Jeff Kirsher]

From: Mitch Williams 

If the PF driver reports proper support, allow the PF driver to
configure RSS on the behalf of the VF driver. This will allow for RSS
support on future hardware without changes to the VF driver.

Unfortunately, the old RSS code still needs to stay as the driver needs
to be compatible with PF drivers that don't support this interface. But
this change still simplifies the data structures a bunch and makes this
code simpler to read and maintain.

Change-ID: I0375aad40788ecdc0cb24d5cfeccf07804e69771
Signed-off-by: Mitch Williams 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40evf/i40evf.h |  30 +-
 drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 121 
 drivers/net/ethernet/intel/i40evf/i40evf_main.c| 308 +++--
 .../net/ethernet/intel/i40evf/i40evf_virtchnl.c| 119 
 4 files changed, 294 insertions(+), 284 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf.h 
b/drivers/net/ethernet/intel/i40evf/i40evf.h
index 017c83b..63f7aae 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf.h
+++ b/drivers/net/ethernet/intel/i40evf/i40evf.h
@@ -67,8 +67,6 @@ struct i40e_vsi {
u16 rx_itr_setting;
u16 tx_itr_setting;
u16 qs_handle;
-   u8 *rss_hkey_user; /* User configured hash keys */
-   u8 *rss_lut_user;  /* User configured lookup table entries */
 };
 
 /* How many Rx Buffers do we bundle into one write to the hardware ? */
@@ -239,8 +237,13 @@ struct i40evf_adapter {
 #define I40EVF_FLAG_AQ_CONFIGURE_QUEUESBIT(6)
 #define I40EVF_FLAG_AQ_MAP_VECTORS BIT(7)
 #define I40EVF_FLAG_AQ_HANDLE_RESETBIT(8)
-#define I40EVF_FLAG_AQ_CONFIGURE_RSS   BIT(9)
+#define I40EVF_FLAG_AQ_CONFIGURE_RSS   BIT(9)  /* direct AQ config */
 #define I40EVF_FLAG_AQ_GET_CONFIG  BIT(10)
+/* Newer style, RSS done by the PF so we can ignore hardware vagaries. */
+#define I40EVF_FLAG_AQ_GET_HENABIT(11)
+#define I40EVF_FLAG_AQ_SET_HENABIT(12)
+#define I40EVF_FLAG_AQ_SET_RSS_KEY BIT(13)
+#define I40EVF_FLAG_AQ_SET_RSS_LUT BIT(14)
 
/* OS defined structs */
struct net_device *netdev;
@@ -260,8 +263,14 @@ struct i40evf_adapter {
(_a)->vf_res->vf_offload_flags & \
I40E_VIRTCHNL_VF_OFFLOAD_IWARP : \
0)
+/* RSS by the PF should be preferred over RSS via other methods. */
+#define RSS_PF(_a) ((_a)->vf_res->vf_offload_flags & \
+   I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF)
 #define RSS_AQ(_a) ((_a)->vf_res->vf_offload_flags & \
I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ)
+#define RSS_REG(_a) (!((_a)->vf_res->vf_offload_flags & \
+  (I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ | \
+   I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF)))
 #define VLAN_ALLOWED(_a) ((_a)->vf_res->vf_offload_flags & \
  I40E_VIRTCHNL_VF_OFFLOAD_VLAN)
struct i40e_virtchnl_vf_resource *vf_res; /* incl. all VSIs */
@@ -273,6 +282,12 @@ struct i40evf_adapter {
struct i40e_eth_stats current_stats;
struct i40e_vsi vsi;
u32 aq_wait_count;
+   /* RSS stuff */
+   u64 hena;
+   u16 rss_key_size;
+   u16 rss_lut_size;
+   u8 *rss_key;
+   u8 *rss_lut;
 };
 
 
@@ -316,11 +331,12 @@ void i40evf_del_vlans(struct i40evf_adapter *adapter);
 void i40evf_set_promiscuous(struct i40evf_adapter *adapter, int flags);
 void i40evf_request_stats(struct i40evf_adapter *adapter);
 void i40evf_request_reset(struct i40evf_adapter *adapter);
+void i40evf_get_hena(struct i40evf_adapter *adapter);
+void i40evf_set_hena(struct i40evf_adapter *adapter);
+void i40evf_set_rss_key(struct i40evf_adapter *adapter);
+void i40evf_set_rss_lut(struct i40evf_adapter *adapter);
 void i40evf_virtchnl_completion(struct i40evf_adapter *adapter,
enum i40e_virtchnl_ops v_opcode,
i40e_status v_retval, u8 *msg, u16 msglen);
-int i40evf_config_rss(struct i40e_vsi *vsi, const u8 *seed, u8 *lut,
- u16 lut_size);
-int i40evf_get_rss(struct i40e_vsi *vsi, const u8 *seed, u8 *lut,
-  u16 lut_size);
+int i40evf_config_rss(struct i40evf_adapter *adapter);
 #endif /* _I40EVF_H_ */
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c 
b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
index dd4430a..9f7657c 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
@@ -387,20 +387,16 @@ static int i40evf_set_coalesce(struct net_device *netdev,
 static int i40evf_get_rss_hash_opts(struct i40evf_adapter *adapter,
struct 

[net-next 14/15] i40e: Add VF promiscuous mode driver support

[Jeff Kirsher]

From: Anjali Singhai Jain 

Add infrastructure for Network Function Virtualization VLAN tagged
packet steering feature.

Change-Id: I9b873d8fcc253858e6baba65ac68ec5b9363944e
Signed-off-by: Anjali Singhai Jain 
Signed-off-by: Greg Rose 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 153 -
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h |   2 +
 2 files changed, 149 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index c364588..f47b0e8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1427,6 +1427,25 @@ static void i40e_vc_reset_vf_msg(struct i40e_vf *vf)
 }
 
 /**
+ * i40e_getnum_vf_vsi_vlan_filters
+ * @vsi: pointer to the vsi
+ *
+ * called to get the number of VLANs offloaded on this VF
+ **/
+static inline int i40e_getnum_vf_vsi_vlan_filters(struct i40e_vsi *vsi)
+{
+   struct i40e_mac_filter *f;
+   int num_vlans = 0;
+
+   list_for_each_entry(f, >mac_filter_list, list) {
+   if (f->vlan >= 0 && f->vlan <= I40E_MAX_VLANID)
+   num_vlans++;
+   }
+
+   return num_vlans;
+}
+
+/**
  * i40e_vc_config_promiscuous_mode_msg
  * @vf: pointer to the VF info
  * @msg: pointer to the msg buffer
@@ -1442,22 +1461,122 @@ static int i40e_vc_config_promiscuous_mode_msg(struct 
i40e_vf *vf,
(struct i40e_virtchnl_promisc_info *)msg;
struct i40e_pf *pf = vf->pf;
struct i40e_hw *hw = >hw;
-   struct i40e_vsi *vsi;
+   struct i40e_mac_filter *f;
+   i40e_status aq_ret = 0;
bool allmulti = false;
-   i40e_status aq_ret;
+   struct i40e_vsi *vsi;
+   bool alluni = false;
+   int aq_err = 0;
 
vsi = i40e_find_vsi_from_id(pf, info->vsi_id);
if (!test_bit(I40E_VF_STAT_ACTIVE, >vf_states) ||
!test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, >vf_caps) ||
-   !i40e_vc_isvalid_vsi_id(vf, info->vsi_id) ||
-   (vsi->type != I40E_VSI_FCOE)) {
+   !i40e_vc_isvalid_vsi_id(vf, info->vsi_id)) {
+   dev_err(>pdev->dev,
+   "VF %d doesn't meet requirements to enter promiscuous 
mode\n",
+   vf->vf_id);
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
+   /* Multicast promiscuous handling*/
if (info->flags & I40E_FLAG_VF_MULTICAST_PROMISC)
allmulti = true;
-   aq_ret = i40e_aq_set_vsi_multicast_promiscuous(hw, vsi->seid,
-  allmulti, NULL);
+
+   if (vf->port_vlan_id) {
+   aq_ret = i40e_aq_set_vsi_mc_promisc_on_vlan(hw, vsi->seid,
+   allmulti,
+   vf->port_vlan_id,
+   NULL);
+   } else if (i40e_getnum_vf_vsi_vlan_filters(vsi)) {
+   list_for_each_entry(f, >mac_filter_list, list) {
+   if (f->vlan >= 0 && f->vlan <= I40E_MAX_VLANID)
+   aq_ret = i40e_aq_set_vsi_mc_promisc_on_vlan
+  (hw,
+  vsi->seid,
+  allmulti,
+  f->vlan,
+  NULL);
+   aq_err = pf->hw.aq.asq_last_status;
+   if (aq_ret) {
+   dev_err(>pdev->dev,
+   "Could not add VLAN %d to multicast 
promiscuous domain err %s aq_err %s\n",
+   f->vlan,
+   i40e_stat_str(>hw, aq_ret),
+   i40e_aq_str(>hw, aq_err));
+   break;
+   }
+   }
+   } else {
+   aq_ret = i40e_aq_set_vsi_multicast_promiscuous(hw, vsi->seid,
+  allmulti, NULL);
+   aq_err = pf->hw.aq.asq_last_status;
+   if (aq_ret) {
+   dev_err(>pdev->dev,
+   "VF %d failed to set multicast promiscuous mode 
err %s aq_err %s\n",
+   vf->vf_id,
+   i40e_stat_str(>hw, aq_ret),
+   i40e_aq_str(>hw, aq_err));
+   goto error_param_int;
+

[net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2016-04-26

[Jeff Kirsher]

This series contains updates to i40e and i40evf.

Alex Duyck cleans up the feature flags since they are becoming pretty
"massive", the primary change being that we now build our features list
around hw_encap_features.  Added support for IPIP and SIT offloads,
which should improvement in throughput for IPIP and SIT tunnels with
the offload enabled.

Mitch adds support for configuring RSS on behalf of the VFs, which removes
the burden of dealing with different hardware interfaces from the VF
drivers and improves future compatibility.  Fix to ensure that we do not
panic by checking that the vsi_res pointer is valid before dereferencing
it, after which we can drink beer and eat peanuts.

Shannon does come housekeeping in i40e_add_fdir_ethtool() in preparation
for more cloud filter work.  Added flexibility to the nvmupdate
facility by adding the ability to specify an AQ event opcode to wait on
after Exec_AQ request.

Kiran implements the feature to allow users to change input set mask for
flow director using side-band channel.

Michal adds device capability which defines if an update is available and
if a security check is needed during the update process.

Kamil just adds a device id to support X722 QSFP+ device.

Greg fixes an issue where a mirror rule ID may be zero, so do not return
invalid parameter when the user passes in a zero for a rule ID.  Adds
support to steer packets to VSIs by VLAN tag alone while being in
promiscuous mode for multicast and unicast MAC addresses.

Jesse fixes the driver from offloading the VLAN tag into the skb any
time there was a VLAN tag and the hardware stripping was enabled, to
making sure it is enabled before put_tag.

The following are changes since commit fab7b629a82da1b59620470d13152aff975239f6:
  Merge branch 'ila-csum-neutral'
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE

Alexander Duyck (2):
  i40e/i40evf: Clean up feature flags
  i40e/i40evf: Add support for IPIP and SIT offloads

Anjali Singhai Jain (2):
  i40e: Add VF promiscuous mode driver support
  i40evf: Add driver support for promiscuous mode

Greg Rose (2):
  i40e: Remove zero check
  i40e: Add promiscuous on VLAN support

Jesse Brandeburg (1):
  i40e/i40evf: Only offload VLAN tag if enabled

Kamil Krawczyk (1):
  i40e: Add DeviceID for X722 QSFP+

Kiran Patil (1):
  i40e: Allow user to change input set mask for flow director

Michal Kosiarz (1):
  i40e: Add device capability which defines if update is available

Mitch Williams (3):
  i40e: Add support for configuring VF RSS
  i40evf: Don't Panic
  i40evf: Allow PF driver to configure RSS

Shannon Nelson (2):
  i40e: Code cleanup in i40e_add_fdir_ethtool
  i40e: Specify AQ event opcode to wait for

 drivers/net/ethernet/intel/i40e/i40e.h |   7 +
 drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h  |   1 +
 drivers/net/ethernet/intel/i40e/i40e_common.c  |  82 -
 drivers/net/ethernet/intel/i40e/i40e_devids.h  |   1 +
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 128 ++-
 drivers/net/ethernet/intel/i40e/i40e_main.c|  98 ++---
 drivers/net/ethernet/intel/i40e/i40e_nvm.c |  49 ++-
 drivers/net/ethernet/intel/i40e/i40e_prototype.h   |   8 +
 drivers/net/ethernet/intel/i40e/i40e_txrx.c|  29 +-
 drivers/net/ethernet/intel/i40e/i40e_type.h|   6 +
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 346 +-
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h |   2 +
 .../net/ethernet/intel/i40evf/i40e_adminq_cmd.h|   1 +
 drivers/net/ethernet/intel/i40evf/i40e_common.c|   1 +
 drivers/net/ethernet/intel/i40evf/i40e_devids.h|   1 +
 drivers/net/ethernet/intel/i40evf/i40e_txrx.c  |  27 +-
 drivers/net/ethernet/intel/i40evf/i40e_type.h  |   6 +
 drivers/net/ethernet/intel/i40evf/i40evf.h |  39 +-
 drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 121 +++
 drivers/net/ethernet/intel/i40evf/i40evf_main.c| 395 -
 .../net/ethernet/intel/i40evf/i40evf_virtchnl.c| 130 +++
 21 files changed, 1070 insertions(+), 408 deletions(-)

-- 
2.5.5

Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

[Saeed Mahameed]

On Tue, Apr 26, 2016 at 11:03 PM, David Miller  wrote:
>
> Series applied.
>
> Be careful about what feature update semantics you implement.  If you get a 
> request
> to change multiple feature bits, and even one of them cannot be done, the 
> entire
> update operation should fail and the bits should revert to what they were 
> before
> the request.

It will be a nightmare to rollback in such case.  What if the rollback failed ?

>
> Is that how the code behaves now?
>

Not exactly.  If the set/clear of Bit(I) is performed successfully we
set/clear that feature in dev->features ourselves,
and if one fails we return a negative error code so
__netdev_update_features will notify on the failure, but we will be
left with the features that we did success to modify.

__netdev_update_features@net/core/dev.c

if (unlikely(err < 0)) {
netdev_err(dev,
"set_features() failed (%d); wanted %pNF, left %pNF\n",
err, , >features);
/* return non-0 since some features might have changed and
 * it's better to fire a spurious notification than miss it
 */
 return -1;
}

>From this I understand it is ok to update the dev->features inside the
device's set_features NDO and return a negative value in case of
failure,
and a notification on changed features will be fired in anycase.

Is this a correct assumption ?

Anyhow if you think this behavior should be fixed, we will fix it.
Failures at set_features should be rare and should be debugged rather
than ignored.

Saeed.

Re: [PATCH] bpf: fix double-fdput in replace_map_fd_with_map_ptr()

[Daniel Borkmann]

On 04/26/2016 10:26 PM, Jann Horn wrote:

When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode
references a non-map file descriptor as a map file descriptor, the error
handling code called fdput() twice instead of once (in __bpf_map_get() and
in replace_map_fd_with_map_ptr()). If the file descriptor table of the
current task is shared, this causes f_count to be decremented too much,
allowing the struct file to be freed while it is still in use
(use-after-free). This can be exploited to gain root privileges by an
unprivileged user.

This bug was introduced in
commit 0246e64d9a5f ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only
exploitable since
commit 1be7f75d1668 ("bpf: enable non-root eBPF programs") because
previously, CAP_SYS_ADMIN was required to reach the vulnerable code.

(posted publicly according to request by maintainer)

Signed-off-by: Jann Horn 
Signed-off-by: Linus Torvalds 


Acked-by: Daniel Borkmann 

Thanks!

Re: [PATCH] bpf: fix double-fdput in replace_map_fd_with_map_ptr()

[Alexei Starovoitov]

On Tue, Apr 26, 2016 at 10:26:26PM +0200, Jann Horn wrote:
> When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode
> references a non-map file descriptor as a map file descriptor, the error
> handling code called fdput() twice instead of once (in __bpf_map_get() and
> in replace_map_fd_with_map_ptr()). If the file descriptor table of the
> current task is shared, this causes f_count to be decremented too much,
> allowing the struct file to be freed while it is still in use
> (use-after-free). This can be exploited to gain root privileges by an
> unprivileged user.
> 
> This bug was introduced in
> commit 0246e64d9a5f ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only
> exploitable since
> commit 1be7f75d1668 ("bpf: enable non-root eBPF programs") because
> previously, CAP_SYS_ADMIN was required to reach the vulnerable code.
> 
> (posted publicly according to request by maintainer)
> 
> Signed-off-by: Jann Horn 
> Signed-off-by: Linus Torvalds 

Acked-by: Alexei Starovoitov 

[PATCH -next] net: w5100: support W5500

[Akinobu Mita]

This adds support for W5500 chip.

W5500 has similar register and memory organization with W5100 and W5200.
There are a few important differences listed below but it is still
possible to share common code with W5100 and W5200.

* W5500 register and memory are organized by multiple blocks.  Each one
is selected by 16bits offset address and 5bits block select bits.

But the existing register access operations take u16 address.  This change
extends the addess by u32 address and put offset address to lower 16bits
and block select bits to upper 16bits.

This change also adds the offset addresses for socket register and TX/RX
memory blocks to the driver private data structure in order to reduce
conditional switches for each chip.

* W5500 has the different register offset for socket interrupt mask
register.  Newly added internal functions w5100_enable_intr() and
w5100_disable_intr() take care of the diffrence.

* W5500 has the different register offset for retry time-value register.
But this register is only used to verify that the reset value is correctly
read at initialization.  So move the verification to w5100_hw_reset()
which already does different things for different chips.

Signed-off-by: Akinobu Mita 
Cc: Mike Sinkovsky 
Cc: David S. Miller 
---
 drivers/net/ethernet/wiznet/Kconfig |   2 +-
 drivers/net/ethernet/wiznet/w5100-spi.c | 192 +++--
 drivers/net/ethernet/wiznet/w5100.c | 243 +++-
 drivers/net/ethernet/wiznet/w5100.h |  13 +-
 4 files changed, 365 insertions(+), 85 deletions(-)

diff --git a/drivers/net/ethernet/wiznet/Kconfig 
b/drivers/net/ethernet/wiznet/Kconfig
index f3385a1..1981e88c 100644
--- a/drivers/net/ethernet/wiznet/Kconfig
+++ b/drivers/net/ethernet/wiznet/Kconfig
@@ -70,7 +70,7 @@ config WIZNET_BUS_ANY
 endchoice
 
 config WIZNET_W5100_SPI
-   tristate "WIZnet W5100/W5200 Ethernet support for SPI mode"
+   tristate "WIZnet W5100/W5200/W5500 Ethernet support for SPI mode"
depends on WIZNET_BUS_ANY && WIZNET_W5100
depends on SPI
---help---
diff --git a/drivers/net/ethernet/wiznet/w5100-spi.c 
b/drivers/net/ethernet/wiznet/w5100-spi.c
index 598a7b0..b868e45 100644
--- a/drivers/net/ethernet/wiznet/w5100-spi.c
+++ b/drivers/net/ethernet/wiznet/w5100-spi.c
@@ -1,5 +1,5 @@
 /*
- * Ethernet driver for the WIZnet W5100/W5200 chip.
+ * Ethernet driver for the WIZnet W5100/W5200/W5500 chip.
  *
  * Copyright (C) 2016 Akinobu Mita 
  *
@@ -8,6 +8,7 @@
  * Datasheet:
  * 
http://www.wiznet.co.kr/wp-content/uploads/wiznethome/Chip/W5100/Document/W5100_Datasheet_v1.2.6.pdf
  * 
http://wiznethome.cafe24.com/wp-content/uploads/wiznethome/Chip/W5200/Documents/W5200_DS_V140E.pdf
+ * 
http://wizwiki.net/wiki/lib/exe/fetch.php?media=products:w5500:w5500_ds_v106e_141230.pdf
  */
 
 #include 
@@ -21,7 +22,7 @@
 #define W5100_SPI_WRITE_OPCODE 0xf0
 #define W5100_SPI_READ_OPCODE 0x0f
 
-static int w5100_spi_read(struct net_device *ndev, u16 addr)
+static int w5100_spi_read(struct net_device *ndev, u32 addr)
 {
struct spi_device *spi = to_spi_device(ndev->dev.parent);
u8 cmd[3] = { W5100_SPI_READ_OPCODE, addr >> 8, addr & 0xff };
@@ -33,7 +34,7 @@ static int w5100_spi_read(struct net_device *ndev, u16 addr)
return ret ? ret : data;
 }
 
-static int w5100_spi_write(struct net_device *ndev, u16 addr, u8 data)
+static int w5100_spi_write(struct net_device *ndev, u32 addr, u8 data)
 {
struct spi_device *spi = to_spi_device(ndev->dev.parent);
u8 cmd[4] = { W5100_SPI_WRITE_OPCODE, addr >> 8, addr & 0xff, data};
@@ -41,7 +42,7 @@ static int w5100_spi_write(struct net_device *ndev, u16 addr, 
u8 data)
return spi_write_then_read(spi, cmd, sizeof(cmd), NULL, 0);
 }
 
-static int w5100_spi_read16(struct net_device *ndev, u16 addr)
+static int w5100_spi_read16(struct net_device *ndev, u32 addr)
 {
u16 data;
int ret;
@@ -55,7 +56,7 @@ static int w5100_spi_read16(struct net_device *ndev, u16 addr)
return ret < 0 ? ret : data | ret;
 }
 
-static int w5100_spi_write16(struct net_device *ndev, u16 addr, u16 data)
+static int w5100_spi_write16(struct net_device *ndev, u32 addr, u16 data)
 {
int ret;
 
@@ -66,7 +67,7 @@ static int w5100_spi_write16(struct net_device *ndev, u16 
addr, u16 data)
return w5100_spi_write(ndev, addr + 1, data & 0xff);
 }
 
-static int w5100_spi_readbulk(struct net_device *ndev, u16 addr, u8 *buf,
+static int w5100_spi_readbulk(struct net_device *ndev, u32 addr, u8 *buf,
  int len)
 {
int i;
@@ -82,7 +83,7 @@ static int w5100_spi_readbulk(struct net_device *ndev, u16 
addr, u8 *buf,
return 0;
 }
 
-static int w5100_spi_writebulk(struct net_device *ndev, u16 addr, const u8 
*buf,
+static int w5100_spi_writebulk(struct net_device *ndev, u32 addr, const u8 
*buf,

[PATCH] bpf: fix double-fdput in replace_map_fd_with_map_ptr()

[Jann Horn]

When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode
references a non-map file descriptor as a map file descriptor, the error
handling code called fdput() twice instead of once (in __bpf_map_get() and
in replace_map_fd_with_map_ptr()). If the file descriptor table of the
current task is shared, this causes f_count to be decremented too much,
allowing the struct file to be freed while it is still in use
(use-after-free). This can be exploited to gain root privileges by an
unprivileged user.

This bug was introduced in
commit 0246e64d9a5f ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only
exploitable since
commit 1be7f75d1668 ("bpf: enable non-root eBPF programs") because
previously, CAP_SYS_ADMIN was required to reach the vulnerable code.

(posted publicly according to request by maintainer)

Signed-off-by: Jann Horn 
Signed-off-by: Linus Torvalds 
---
 kernel/bpf/verifier.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 2e08f8e..8291251 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2029,7 +2029,6 @@ static int replace_map_fd_with_map_ptr(struct 
verifier_env *env)
if (IS_ERR(map)) {
verbose("fd %d is not pointing to valid 
bpf_map\n",
insn->imm);
-   fdput(f);
return PTR_ERR(map);
}
 
-- 
2.8.0.rc3.226.g39d4020

Re: [net-next PATCH 6/8] mlx4: Add support for inner IPv6 checksum offloads and TSO

[Saeed Mahameed]

On Tue, Apr 26, 2016 at 6:50 PM, Alex Duyck  wrote:
>
> The setup is pretty straight forward.  Basically I left the first port
> in the default namespace and moved the second int a secondary
> namespace referred to below as $netns.  I then assigned the IPv6
> addresses fec0::10:1 and fec0::10:2. After that I ran the following:
>
> VXLAN=vx$net
> echo $VXLAN ${test_options[$i]}
> ip link add $VXLAN type vxlan id $net \
> local fec0::10:1 remote $addr6 dev $PF0 \
> ${test_options[$i]} dstport `expr 8800 + $net`
> ip netns exec $netns ip link add $VXLAN type vxlan id $net \
>   local $addr6 remote fec0::10:1 dev $port \
>   ${test_options[$i]} dstport `expr 8800 + 
> $net`
> ifconfig $VXLAN 192.168.${net}.1/24
> ip netns exec $netns ifconfig $VXLAN 192.168.${net}.2/24
>

Thanks, indeed i see that GSO is not working with vxlan over IPv6 over
mlx5 device.
We will test out those patches on both mlx4 and mlx5, and debug mlx4
IPv6 issue you see.

>
>> Anyway, I suspect it might be related to a driver bug most likely in
>> get_real_size function @en_tx.c
>> specifically in : *lso_header_size = (skb_inner_transport_header(skb) -
>> skb->data) + inner_tcp_hdrlen(skb);
>>
>> will check this and get back to you.
>
> I'm not entirely convinced.  What I was seeing is t hat the hardware
> itself was performing Rx checksum offload only on tunnels with an
> outer IPv4 header and ignoring tunnels with an outer IPv6 header.

I don't get it, are you trying to say that the issue is in the RX side ?
what do you mean by ignoring ? Dropping ? or just not validating checksum ?
if so why would you disable GSO and IPv6 checksumming on TX ?

>>>   @@ -2431,7 +2435,18 @@ static netdev_features_t
>>> mlx4_en_features_check(struct sk_buff *skb,
>>> netdev_features_t
>>> features)
>>>   {
>>> features = vlan_features_check(skb, features);
>>> -   return vxlan_features_check(skb, features);
>>> +   features = vxlan_features_check(skb, features);
>>> +
>>> +   /* The ConnectX-3 doesn't support outer IPv6 checksums but it does
>>> +* support inner IPv6 checksums and segmentation so  we need to
>>> +* strip that feature if this is an IPv6 encapsulated frame.
>>> +*/
>>> +   if (skb->encapsulation &&
>>> +   (skb->ip_summed == CHECKSUM_PARTIAL) &&
>>> +   (ip_hdr(skb)->version != 4))
>>> +   features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
>>
>> Dejavu, didn't you fix this already in harmonize_features, in
>> i.e, it is enough to do here:
>>
>> if (skb->encapsulation && (skb->ip_summed == CHECKSUM_PARTIAL))
>> features &= ~NETIF_F_IPV6_CSUM;
>>
>
> So what this patch is doing is enabling an inner IPv6 header offloads.
> Up above we set the NETIF_F_IPV6_CSUM bit and we want it to stay set
> unless we have an outer IPv6 header because the inner headers may
> still need that bit set.  If I did what you suggest it strips IPv6
> checksum support for inner headers and if we have to use GSO partial I
> ended up encountering some of the other bugs that I have fixed for GSO
> partial where either sg or csum are not defined.
>

I see, you mean that you want to disable checksumming and GSO only for
packets with Outer(IPv6):Inner(X) and keep it in case for
Outer(IPv4):Inner(IPv6)
but i think it is weird that the driver decides to disable features it
didn't declare in first place (NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK)

Retry:

if (skb->encapsulation && (skb->ip_summed == CHECKSUM_PARTIAL) &&
(ip_hdr(skb)->version != 4))
features &= ~NETIF_F_IPV6_CSUM;

will this work ?

Anyway i prefer to debug the mlx4 issue first before we discuss the
best approach to disable checksumming & GSO for outer IPv6 in mlx4.

>>
>>> +
>>> +   return features;
>>>   }
>>>   #endif
>>>   diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>>> b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>>> index c0d7b7296236..c9f5388ea22a 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>>> @@ -41,6 +41,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>> #include "mlx4_en.h"
>>> @@ -918,8 +919,18 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct
>>> net_device *dev)
>>>  tx_ind, fragptr);
>>> if (skb->encapsulation) {
>>> -   struct iphdr *ipv4 = (struct iphdr
>>> *)skb_inner_network_header(skb);
>>> -   if (ipv4->protocol == IPPROTO_TCP || ipv4->protocol ==
>>> IPPROTO_UDP)
>>> +   union {
>>> +   struct iphdr *v4;
>>> +   struct ipv6hdr *v6;
>>> +   unsigned char *hdr;
>>> +   } ip;
>>> +   u8 proto;
>>> 

Re: [PATCH] netem: Segment GSO packets on enqueue.

[Eric Dumazet]

On Tue, 2016-04-26 at 15:00 -0400, Neil Horman wrote:
> I can understand that, but that raises two questions in my mind:
> 
> 1)  Doesn't that make all the statistical manipulation for netem wrong?  That 
> is
> to say, if netem drops 5% of packets, and it happens to drop a GSO packet, its
> actually dropping several, instead of the single one required.


Please take a look at tbf_segment(), where you can find a proper way to
handle this.

Note that for the case q->corrupt is 0, we definitely do not want to
segment TSO packets.

> 2) How are you getting netem to work with GSO at all?  The warning is 
> triggered
> for me on every GSO packet, which I think would impact throughput :)

I mostly use netem to add delays and drops.
I never had this bug, since q->corrupt = 0

Re: [PATCH RFC net-next] net: dsa: Provide CPU port statistics to master netdev

[Andrew Lunn]

> > Hi Florian
> > 
> > Interesting concept. My one concern is that by concatenating the two
> > sets of statistics, we get a name clash. I'm not sure the Marvell
> > switch statistics counters have different names to the Marvell
> > Ethernet driver statistics counters. ethtool does not care, but maybe
> > an SNMP agent using these statistics might not be too happy seeing the
> > same name twice?
> 
> That's a very good point, would you agree if we were prefixing the DSA
> CPU port statistics with some kind of name, e.g: cpu_port_ or
> something more compact?

Yes, that would be O.K.

It cannot be too long a prefix. The maximum length of the name is
32. The header file is unclear if there must be a NULL at the end. It
looks like the longest switch statistic we have is
RxPkts1024toMaxPktsOctets, i.e. 25 characters. So we only have 6 or 7
characters for the prefix.

   Andrew

Re: [PATCH 0/2] sh_eth: couple of software reset bit cleanups

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 24 Apr 2016 23:42:48 +0300

>Here's a set of 2 patches against DaveM's 'net-next.git' repo. We clean up
> the use of the software reset bits...
> 
> [1/2] sh_eth: use EDMR_SRST_GETHER in sh_eth_check_reset()
> [2/2] sh_eth: rename ARSTR register bit

Series applied, thanks.

[PATCH v6 03/25] io-mapping: Specify mapping size for io_mapping_map_wc()

[Chris Wilson]

The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: Yishai Hadas 
Cc: Dan Williams 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: David Hildenbrand 
Cc: Luis R. Rodriguez 
Cc: intel-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Luis R. Rodriguez 
---
 drivers/gpu/drm/i915/intel_overlay.c|  3 ++-
 drivers/net/ethernet/mellanox/mlx4/pd.c |  4 +++-
 include/linux/io-mapping.h  | 10 +++---
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 06bcd6aee64f..8d5293644d05 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem 
*)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
-overlay->flip_addr);
+overlay->flip_addr,
+PAGE_SIZE);
 
return regs;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c 
b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, 
int node)
goto free_uar;
}
 
-   uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << 
PAGE_SHIFT);
+   uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+   uar->index << PAGE_SHIFT,
+   PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
 }
 
 static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
 {
resource_size_t phys_addr;
 
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
 
-   return ioremap_wc(phys_addr, PAGE_SIZE);
+   return ioremap_wc(phys_addr, size);
 }
 
 static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
 
 /* Non-atomic map/unmap */
 static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
 {
return ((char __force __iomem *) mapping) + offset;
 }
-- 
2.8.1

Re: [PATCH net-next V1 00/11] Mellanox 100G extending mlx5 ethtool support

[David Miller]

From: Saeed Mahameed 
Date: Sun, 24 Apr 2016 22:51:45 +0300

> Changes from V0:
>   - Dropped: net/mlx5e: Disable link up on INIT HCA command
> Due to Ido's and Or's requests we will submit this patch to net and 
> will need it for -stable.
>   - Rebased to: 11afbff86168 ("Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next")
> 
> This series is centralized around extending and improving mlx5 ethernet 
> driver ethtool 
> support. We've done some code refactoring for ethtool statistics reporting, 
> making it 
> more scalable and robust, now each reported ethtool counter belongs to a 
> group and has
> its own descriptor within that group, the descriptor holds the counter name 
> and offset
> in memory in that group memory block.
> 
> Added new counters:
>   - Reporting more error and drop counter in ifconig/ip tool.
>   - Per priority pause and traffic counter in ethtool.
>   - link down events counter in ethtool.
>   
> Set features handling was also refactored a little bit to be more resilient 
> and generic, 
> now setting more than one feature will not stop on the first failed one, but 
> instead
> it will try to continue setting others. We made it generic to make it simpler 
> for adding
> more features support, it is now done easily by only introducing a handler 
> function of 
> the new supported netdev feature, and let the generic handler do the job.
> 
> New netdev features and ethtool support:
>   - Netdev feature RXALL, set on/off FCS check offload.
>   - Netdev feature HW_VLAN_CTAG_RX, set on/off rx-vlan stripping offload.
>   - Ethtool interface identify.
>   - Ethtool dump module EEPROM.

Series applied.

Be careful about what feature update semantics you implement.  If you get a 
request
to change multiple feature bits, and even one of them cannot be done, the entire
update operation should fail and the bits should revert to what they were before
the request.

Is that how the code behaves now?

Re: [PATCH net-next 0/6] net: core: remove TX_LOCKED support

[David Miller]

From: Florian Westphal 
Date: Sun, 24 Apr 2016 21:38:08 +0200

>  Not that many users left, lets kill it.
> 
>  TX_LOCKED was meant to be used by LLTX drivers when spin_trylock()
>  failed.  Stack then re-queued if collisions happened on different
>  cpus or free'd the skb to prevent deadlocks.
> 
>  Most of the driver removal patches fall into one of three categories:
>  1. remove the driver-private tx lock (and LLTX flag), or...
>  2. convert spin_trylock to plain spin_lock, or...
>  3. convert TX_LOCKED to free+TX_OK
> 
>  Patches are grouped by these categories, last patch is the actual removal.
>  All driver changes were compile tested only with exception of atl1e.

This looks good to me, series applied, thanks Florian.

Re: [PATCH] Fixes buffer allocation size and the actual packet length;

[David Miller]

Submitting a cover letter and the patch itself with identical Subject lines
is not correct.

You must also use proper "[PATCH $(TREE) X/Y] " prefixes in your Subject
lines as well.

Please format your Subject lines correctly and resubmit, thank you.

Re: [PATCH RFC net-next] net: dsa: Provide CPU port statistics to master netdev

[Florian Fainelli]

On 25/04/16 14:43, Andrew Lunn wrote:
> On Wed, Apr 20, 2016 at 10:58:21AM -0700, Florian Fainelli wrote:
>> This patch overloads the DSA master netdev, aka CPU Ethernet MAC to also
>> include switch-side statistics, which is useful for debugging purposes,
>> when the switch is not properly connected to the Ethernet MAC (duplex
>> mismatch, (RG)MII electrical issues etc.).
>>
>> We accomplish this by retaining the original copy of the master netdev's
>> ethtool_ops, and just overload the 3 operations we care about:
>> get_sset_count, get_strings and get_ethtool_stats so as to intercept
>> these calls and call into the original master_netdev ethtool_ops, plus
>> our own.
> 
> Hi Florian
> 
> Interesting concept. My one concern is that by concatenating the two
> sets of statistics, we get a name clash. I'm not sure the Marvell
> switch statistics counters have different names to the Marvell
> Ethernet driver statistics counters. ethtool does not care, but maybe
> an SNMP agent using these statistics might not be too happy seeing the
> same name twice?

That's a very good point, would you agree if we were prefixing the DSA
CPU port statistics with some kind of name, e.g: cpu_port_ or
something more compact?
-- 
Florian

Re: [PATCH 0/5] Don't return NULL from get_phy_device() anymore

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 24 Apr 2016 20:23:03 +0300

>Here's the set of 5 patches against DaveM's 'net-next.git' repo. The first
> patch makes get_phy_device() return only error values on error, the rest of
> the patches clean up the callers of that function...

Series applied, thanks.

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Andrew Lunn]

On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
> > > A more complex problem would be having a PHY driver for a device
> > > that can be either an ethernet phy or some other phy.
> > 
> > I doubt that ever happens. You can have up to 32 different devices on
> > an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
> > completely different things, why would a hardware engineer place them
> > on the same address? It is like saying your ATA controller and VGA
> > controller share the same slot on the PCI bus...
> 
> To clarify: what I meant is a device that is designed as a PHY for
> similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
> register set and a single driver, but that driver can operate
> in multiple modes. You typically have multiple instances of
> such hardware, with each instance linked to exactly one host
> device, but one driver for all of them.
> 
> See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
> and drivers/phy/phy-xgene.c for one such example.

Interesting. Also, that this lists SGMII. I assume this is a phy in
the MAC in order to talk to the Ethernet PHY.

I still don't see it being a big problem if a phy driver implements an
Ethernet PHY. It just needs to call phy_device_create() and
phy_device_register().

Andrew

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Arnd Bergmann]

On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
> > A more complex problem would be having a PHY driver for a device
> > that can be either an ethernet phy or some other phy.
> 
> I doubt that ever happens. You can have up to 32 different devices on
> an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
> completely different things, why would a hardware engineer place them
> on the same address? It is like saying your ATA controller and VGA
> controller share the same slot on the PCI bus...

To clarify: what I meant is a device that is designed as a PHY for
similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
register set and a single driver, but that driver can operate
in multiple modes. You typically have multiple instances of
such hardware, with each instance linked to exactly one host
device, but one driver for all of them.

See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
and drivers/phy/phy-xgene.c for one such example.

Arnd

Re: [PATCH] sh_eth: get rid of the 2nd parameter to sh_eth_dev_init()

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 24 Apr 2016 19:11:07 +0300

> sh_eth_dev_init()  is now always called with  'true' as the  2nd argument,
> so that there's no more sense in having 2 parameters to this function...
> 
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH net-next] sctp: sctp_diag should fill RMEM_ALLOC with asoc->rmem_alloc when rcvbuf_policy is set

[David Miller]

From: Xin Long 
Date: Sun, 24 Apr 2016 23:21:22 +0800

> For sctp assoc, when rcvbuf_policy is set, it will has it's own
> rmem_alloc, when we dump asoc info in sctp_diag, we should use that
> value on RMEM_ALLOC as well, just like WMEM_ALLOC.
> 
> Signed-off-by: Xin Long 

Applied.

Re: [PATCH net-next] macvlan: fix failure during registration v3

[David Miller]

From: Francesco Ruggeri 
Date: Sat, 23 Apr 2016 15:03:32 -0700

> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the ipvlan driver.
> This patch consolidates modifications to port->count into macvlan_init
> and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
> 
> v3: remove macvtap specific bits.
> 
> Signed-off-by: Francesco Ruggeri 

Applied.

Re: [PATCH net-next] macvtap: check minor when unregistering

[David Miller]

From: Francesco Ruggeri 
Date: Sat, 23 Apr 2016 15:04:31 -0700

> macvtap_device_event(NETDEV_UNREGISTER) should check vlan->minor to
> determine if it is being invoked in the context of a macvtap_newlink
> that failed, for example in this code sequence:
> 
> macvtap_newlink
>   macvlan_common_newlink
> register_netdevice
>   call_netdevice_notifiers(NETDEV_REGISTER, dev)
> macvtap_device_event(NETDEV_REGISTER)
>   minor = 0>
>   rollback_registered(dev);
> rollback_registered_many
>   call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
> macvtap_device_event(NETDEV_UNREGISTER)
>   
> 
> Signed-off-by: Francesco Ruggeri 

Applied.

Re: [PATCH net-next] ravb: Remove rx buffer ALIGN

[Sergei Shtylyov]

Hello.

On 04/24/2016 07:16 PM, Yoshihiro Kaneko wrote:


From: Kazuya Mizuguchi 

Aligning the reception data size is not required.


   OK, the gen 2/3 manuals indeed don't require this. I assume the patch has 
been tested...



Signed-off-by: Kazuya Mizuguchi 
Signed-off-by: Yoshihiro Kaneko 


   I have a few comments though...


diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 238b56f..66ed80c 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -246,10 +246,10 @@ static void ravb_ring_format(struct net_device *ndev, int 
q)
for (i = 0; i < priv->num_rx_ring[q]; i++) {
/* RX descriptor */
rx_desc = >rx_ring[q][i];
-   /* The size of the buffer should be on 16-byte boundary. */
-   rx_desc->ds_cc = cpu_to_le16(ALIGN(PKT_BUF_SZ, 16));
-   dma_addr = dma_map_single(ndev->dev.parent, 
priv->rx_skb[q][i]->data,
- ALIGN(PKT_BUF_SZ, 16),
+   rx_desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
+   dma_addr = dma_map_single(ndev->dev.parent,
+ priv->rx_skb[q][i]->data,


   Please don't reformat the lines above.


+ PKT_BUF_SZ,
  DMA_FROM_DEVICE);
/* We just set the data size to 0 for a failed mapping which
 * should prevent DMA from happening...
@@ -557,8 +557,9 @@ static bool ravb_rx(struct net_device *ndev, int *quota, 
int q)

skb = priv->rx_skb[q][entry];
priv->rx_skb[q][entry] = NULL;
-   dma_unmap_single(ndev->dev.parent, 
le32_to_cpu(desc->dptr),
-ALIGN(PKT_BUF_SZ, 16),
+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),


  Same here.

[...]

MBR, Sergei

Re: [PATCH] can: m_can: fix bitrate setup on latest silicon

[Oliver Hartkopp]

On 04/26/2016 03:46 PM, Florian Vallee wrote:

According to the m_can user manual changelog the BTP register layout was
updated with core revision 3.1.0


Hello Florian,

nice to see a real v3.1.0 user emerging on the mailing list :-)

I wonder whether this small change covers the updates made between
v3.0.1 and v3.1.0.

IIRC

v3.0.1:
NON_ISO operation / general CAN/CANFD and BRS switch in register CCCR
v3.1.0:
ISO operation / per frame CAN/CANFD switch (FDF/BRS bit in TX/RX buffer)
v3.2.x:
Ability to switch ISO/NON_ISO operation (NISO bit on register CCCR)
updated range of NBTP.NTSEG2

The current v3.0.1 driver is fixed to tell to be a NON_ISO controller:

https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/diff/drivers/net/can/m_can/m_can.c?h=testing

The v3.1.0 is a fixed ISO controller and additional it does not make 
sense anymore to configure the CCCR register each time, before sending a 
frame:


https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/tree/drivers/net/can/m_can/m_can.c?h=testing=885cc17abad6c3064f266099a6ded2d357012380#n1075

Just as the new TX/RX buffer layout contains a FDF and BRS bits for this 
reason.



+static inline int m_can_read_core_rev(const struct m_can_priv *priv)
+{
+   u32 reg = m_can_read(priv, M_CAN_CREL);
+
+   return ((reg >> CRR_REL_SHIFT) & CRR_REL_MASK);
+}
+
  static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
  {
struct net_device_stats *stats = >stats;
@@ -814,8 +838,16 @@ static int m_can_set_bittiming(struct net_device *dev)
sjw = bt->sjw - 1;
tseg1 = bt->prop_seg + bt->phase_seg1 - 1;
tseg2 = bt->phase_seg2 - 1;
-   reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
-   (tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
+
+   if (m_can_read_core_rev(priv) < M_CAN_COREREL_3_1_0)


Your patch looks very good so far. I would appreciate if you could 
update the other register changes too as I don't have a hardware to 
test. I can provide the ISO/NON_ISO config for the netlink interface 
updates then :-)


Best regards,
Oliver

Re: [PATCH net-next] macvlan: fix failure during registration v3

[Francesco Ruggeri]

On Tue, Apr 26, 2016 at 11:54 AM, Mahesh Bandewar  wrote:
>
> On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri  
> wrote:
> > If macvlan_common_newlink fails in register_netdevice after macvlan_init
> > then it decrements port->count twice, first in macvlan_uninit (from
> > register_netdevice or rollback_registered) and then again in
> > macvlan_common_newlink.
> > A similar problem may exist in the ipvlan driver.
> That is correct! The problem exists in ipvlan driver also. I'll cook a
> patch to fix this in ipvlan driver.
>
> > This patch consolidates modifications to port->count into macvlan_init
> > and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
> >
> > v3: remove macvtap specific bits.
> >
> > Signed-off-by: Francesco Ruggeri 
> > ---
> >  drivers/net/macvlan.c | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> > index 2bcf1f3..cb01023 100644
> > --- a/drivers/net/macvlan.c
> > +++ b/drivers/net/macvlan.c
> > @@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
> >  {
> > struct macvlan_dev *vlan = netdev_priv(dev);
> > const struct net_device *lowerdev = vlan->lowerdev;
> > +   struct macvlan_port *port = vlan->port;
> >
> > dev->state  = (dev->state & ~MACVLAN_STATE_MASK) |
> >   (lowerdev->state & MACVLAN_STATE_MASK);
> > @@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
> > if (!vlan->pcpu_stats)
> > return -ENOMEM;
> >
> > +   port->count += 1;
> > +
> > return 0;
> >  }
> >
> > @@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, 
> > struct net_device *dev,
> > return err;
> > }
> >
> > -   port->count += 1;
> > err = register_netdevice(dev);
> > if (err < 0)
> > -   goto destroy_port;
> > +   return err;
> >
> > dev->priv_flags |= IFF_MACVLAN;
> > err = netdev_upper_dev_link(lowerdev, dev);
> > @@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, 
> > struct net_device *dev,
> >
> >  unregister_netdev:
> > unregister_netdevice(dev);
> > -destroy_port:
> > -   port->count -= 1;
> > -   if (!port->count)
> > -   macvlan_port_destroy(lowerdev);
> I think you still need this when it fails netdev_upper_dev_link(). The
> only thing you should remove is the label.

I don't think so. I think the double decrement also occurred in this case.
unregister_netdevice invokes rollback_registered/macvlan_uninit
which does the decrement.

Thanks,
Francesco

> >
> > return err;
> >  }
> > --
> > 1.8.1.4
> >

Re: [PATCH] netem: Segment GSO packets on enqueue.

[Neil Horman]

On Tue, Apr 26, 2016 at 11:49:58AM -0700, Eric Dumazet wrote:
> On Tue, 2016-04-26 at 13:43 -0400, Neil Horman wrote:
> > This was recently reported to me, and reproduced on the latest net kernel, 
> > when
> > attempting to run netperf from a host that had a netem qdisc attached to the
> > egress interface:
> 
> ..
> 
> > The problem occurs because netem is not prepared to handle GSO packets (as 
> > it
> > uses skb_checksum_help in its enqueue path, which cannot manipulate these
> > frames).
> > 
> > The solution I think is to simply segment the skb in a simmilar fashion to 
> > the
> > way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
> > segment, instead of only when the interface needs us to do it.  This allows
> > netem to properly drop/mangle/pass/etc the correct percentages of frames as 
> > per
> > its qdisc configuration, and avoid failing its checksum operations
> > 
> > tested successfully by myself on the latest net kernel, to whcih this 
> > applies
> > 
> > Signed-off-by: Neil Horman 
> > CC: Jamal Hadi Salim 
> > CC: "David S. Miller" 
> > CC: ne...@lists.linux-foundation.org
> > ---
> >  net/sched/sch_netem.c | 34 +-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> 
> This is not correct.
> 
> I want my TSO packets being still TSO after netem traversal.
> 
> Some of us use netem at 40Gbit speed ;)
> 
I can understand that, but that raises two questions in my mind:

1)  Doesn't that make all the statistical manipulation for netem wrong?  That is
to say, if netem drops 5% of packets, and it happens to drop a GSO packet, its
actually dropping several, instead of the single one required.

2) How are you getting netem to work with GSO at all?  The warning is triggered
for me on every GSO packet, which I think would impact throughput :)

Neil

Re: [PATCH net-next] macvlan: fix failure during registration v3

[Mahesh Bandewar]

On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri  wrote:
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the ipvlan driver.
That is correct! The problem exists in ipvlan driver also. I'll cook a
patch to fix this in ipvlan driver.

> This patch consolidates modifications to port->count into macvlan_init
> and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
>
> v3: remove macvtap specific bits.
>
> Signed-off-by: Francesco Ruggeri 
> ---
>  drivers/net/macvlan.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 2bcf1f3..cb01023 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
>  {
> struct macvlan_dev *vlan = netdev_priv(dev);
> const struct net_device *lowerdev = vlan->lowerdev;
> +   struct macvlan_port *port = vlan->port;
>
> dev->state  = (dev->state & ~MACVLAN_STATE_MASK) |
>   (lowerdev->state & MACVLAN_STATE_MASK);
> @@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
> if (!vlan->pcpu_stats)
> return -ENOMEM;
>
> +   port->count += 1;
> +
> return 0;
>  }
>
> @@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct 
> net_device *dev,
> return err;
> }
>
> -   port->count += 1;
> err = register_netdevice(dev);
> if (err < 0)
> -   goto destroy_port;
> +   return err;
>
> dev->priv_flags |= IFF_MACVLAN;
> err = netdev_upper_dev_link(lowerdev, dev);
> @@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct 
> net_device *dev,
>
>  unregister_netdev:
> unregister_netdevice(dev);
> -destroy_port:
> -   port->count -= 1;
> -   if (!port->count)
> -   macvlan_port_destroy(lowerdev);
I think you still need this when it fails netdev_upper_dev_link(). The
only thing you should remove is the label.
>
> return err;
>  }
> --
> 1.8.1.4
>

Re: [PATCH v2] net/mlx5e: avoid stack overflow in mlx5e_open_channels

[Saeed Mahameed]

On Tue, Apr 26, 2016 at 6:52 PM, Arnd Bergmann  wrote:
> struct mlx5e_channel_param is a large structure that is allocated
> on the stack of mlx5e_open_channels, and with a recent change
> it has grown beyond the warning size for the maximum stack
> that a single function should use:
>
> mellanox/mlx5/core/en_main.c: In function 'mlx5e_open_channels':
> mellanox/mlx5/core/en_main.c:1325:1: error: the frame size of 1072 bytes is 
> larger than 1024 bytes [-Werror=frame-larger-than=]
>
> The function is already using dynamic allocation and is not in
> a fast path, so the easiest workaround is to use another kzalloc
> for allocating the channel parameters.
>
> Signed-off-by: Arnd Bergmann 
> Fixes: d3c9bc2743dc ("net/mlx5e: Added ICO SQs")

Acked-by: Saeed Mahameed 

Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels

[Saeed Mahameed]

On Tue, Apr 26, 2016 at 6:49 PM, Arnd Bergmann  wrote:
> On Tuesday 26 April 2016 17:41:45 Saeed Mahameed wrote:
>> On Tue, Apr 26, 2016 at 4:53 PM, Arnd Bergmann  wrote:
>> >
>> > Sure, do you want to just edit this when you forward the patch, or
>> > do you need me to do it?
>> >
>>
>> Well, I won't say no if you want to do it
>>
>
> All I want is to get rid of the patch in my queue. I guess it's
> worth the 10 minute of work ;-)
>
> v2 coming
>
> Arnd

Thank you Arnd, Appreciated.
Saeed.

[PATCH] Fixes buffer allocation size and the actual packet length;

[Petko Manolov]

usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.

Going through the chip's documentation i figured out the ethernet
packet is appended with 4 bytes of status data.  That's why we now
subtract 4 instead of 8 bytes from the reported packet length.

Reported-by: Lincoln Ramsay 
Signed-off-by: Petko Manolov 
---
 drivers/net/usb/pegasus.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index f840802..780c217 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -497,7 +497,7 @@ static void read_bulk_callback(struct urb *urb)
pkt_len = buf[count - 3] << 8;
pkt_len += buf[count - 4];
pkt_len &= 0xfff;
-   pkt_len -= 8;
+   pkt_len -= 4;
}
 
/*
@@ -528,7 +528,7 @@ static void read_bulk_callback(struct urb *urb)
 goon:
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
  usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
  read_bulk_callback, pegasus);
rx_status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
if (rx_status == -ENODEV)
@@ -569,7 +569,7 @@ static void rx_fixup(unsigned long data)
}
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
  usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
  read_bulk_callback, pegasus);
 try_again:
status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
@@ -823,7 +823,7 @@ static int pegasus_open(struct net_device *net)
 
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
  usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
  read_bulk_callback, pegasus);
if ((res = usb_submit_urb(pegasus->rx_urb, GFP_KERNEL))) {
if (res == -ENODEV)
-- 
2.8.0.rc3

[PATCH] Fixes buffer allocation size and the actual packet length;

[Petko Manolov]

As noticed by Lincoln Ramsay  some old (usb 1.1) Pegasus 
based devices may actually return more bytes than the specified in the 
datasheet 
amount.  That would not be a problem if the allocated space for the SKB was 
equal to the parameter passed to usb_fill_bulk_urb().  Some poor bugger (i 
really hope it was not me, but 'git blame' is useless in this case, so anyway) 
decided to add '+ 8' to the buffer length parameter.  Sometimes the usb 
transfer 
overflows and corrupts the socket structure, leading to kernel panic.

The above doesn't seem to happen for newer (Pegasus2 based) devices which did 
help this bug to hide for so long.

Nearly all Pegasus devices may append the RX status to the end of the received 
packet.  It is the default setup for the driver.  The actual ethernet packet is 
4 bytes shorter.  Why and when 'pkt_len -= 4' became 'pkt_len -= 8' is again 
hidden in the mists of time.  There might have been a good reason to do so, but 
multiple reads of the datasheet did not point me to any.

The patch is against v4.6-rc5 and was tested on ADM8515 device by transferring 
multiple gigabytes of data over a couple of days without any complains from the 
kernel.

Petko Manolov (1):
  Fixes buffer allocation size and the actual packet length;

 drivers/net/usb/pegasus.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
2.8.0.rc3

Re: [PATCH] netem: Segment GSO packets on enqueue.

[Eric Dumazet]

On Tue, 2016-04-26 at 13:43 -0400, Neil Horman wrote:
> This was recently reported to me, and reproduced on the latest net kernel, 
> when
> attempting to run netperf from a host that had a netem qdisc attached to the
> egress interface:

..

> The problem occurs because netem is not prepared to handle GSO packets (as it
> uses skb_checksum_help in its enqueue path, which cannot manipulate these
> frames).
> 
> The solution I think is to simply segment the skb in a simmilar fashion to the
> way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
> segment, instead of only when the interface needs us to do it.  This allows
> netem to properly drop/mangle/pass/etc the correct percentages of frames as 
> per
> its qdisc configuration, and avoid failing its checksum operations
> 
> tested successfully by myself on the latest net kernel, to whcih this applies
> 
> Signed-off-by: Neil Horman 
> CC: Jamal Hadi Salim 
> CC: "David S. Miller" 
> CC: ne...@lists.linux-foundation.org
> ---
>  net/sched/sch_netem.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)


This is not correct.

I want my TSO packets being still TSO after netem traversal.

Some of us use netem at 40Gbit speed ;)

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

[Sergei Shtylyov]

On 04/26/2016 08:17 PM, David Miller wrote:


I plan to queue this patch through arm-soc for 4.7.


Ok.


   How about this patch going thru your net-next repo instead?
I'd like to keep the kernel bisectable... if my phylib/macb patches get merged 
earlier than this one, that board would be broken...


MBR, Sergei

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

[Sergei Shtylyov]

Hello.

On 04/26/2016 01:24 PM, Nicolas Ferre wrote:


Fix gpio active flag for the phy reset-gpios property. The line is
active low instead of active high.
Actually, this flags was never used by the macb driver.

Reported-by: Sergei Shtylyov 
Cc: Andrew Lunn 
Cc: David Miller 
Signed-off-by: Nicolas Ferre 
---
Hi,

Thanks for having reported this bug to me.


   And thank you for beating me to it and doing the patch. I'm still busy 
with other stuff. :-(



I hope that we will be able to move forward for changing the phy
reset code in the macb driver.


   I meant to delete it entirely.


I plan to queue this patch through arm-soc for 4.7.


   Hm, that way we get that board broken if my phylib/macb patches get merged 
before your patch. Perhaps it would be better to merge this patch thru DaveM's 
tree (before my patches) to keep the kernel bisectable?



Thanks, best regards,
   Nicolas


MBR, Sergei

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Andrew Lunn]

> A more complex problem would be having a PHY driver for a device
> that can be either an ethernet phy or some other phy.

I doubt that ever happens. You can have up to 32 different devices on
an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
completely different things, why would a hardware engineer place them
on the same address? It is like saying your ATA controller and VGA
controller share the same slot on the PCI bus...

   Andrew

Re: [PATCH net-next 0/3] qed: Bandwidth configuration support

[David Miller]

From: Manish Chopra 
Date: Tue, 26 Apr 2016 10:56:07 -0400

> This series adds support in driver for min/max bandwidth configuration
> for the PF on the link change notification or on explicit request of
> bandwidth update from the MFW [management firmware].
> 
> The same infrastructure would later be used by user based flows
> [for example, rate shaping for the VFs]
> 
> Please consider applying this series to "net-next"

Series applied, thanks.

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Arnd Bergmann]

On Tuesday 26 April 2016 10:23:02 Florian Fainelli wrote:
> On 26/04/16 05:13, Andrew Lunn wrote:
> >> 4. Apart from these, by using MDIO mux framework we are making our
> >> non-ethernet PHYs dependent on Linux network drivers which is not
> >> acceptable. What if some product line does not need network subsystem at
> >> all?
> > 
> > This is your only valid point. However, does Broadcom have a product
> > line which does not include networking? Is not Broadcom a network SoC
> > vendor?
> 
> But even with that, there is no reason why we could not decouple the
> PHYLIB MDIO framework from PHYLIB and make it available as a more
> standalone subsystem which can be utilized when you have a mix of MDIO
> devices like here.

[adding Kishon Vijay Abraham]

We should also consider how this fits in with drivers/phy/, which is
the generic framework for all PHY devices that are not for ethernet.

The most straightforward way that you mention would be to allow
generic PHY devices to be probed on an MIO bus or mux. This should
just work using mdio_module_driver(), as Andrew already explained.

A more complex problem would be having a PHY driver for a device
that can be either an ethernet phy or some other phy. With today's
frameworks that would require two separate drivers, one in drivers/phy
and one in drivers/net/phy/. If that turns out to be a common problem,
we might want to come up with a way to nest one on top of the other,
or merge two two device structures (struct phy_device and struct phy).

> I am not clear on how common a shared MDIO bus is on other SoCs, but the
> other Broadcom SoCs I am familiar with have dedicated MDIO buses
> instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
> a ton easier.

I think most commonly, the other PHYs are not on MDIO at all, but are
integrated inside of the SoC as an MMIO based device.

Arnd

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Andrew Lunn]

> I am not clear on how common a shared MDIO bus is on other SoCs, but the
> other Broadcom SoCs I am familiar with have dedicated MDIO buses
> instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
> a ton easier.

I don't actually see this shared bus being an issue, once the mux it
implemented. With the mux, you see N MDIO busses, each acting like a
normal MDIO bus. I've used the GPIO variety and had no issues:

http://marc.info/?l=linux-arm-kernel=145910090401796=2

Andrew

[PATCH] netem: Segment GSO packets on enqueue.

[Neil Horman]

This was recently reported to me, and reproduced on the latest net kernel, when
attempting to run netperf from a host that had a netem qdisc attached to the
egress interface:

[  788.073771] [ cut here ]
[  788.096716] WARNING: at net/core/dev.c:2253 skb_warn_bad_offload+0xcd/0xda()
[  788.129521] bnx2: caps=(0x0001801949b3, 0x) len=2962
data_len=0 gso_size=1448 gso_type=1 ip_summed=3
[  788.182150] Modules linked in: sch_netem kvm_amd kvm crc32_pclmul ipmi_ssif
ghash_clmulni_intel sp5100_tco amd64_edac_mod aesni_intel lrw gf128mul
glue_helper ablk_helper edac_mce_amd cryptd pcspkr sg edac_core hpilo ipmi_si
i2c_piix4 k10temp fam15h_power hpwdt ipmi_msghandler shpchp acpi_power_meter
pcc_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c
sd_mod crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect sysimgblt
i2c_algo_bit drm_kms_helper ahci ata_generic pata_acpi ttm libahci
crct10dif_pclmul pata_atiixp tg3 libata crct10dif_common drm crc32c_intel ptp
serio_raw bnx2 r8169 hpsa pps_core i2c_core mii dm_mirror dm_region_hash dm_log
dm_mod
[  788.465294] CPU: 16 PID: 0 Comm: swapper/16 Tainted: GW
   3.10.0-327.el7.x86_64 #1
[  788.511521] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/17/2012
[  788.542260]  880437c036b8 f7afc56532a53db9 880437c03670
816351f1
[  788.576332]  880437c036a8 8107b200 880633e74200
880231674000
[  788.611943]  0001 0003 
880437c03710
[  788.647241] Call Trace:
[  788.658817][] dump_stack+0x19/0x1b
[  788.686193]  [] warn_slowpath_common+0x70/0xb0
[  788.713803]  [] warn_slowpath_fmt+0x5c/0x80
[  788.741314]  [] ? ___ratelimit+0x93/0x100
[  788.767018]  [] skb_warn_bad_offload+0xcd/0xda
[  788.796117]  [] skb_checksum_help+0x17c/0x190
[  788.823392]  [] netem_enqueue+0x741/0x7c0 [sch_netem]
[  788.854487]  [] dev_queue_xmit+0x2a8/0x570
[  788.880870]  [] ip_finish_output+0x53d/0x7d0
...

The problem occurs because netem is not prepared to handle GSO packets (as it
uses skb_checksum_help in its enqueue path, which cannot manipulate these
frames).

The solution I think is to simply segment the skb in a simmilar fashion to the
way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
segment, instead of only when the interface needs us to do it.  This allows
netem to properly drop/mangle/pass/etc the correct percentages of frames as per
its qdisc configuration, and avoid failing its checksum operations

tested successfully by myself on the latest net kernel, to whcih this applies

Signed-off-by: Neil Horman 
CC: Jamal Hadi Salim 
CC: "David S. Miller" 
CC: ne...@lists.linux-foundation.org
---
 net/sched/sch_netem.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 9640bb3..c9feecb 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -401,7 +401,7 @@ static void tfifo_enqueue(struct sk_buff *nskb, struct 
Qdisc *sch)
  * NET_XMIT_DROP: queue length didn't change.
  *  NET_XMIT_SUCCESS: one skb was queued.
  */
-static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+static int __netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
 {
struct netem_sched_data *q = qdisc_priv(sch);
/* We don't fill cb now as skb_unshare() may invalidate it */
@@ -519,6 +519,38 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc 
*sch)
return NET_XMIT_SUCCESS;
 }
 
+static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+   struct sk_buff *segs;
+   struct sk_buff *next;
+   int rc = NET_XMIT_SUCCESS;
+
+   if (skb_is_gso(skb)) {
+   segs = skb_gso_segment(skb, 0);
+   kfree_skb(skb);
+   if (IS_ERR(segs)) {
+   qdisc_qstats_drop(sch);
+   return NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
+   }
+   skb = segs;
+   }
+
+   while (skb) {
+   next = skb->next;
+   skb->next = NULL;
+   if (rc == NET_XMIT_SUCCESS)
+   rc = __netem_enqueue(skb, sch);
+   else {
+   qdisc_qstats_drop(sch);
+   kfree_skb(skb);
+   }
+
+   skb = next;
+   }
+
+   return rc;
+}
+
 static unsigned int netem_drop(struct Qdisc *sch)
 {
struct netem_sched_data *q = qdisc_priv(sch);
-- 
2.5.5

[PATCH] net: phy: at803x: only the AT8030 needs a hardware reset on link change

[Timur Tabi]

Commit 13a56b44 ("at803x: Add support for hardware reset") added a
work-around for a hardware bug on the AT8030.  However, the work-around
was being called for all 803x PHYs, even those that don't need it.
Function at803x_link_change_notify() checks to make sure that it only
resets the PHY on the 8030, but it makes more sense to not call that
function at all if it isn't needed.

Signed-off-by: Timur Tabi 
---
 drivers/net/phy/at803x.c | 40 ++--
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index b3ffaee..f279a89 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -359,27 +359,25 @@ static void at803x_link_change_notify(struct phy_device 
*phydev)
 * in the FIFO. In such cases, the FIFO enters an error mode it
 * cannot recover from by software.
 */
-   if (phydev->drv->phy_id == ATH8030_PHY_ID) {
-   if (phydev->state == PHY_NOLINK) {
-   if (priv->gpiod_reset && !priv->phy_reset) {
-   struct at803x_context context;
-
-   at803x_context_save(phydev, );
-
-   gpiod_set_value(priv->gpiod_reset, 1);
-   msleep(1);
-   gpiod_set_value(priv->gpiod_reset, 0);
-   msleep(1);
-
-   at803x_context_restore(phydev, );
-
-   phydev_dbg(phydev, "%s(): phy was reset\n",
-  __func__);
-   priv->phy_reset = true;
-   }
-   } else {
-   priv->phy_reset = false;
+   if (phydev->state == PHY_NOLINK) {
+   if (priv->gpiod_reset && !priv->phy_reset) {
+   struct at803x_context context;
+
+   at803x_context_save(phydev, );
+
+   gpiod_set_value(priv->gpiod_reset, 1);
+   msleep(1);
+   gpiod_set_value(priv->gpiod_reset, 0);
+   msleep(1);
+
+   at803x_context_restore(phydev, );
+
+   phydev_dbg(phydev, "%s(): phy was reset\n",
+  __func__);
+   priv->phy_reset = true;
}
+   } else {
+   priv->phy_reset = false;
}
 }
 
@@ -391,7 +389,6 @@ static struct phy_driver at803x_driver[] = {
.phy_id_mask= 0xffef,
.probe  = at803x_probe,
.config_init= at803x_config_init,
-   .link_change_notify = at803x_link_change_notify,
.set_wol= at803x_set_wol,
.get_wol= at803x_get_wol,
.suspend= at803x_suspend,
@@ -427,7 +424,6 @@ static struct phy_driver at803x_driver[] = {
.phy_id_mask= 0xffef,
.probe  = at803x_probe,
.config_init= at803x_config_init,
-   .link_change_notify = at803x_link_change_notify,
.set_wol= at803x_set_wol,
.get_wol= at803x_get_wol,
.suspend= at803x_suspend,
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [net-next PATCH V2 5/5] samples/bpf: like LLC also verify and allow redefining CLANG command

[Alexei Starovoitov]

On Tue, Apr 26, 2016 at 06:27:32PM +0200, Jesper Dangaard Brouer wrote:
> Users are likely to manually compile both LLVM 'llc' and 'clang'
> tools.  Thus, also allow redefining CLANG and verify command exist.
> 
> Makefile implementation wise, the target that verify the command have
> been generalized.
> 
> Signed-off-by: Jesper Dangaard Brouer 
> ---
>  samples/bpf/Makefile   |   23 +--
>  samples/bpf/README.rst |6 +++---
>  2 files changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index dd63521832d8..c02ea9d2a248 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -81,9 +81,10 @@ HOSTLOADLIBES_spintest += -lelf
>  HOSTLOADLIBES_map_perf_test += -lelf -lrt
>  HOSTLOADLIBES_test_overhead += -lelf -lrt
>  
> -# Allows pointing LLC to a LLVM backend with bpf support, redefine on 
> cmdline:
> -#  make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> +# Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on 
> cmdline:
> +#  make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
> CLANG=~/git/llvm/build/bin/clang
>  LLC ?= llc
> +CLANG ?= clang
>  
>  # Trick to allow make to be run from this directory
>  all:
> @@ -94,15 +95,17 @@ clean:
>   @rm -f *~
>  
>  # Verify LLVM compiler is available and bpf target is supported
> -.PHONY: verify_cmd_llc verify_target_bpf
> +.PHONY: verify_cmd_llc verify_target_bpf $(CLANG) $(LLC)
>  
> -verify_cmd_llc:
> - @if ! (which "${LLC}" > /dev/null 2>&1); then \
> - echo "*** ERROR: Cannot find LLVM tool 'llc' (${LLC})" ;\
> - exit 1; \
> - else true; fi
> +verify_cmds: $(CLANG) $(LLC)
> + @for TOOL in $^ ; do \
> + if ! (which "$${TOOL}" > /dev/null 2>&1); then \
> + echo "*** ERROR: Cannot find LLVM tool $${TOOL}" ;\
> + exit 1; \
> + else true; fi; \
> + done
>  
> -verify_target_bpf: verify_cmd_llc
> +verify_target_bpf: verify_cmds
>   @if ! (${LLC} -march=bpf -mattr=help > /dev/null 2>&1); then \
>   echo "*** ERROR: LLVM (${LLC}) does not support 'bpf' target" ;\
>   echo "   NOTICE: LLVM version >= 3.7.1 required" ;\

If I read the patch correctly, it only checks that any version
of clang is available and llc supports -march=bpf.
That's correct.
There is no need to build the latest clang most of the time.
clang 3.4 and 3.5 are fine to compile samples/bpf/
since llvm ir is mostly compatible with llc from 3.7 or 3.8

Acked-by: Alexei Starovoitov 

Re: [net-next PATCH V2 4/5] samples/bpf: allow make to be run from samples/bpf/ directory

[Alexei Starovoitov]

On Tue, Apr 26, 2016 at 06:27:27PM +0200, Jesper Dangaard Brouer wrote:
> It is not intuitive that 'make' must be run from the top level
> directory with argument "samples/bpf/" to compile these eBPF samples.
> 
> Introduce a kbuild make file trick that allow make to be run from the
> "samples/bpf/" directory itself.  It basically change to the top level
> directory and call "make samples/bpf/" with the "/" slash after the
> directory name.
> 
> Also add a clean target that only cleans this directory, by taking
> advantage of the kbuild external module setting M=$PWD.
> 
> Signed-off-by: Jesper Dangaard Brouer 

Acked-by: Alexei Starovoitov 

Re: [net-next PATCH V2 3/5] samples/bpf: add a README file to get users started

[Alexei Starovoitov]

On Tue, Apr 26, 2016 at 06:27:22PM +0200, Jesper Dangaard Brouer wrote:
> +
> +Manually compiling LLVM with 'bpf' support
> +--
> +
> +In some LLVM versions the BPF target were marked experimental. They
> +needed the 'cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF'.  Since
> +version 3.7.1, LLVM adds a proper LLVM backend target for the BPF
> +bytecode architecture.

it's actually non-experimental since 3.7.0.
It was experimental after 3.6 was released during development of 3.7.
I doubt you can find this anywhere, so I suggest to just drop this paragraph.

Re: [net-next PATCH V2 1/5] samples/bpf: add back functionality to redefine LLC command

[Alexei Starovoitov]

On Tue, Apr 26, 2016 at 06:27:11PM +0200, Jesper Dangaard Brouer wrote:
> It is practical to be-able-to redefine the location of the LLVM
> command 'llc', because not all distros have a LLVM version with bpf
> target support.  Thus, it is sometimes required to compile LLVM from
> source, and sometimes it is not desired to overwrite the distros
> default LLVM version.
> 
> This feature was removed with 128d1514be35 ("samples/bpf: Use llc in
> PATH, rather than a hardcoded value").
> 
> Add this features back. Note that it is possible to redefine the LLC
> on the make command like:
> 
>  make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> 
> Fixes: 128d1514be35 ("samples/bpf: Use llc in PATH, rather than a hardcoded 
> value")
> Signed-off-by: Jesper Dangaard Brouer 

Acked-by: Alexei Starovoitov 

Re: [net-next PATCH V2 2/5] samples/bpf: Makefile verify LLVM compiler avail and bpf target is supported

[Alexei Starovoitov]

On Tue, Apr 26, 2016 at 06:27:16PM +0200, Jesper Dangaard Brouer wrote:
> Make compiling samples/bpf more user friendly, by detecting if LLVM
> compiler tool 'llc' is available, and also detect if the 'bpf' target
> is available in this version of LLVM.
> 
> Signed-off-by: Jesper Dangaard Brouer 

Acked-by: Alexei Starovoitov 

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

[Florian Fainelli]

On 26/04/16 05:13, Andrew Lunn wrote:
>> 4. Apart from these, by using MDIO mux framework we are making our
>> non-ethernet PHYs dependent on Linux network drivers which is not
>> acceptable. What if some product line does not need network subsystem at
>> all?
> 
> This is your only valid point. However, does Broadcom have a product
> line which does not include networking? Is not Broadcom a network SoC
> vendor?

But even with that, there is no reason why we could not decouple the
PHYLIB MDIO framework from PHYLIB and make it available as a more
standalone subsystem which can be utilized when you have a mix of MDIO
devices like here.

I am not clear on how common a shared MDIO bus is on other SoCs, but the
other Broadcom SoCs I am familiar with have dedicated MDIO buses
instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
a ton easier.
-- 
Florian

Re: [PATCH net-next 0/8] cxgb4: minor fixes, decode msgs and code refactor for few functions

[David Miller]

From: Hariprasad Shenai 
Date: Tue, 26 Apr 2016 20:10:21 +0530

> This patch series adds new routine to get adapter information and removes
> some redundant messages logged in dmesg. Fixes race while freeing tx
> descriptors. Decodes module type and link down reason codes obtained from
> firmware. Refactor port initialization and FW_PORT_CMD handling. Pass
> correct port id in DCB message handler to obtain netdev associated. 
> 
> This patch series has been created against net-next tree and includes
> patches on cxgb4 driver.
> 
> We have included all the maintainers of respective drivers. Kindly review
> the change and let us know in case of any review comments.

Series applied, thanks.

Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag

[David Miller]

From: Nicolas Ferre 
Date: Tue, 26 Apr 2016 12:24:32 +0200

> I plan to queue this patch through arm-soc for 4.7.

Ok.