Re: [net-next PATCH V2 5/5] samples/bpf: like LLC also verify and allow redefining CLANG command
On Tue, 26 Apr 2016 10:36:10 -0700 Alexei Starovoitov wrote: > 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. Yes, you read the patch correctly :-) > 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 Good to get confirmation. I was testing with clang 3.5.0, and llc 3.9-git. > Acked-by: Alexei Starovoitov -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer
[no subject]
, Doug Ledford Bcc: Subject: Re: [PATCH net] RDMA/nes: don't leak skb if carrier down Reply-To: l...@kernel.org In-Reply-To: <1461529139-28582-1-git-send-email...@strlen.de> On Sun, Apr 24, 2016 at 10:18:59PM +0200, Florian Westphal wrote: > Alternatively one could free the skb, OTOH I don't think this test is > useful so just remove it. > > Cc: > Signed-off-by: Florian Westphal I don't know why did you decide to send it to netdev and not to relevant maintainers, but the relevant mailing list is linux-rdma and Faisal needs to Review/Acknowledge it. ➜ linux-rdma git:(master) ./scripts/get_maintainer.pl -f drivers/infiniband/hw/nes/nes_nic.c Faisal Latif (supporter:NETEFFECT IWARP RNIC DRIVER (IW_NES)) Doug Ledford (supporter:INFINIBAND SUBSYSTEM) Sean Hefty (supporter:INFINIBAND SUBSYSTEM) Hal Rosenstock (supporter:INFINIBAND SUBSYSTEM) linux-r...@vger.kernel.org (open list:NETEFFECT IWARP RNIC DRIVER (IW_NES)) linux-ker...@vger.kernel.org (open list) > --- > Noticed this while working on the TX_LOCKED removal. > > diff --git a/drivers/infiniband/hw/nes/nes_nic.c > b/drivers/infiniband/hw/nes/nes_nic.c > index 3ea9e05..9291453 100644 > --- a/drivers/infiniband/hw/nes/nes_nic.c > +++ b/drivers/infiniband/hw/nes/nes_nic.c > @@ -500,9 +500,6 @@ static int nes_netdev_start_xmit(struct sk_buff *skb, > struct net_device *netdev) >* skb_shinfo(skb)->nr_frags, skb_is_gso(skb)); >*/ > > - if (!netif_carrier_ok(netdev)) > - return NETDEV_TX_OK; > - > if (netif_queue_stopped(netdev)) > return NETDEV_TX_BUSY; > > -- > 2.7.3 > > -- > 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 signature.asc Description: Digital signature
Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings
On Mon, Apr 25, 2016 at 04:34:47PM +0300, Haggai Abramovsky wrote: > -int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct, > -struct mlx4_buf *buf, gfp_t gfp) > +static int mlx4_buf_direct_alloc(struct mlx4_dev *dev, int size, > + struct mlx4_buf *buf, gfp_t gfp) > { > - dma_addr_t t; > + dma_addr_t t; > You have wrong indentation in whole this function. > - if (size <= max_direct) { > buf->nbufs= 1; > buf->npages = 1; > buf->page_shift = get_order(size) + PAGE_SHIFT; > - buf->direct.buf = dma_alloc_coherent(&dev->persist->pdev->dev, > -size, &t, gfp); > + buf->direct.buf = > + dma_zalloc_coherent(&dev->persist->pdev->dev, > + size, &t, gfp); > if (!buf->direct.buf) > return -ENOMEM; signature.asc Description: Digital signature
Re: [net-next PATCH V2 3/5] samples/bpf: add a README file to get users started
On Tue, 26 Apr 2016 10:31:06 -0700 Alexei Starovoitov wrote: > 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. Okay lets drop this paragraph, given the LLVM period was so short, it does not make sense to mention here. I will send a V3 patch series, as DaveM usually likes a full resubmit (I'll add your acks to the other patches, but you need to ack this one). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer
Re: [RFC PATCH 4/5] bnxt: Add support for segmentation of tunnels with outer checksums
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
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 /* For TIOCINQ/OUTQ */ + +#include + +#include "qrtr.h" + +#define QRTR_PROTO_VER 1 + +/* auto-bind range */ +#define QRTR_MIN_
Re: [PATCH 1/6] bus: Add shared MDIO bus framework
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
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
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
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
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(&bitmap->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(&bitmap->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
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
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(&bitmap->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(&bitmap->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
> 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
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
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(&priv->set_rx_mode_work); mlx5e_disable_async_events(priv); flush_scheduled_work(); - unregister_netdev(netdev); + if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state)) { + netif_device_detach(netdev); + mutex_lock(&priv->state_lock); + if (test_bit(MLX5E_STATE_OPENED, &priv->state)) + mlx5e_close_locked(netdev); + mutex_unlock(&priv->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
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 = &macsec_priv(dev)->secy; struct macsec_tx_sc *tx_sc = &secy->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
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.
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
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
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(&tx_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(&tx_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(&tx_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(&tx_ring->tx_lock, flags); if (unlikely(!PCH_GBE_DESC_UNUSED(tx_ring))) { netif_stop_queue(netdev); - spin_unlock_irqrestore(&tx_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(&tx_ring->tx_lock, flags); return NETDEV_TX_OK; } -- 2.5.5
Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller
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
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
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 change
Darlehen anbieten. Kontaktieren Sie uns für weitere Informationen
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
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
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
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
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
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()
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
[...] >> > -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
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
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(&pdev->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 *ndev = platform_get_drvdata(p
[PATCH net-next 2/5] stmmac: dwmac-socfpga: add PM ops and resume function
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(&pdev->dev, plat_dat, &stmmac_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 = &stmmac_pltfr_pm_ops, + .pm = &socfpga_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()
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
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
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); 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(&pdev->dev, plat_dat, &stmmac_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
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
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(&tx_ring->tx_lock, flags); + spin_lock_irqsave(&tx_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
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 should help to keep the code size smaller for the
[net-next 12/15] i40e/i40evf: Only offload VLAN tag if enabled
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(&q_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(&q_vector->napi, skb); -- 2.5.5
[net-next 10/15] i40e: Add DeviceID for X722 QSFP+
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
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
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
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 = &pf->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(&pf->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(&pf->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->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 |= + I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ; + else + vfres->vf_offload
[net-next 08/15] i40e: Allow user to change input set mask for flow director
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(&pf->hw, +I40E_PRTQF_FD_INSET(idx, 1)) << 32) | + (u64)i40e_read_rx_ctl(&pf->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 (pf->fdir_pf_active_filters) { + netif_err(pf, drv, vsi->netdev, "Change of input set is not su
[net-next 15/15] i40evf: Add driver support for promiscuous mode
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, &vsi->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(&pf->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, &adapter->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) { + i40evf_set_promiscuous(adapter, 0); + goto watchdog_done; + } + if (adapter->state == __I40EVF_RUNNING) i40evf_
[net-next 06/15] i40e: Specify AQ event opcode to wait for
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 *)&bytes[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); - if (!status) + if (!status) { + hw->nvm_
[net-next 02/15] i40e/i40evf: Add support for IPIP and SIT offloads
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, &l4_proto, &frag_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 | +SKB_GSO_UDP_TUNNEL |
[net-next 11/15] i40e: Remove zero check
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
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 *)&desc.params.raw; + enum i40e_status_code status; + u16 flags = 0; + + i40e_fill_default_direct_cmd_desc(&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, &desc, 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 *)&desc.params.raw; + enum i40e_status_code status; + u16 flags = 0; + + i40e_fill_default_direct_cmd_desc(&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, &desc, 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); i40e_status i40e_aq_set_vsi_vlan_promisc(struct i40e_hw *hw,
[net-next 01/15] i40e/i40evf: Clean up feature flags
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 */ - netdev->hw_features |= netdev->features; + netdev->features |= netdev->hw_features | NETIF_F_
[net-next 05/15] i40e: Code cleanup in i40e_add_fdir_ethtool
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
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 ethtool_rxnfc *cmd) { - struct i40e_hw *hw = &adapter->hw; - u64 hena = (u64)rd32(hw, I40E_VFQF_HENA
[net-next 14/15] i40e: Add VF promiscuous mode driver support
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, &vsi->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 = &pf->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->vf_states) || !test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->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(&pf->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, &vsi->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(&pf->pdev->dev, + "Could not add VLAN %d to multicast promiscuous domain err %s aq_err %s\n", + f->vlan, + i40e_stat_str(&pf->hw, aq_ret), + i40e_aq_str(&pf->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(&pf->pdev->dev, + "VF %d failed to set multicast promiscuous mode err %s aq_err %s\n", + vf->vf_id, + i40e_stat_str(&pf->hw, aq_ret), + i40e_aq_str(&pf->hw, aq_err)); + goto error_param_int; + } + } + + if (!aq_ret) { + dev_info(&pf->pdev-
[net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2016-04-26
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
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, &dev->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()
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()
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
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, int len) { int i; @@ -134,7 +135,7 @@ static int w5200_spi_init(struct net_dev
[PATCH] bpf: fix double-fdput in replace_map_fd_with_map_ptr()
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
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.
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
> > 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
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()
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
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
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;
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
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
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
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
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()
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
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
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
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
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 = &priv->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
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&id=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 = &dev->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
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.
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
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
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
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;
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;
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.
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
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
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
> 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
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
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
> 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&m=145910090401796&w=2 Andrew
[PATCH] netem: Segment GSO packets on enqueue.
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
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, &context); - - gpiod_set_value(priv->gpiod_reset, 1); - msleep(1); - gpiod_set_value(priv->gpiod_reset, 0); - msleep(1); - - at803x_context_restore(phydev, &context); - - 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, &context); + + gpiod_set_value(priv->gpiod_reset, 1); + msleep(1); + gpiod_set_value(priv->gpiod_reset, 0); + msleep(1); + + at803x_context_restore(phydev, &context); + + 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
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
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
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
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