[PATCH v2 net-next 1/4] soreuseport: define reuseport groups

2015-12-29 Thread Craig Gallek
From: Craig Gallek 

struct sock_reuseport is an optional shared structure referenced by each
socket belonging to a reuseport group.  When a socket is bound to an
address/port not yet in use and the reuseport flag has been set, the
structure will be allocated and attached to the newly bound socket.
When subsequent calls to bind are made for the same address/port, the
shared structure will be updated to include the new socket and the
newly bound socket will reference the group structure.

Usually, when an incoming packet was destined for a reuseport group,
all sockets in the same group needed to be considered before a
dispatching decision was made.  With this structure, an appropriate
socket can be found after looking up just one socket in the group.

This shared structure will also allow for more complicated decisions to
be made when selecting a socket (eg a BPF filter).

This work is based off a similar implementation written by
Ying Cai  for implementing policy-based reuseport
selection.

Signed-off-by: Craig Gallek 
---
 include/net/sock.h   |   2 +
 include/net/sock_reuseport.h |  20 +
 net/core/Makefile|   2 +-
 net/core/sock_reuseport.c| 173 +++
 4 files changed, 196 insertions(+), 1 deletion(-)
 create mode 100644 include/net/sock_reuseport.h
 create mode 100644 net/core/sock_reuseport.c

diff --git a/include/net/sock.h b/include/net/sock.h
index 3794cdd..e830c10 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -318,6 +318,7 @@ struct cg_proto;
   *@sk_error_report: callback to indicate errors (e.g. %MSG_ERRQUEUE)
   *@sk_backlog_rcv: callback to process the backlog
   *@sk_destruct: called at sock freeing time, i.e. when all refcnt == 0
+  *@sk_reuseport_cb: reuseport group container
  */
 struct sock {
/*
@@ -453,6 +454,7 @@ struct sock {
int (*sk_backlog_rcv)(struct sock *sk,
  struct sk_buff *skb);
void(*sk_destruct)(struct sock *sk);
+   struct sock_reuseport __rcu *sk_reuseport_cb;
 };
 
 #define __sk_user_data(sk) ((*((void __rcu **)&(sk)->sk_user_data)))
diff --git a/include/net/sock_reuseport.h b/include/net/sock_reuseport.h
new file mode 100644
index 000..67d1eb8
--- /dev/null
+++ b/include/net/sock_reuseport.h
@@ -0,0 +1,20 @@
+#ifndef _SOCK_REUSEPORT_H
+#define _SOCK_REUSEPORT_H
+
+#include 
+#include 
+
+struct sock_reuseport {
+   struct rcu_head rcu;
+
+   u16 max_socks;  /* length of socks */
+   u16 num_socks;  /* elements in socks */
+   struct sock *socks[0];  /* array of sock pointers */
+};
+
+extern int reuseport_alloc(struct sock *sk);
+extern int reuseport_add_sock(struct sock *sk, const struct sock *sk2);
+extern void reuseport_detach_sock(struct sock *sk);
+extern struct sock *reuseport_select_sock(struct sock *sk, u32 hash);
+
+#endif  /* _SOCK_REUSEPORT_H */
diff --git a/net/core/Makefile b/net/core/Makefile
index 086b01f..0b835de 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
 
 obj-y   += dev.o ethtool.o dev_addr_lists.o dst.o netevent.o \
neighbour.o rtnetlink.o utils.o link_watch.o filter.o \
-   sock_diag.o dev_ioctl.o tso.o
+   sock_diag.o dev_ioctl.o tso.o sock_reuseport.o
 
 obj-$(CONFIG_XFRM) += flow.o
 obj-y += net-sysfs.o
diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
new file mode 100644
index 000..963c8d5
--- /dev/null
+++ b/net/core/sock_reuseport.c
@@ -0,0 +1,173 @@
+/*
+ * To speed up listener socket lookup, create an array to store all sockets
+ * listening on the same port.  This allows a decision to be made after finding
+ * the first socket.
+ */
+
+#include 
+#include 
+
+#define INIT_SOCKS 128
+
+static DEFINE_SPINLOCK(reuseport_lock);
+
+static struct sock_reuseport *__reuseport_alloc(u16 max_socks)
+{
+   size_t size = sizeof(struct sock_reuseport) +
+ sizeof(struct sock *) * max_socks;
+   struct sock_reuseport *reuse = kzalloc(size, GFP_ATOMIC);
+
+   if (!reuse)
+   return NULL;
+
+   reuse->max_socks = max_socks;
+
+   return reuse;
+}
+
+int reuseport_alloc(struct sock *sk)
+{
+   struct sock_reuseport *reuse;
+
+   /* bh lock used since this function call may precede hlist lock in
+* soft irq of receive path or setsockopt from process context
+*/
+   spin_lock_bh(_lock);
+   WARN_ONCE(rcu_dereference_protected(sk->sk_reuseport_cb,
+   lockdep_is_held(_lock)),
+ "multiple allocations for the same socket");
+   reuse = __reuseport_alloc(INIT_SOCKS);
+   if (!reuse) {
+   

[PATCH v2 net-next 4/4] soreuseport: BPF selection functional test

2015-12-29 Thread Craig Gallek
From: Craig Gallek 

This program will build classic and extended BPF programs and
validate the socket selection logic when used with
SO_ATTACH_REUSEPORT_CBPF and SO_ATTACH_REUSEPORT_EBPF.

It also validates the re-programing flow and several edge cases.

Signed-off-by: Craig Gallek 
---
 tools/testing/selftests/net/.gitignore  |   1 +
 tools/testing/selftests/net/Makefile|   2 +-
 tools/testing/selftests/net/reuseport_bpf.c | 467 
 3 files changed, 469 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/net/reuseport_bpf.c

diff --git a/tools/testing/selftests/net/.gitignore 
b/tools/testing/selftests/net/.gitignore
index 0032662..6fb2336 100644
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@ -1,3 +1,4 @@
 socket
 psock_fanout
 psock_tpacket
+reuseport_bpf
diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index fac4782..41449b5 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -4,7 +4,7 @@ CFLAGS = -Wall -O2 -g
 
 CFLAGS += -I../../../../usr/include/
 
-NET_PROGS = socket psock_fanout psock_tpacket
+NET_PROGS = socket psock_fanout psock_tpacket reuseport_bpf
 
 all: $(NET_PROGS)
 %: %.c
diff --git a/tools/testing/selftests/net/reuseport_bpf.c 
b/tools/testing/selftests/net/reuseport_bpf.c
new file mode 100644
index 000..74ff099
--- /dev/null
+++ b/tools/testing/selftests/net/reuseport_bpf.c
@@ -0,0 +1,467 @@
+/*
+ * Test functionality of BPF filters for SO_REUSEPORT.  The tests below will 
use
+ * a BPF program (both classic and extended) to read the first word from an
+ * incoming packet (expected to be in network byte-order), calculate a modulus
+ * of that number, and then dispatch the packet to the Nth socket using the
+ * result.  These tests are run for each supported address family and protocol.
+ * Additionally, a few edge cases in the implementation are tested.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
+
+struct test_params {
+   int recv_family;
+   int send_family;
+   int protocol;
+   size_t recv_socks;
+   uint16_t recv_port;
+   uint16_t send_port_min;
+};
+
+static size_t sockaddr_size(void)
+{
+   return sizeof(struct sockaddr_storage);
+}
+
+static struct sockaddr *new_any_sockaddr(int family, uint16_t port)
+{
+   struct sockaddr_storage *addr;
+   struct sockaddr_in *addr4;
+   struct sockaddr_in6 *addr6;
+
+   addr = malloc(sizeof(struct sockaddr_storage));
+   memset(addr, 0, sizeof(struct sockaddr_storage));
+
+   switch (family) {
+   case AF_INET:
+   addr4 = (struct sockaddr_in *)addr;
+   addr4->sin_family = AF_INET;
+   addr4->sin_addr.s_addr = htonl(INADDR_ANY);
+   addr4->sin_port = htons(port);
+   break;
+   case AF_INET6:
+   addr6 = (struct sockaddr_in6 *)addr;
+   addr6->sin6_family = AF_INET6;
+   addr6->sin6_addr = in6addr_any;
+   addr6->sin6_port = htons(port);
+   break;
+   default:
+   error(1, 0, "Unsupported family %d", family);
+   }
+   return (struct sockaddr *)addr;
+}
+
+static struct sockaddr *new_loopback_sockaddr(int family, uint16_t port)
+{
+   struct sockaddr *addr = new_any_sockaddr(family, port);
+   struct sockaddr_in *addr4;
+   struct sockaddr_in6 *addr6;
+
+   switch (family) {
+   case AF_INET:
+   addr4 = (struct sockaddr_in *)addr;
+   addr4->sin_addr.s_addr = htonl(INADDR_LOOPBACK);
+   break;
+   case AF_INET6:
+   addr6 = (struct sockaddr_in6 *)addr;
+   addr6->sin6_addr = in6addr_loopback;
+   break;
+   default:
+   error(1, 0, "Unsupported family %d", family);
+   }
+   return addr;
+}
+
+static void attach_ebpf(int fd, uint16_t mod)
+{
+   static char bpf_log_buf[65536];
+   static const char bpf_license[] = "GPL";
+
+   int bpf_fd;
+   const struct bpf_insn prog[] = {
+   /* BPF_MOV64_REG(BPF_REG_6, BPF_REG_1) */
+   { BPF_ALU64 | BPF_MOV | BPF_X, BPF_REG_6, BPF_REG_1, 0, 0 },
+   /* BPF_LD_ABS(BPF_W, 0) R0 = (uint32_t)skb[0] */
+   { BPF_LD | BPF_ABS | BPF_W, 0, 0, 0, 0 },
+   /* BPF_ALU64_IMM(BPF_MOD, BPF_REG_0, mod) */
+   { BPF_ALU64 | BPF_MOD | BPF_K, BPF_REG_0, 0, 0, mod },
+   /* BPF_EXIT_INSN() */
+   { BPF_JMP | BPF_EXIT, 0, 0, 0, 0 }
+   };
+   union bpf_attr attr;
+
+   memset(, 0, sizeof(attr));
+   attr.prog_type = BPF_PROG_TYPE_SOCKET_FILTER;
+   

[PATCH v2 net-next 3/4] soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF

2015-12-29 Thread Craig Gallek
From: Craig Gallek 

Expose socket options for setting a classic or extended BPF program
for use when selecting sockets in an SO_REUSEPORT group.  These options
can be used on the first socket to belong to a group before bind or
on any socket in the group after bind.

This change includes refactoring of the existing sk_filter code to
allow reuse of the existing BPF filter validation checks.

Signed-off-by: Craig Gallek 
---
 arch/alpha/include/uapi/asm/socket.h   |   3 +
 arch/avr32/include/uapi/asm/socket.h   |   3 +
 arch/frv/include/uapi/asm/socket.h |   3 +
 arch/ia64/include/uapi/asm/socket.h|   3 +
 arch/m32r/include/uapi/asm/socket.h|   3 +
 arch/mips/include/uapi/asm/socket.h|   3 +
 arch/mn10300/include/uapi/asm/socket.h |   3 +
 arch/parisc/include/uapi/asm/socket.h  |   3 +
 arch/powerpc/include/uapi/asm/socket.h |   3 +
 arch/s390/include/uapi/asm/socket.h|   3 +
 arch/sparc/include/uapi/asm/socket.h   |   3 +
 arch/xtensa/include/uapi/asm/socket.h  |   3 +
 include/linux/filter.h |   2 +
 include/net/sock_reuseport.h   |  10 ++-
 include/net/udp.h  |   5 +-
 include/uapi/asm-generic/socket.h  |   3 +
 net/core/filter.c  | 120 +++--
 net/core/sock.c|  29 
 net/core/sock_reuseport.c  |  88 ++--
 net/ipv4/udp.c |  14 ++--
 net/ipv4/udp_diag.c|   4 +-
 net/ipv6/udp.c |  14 ++--
 22 files changed, 282 insertions(+), 43 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/socket.h 
b/arch/alpha/include/uapi/asm/socket.h
index 9a20821..c5fb9e6 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -92,4 +92,7 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/avr32/include/uapi/asm/socket.h 
b/arch/avr32/include/uapi/asm/socket.h
index 2b65ed6..9de0796 100644
--- a/arch/avr32/include/uapi/asm/socket.h
+++ b/arch/avr32/include/uapi/asm/socket.h
@@ -85,4 +85,7 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _UAPI__ASM_AVR32_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h 
b/arch/frv/include/uapi/asm/socket.h
index 4823ad1..f02e484 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -85,5 +85,8 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _ASM_SOCKET_H */
 
diff --git a/arch/ia64/include/uapi/asm/socket.h 
b/arch/ia64/include/uapi/asm/socket.h
index 59be3d8..bce2916 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -94,4 +94,7 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h 
b/arch/m32r/include/uapi/asm/socket.h
index 7bc4cb2..14aa4a6 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -85,4 +85,7 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h 
b/arch/mips/include/uapi/asm/socket.h
index dec3c85..5910fe2 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -103,4 +103,7 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h 
b/arch/mn10300/include/uapi/asm/socket.h
index cab7d6d..58b1aa0 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -85,4 +85,7 @@
 #define SO_ATTACH_BPF  50
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define SO_ATTACH_REUSEPORT_CBPF   51
+#define SO_ATTACH_REUSEPORT_EBPF   52
+
 #endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h 
b/arch/parisc/include/uapi/asm/socket.h
index a5cd40c..f9cf122 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -84,4 +84,7 @@
 #define SO_ATTACH_BPF  0x402B
 #define SO_DETACH_BPF  SO_DETACH_FILTER
 
+#define 

[PATCH v2 net-next 2/4] soreuseport: fast reuseport UDP socket selection

2015-12-29 Thread Craig Gallek
From: Craig Gallek 

Include a struct sock_reuseport instance when a UDP socket binds to
a specific address for the first time with the reuseport flag set.
When selecting a socket for an incoming UDP packet, use the information
available in sock_reuseport if present.

This required adding an additional field to the UDP source address
equality function to differentiate between exact and wildcard matches.
The original use case allowed wildcard matches when checking for
existing port uses during bind.  The new use case of adding a socket
to a reuseport group requires exact address matching.

Performance test (using a machine with 2 CPU sockets and a total of
48 cores):  Create reuseport groups of varying size.  Use one socket
from this group per user thread (pinning each thread to a different
core) calling recvmmsg in a tight loop.  Record number of messages
received per second while saturating a 10G link.
  10 sockets: 18% increase (~2.8M -> 3.3M pkts/s)
  20 sockets: 14% increase (~2.9M -> 3.3M pkts/s)
  40 sockets: 13% increase (~3.0M -> 3.4M pkts/s)

This work is based off a similar implementation written by
Ying Cai  for implementing policy-based reuseport
selection.

Signed-off-by: Craig Gallek 
---
 include/net/addrconf.h   |   3 +-
 include/net/udp.h|   2 +-
 net/ipv4/udp.c   | 119 +++
 net/ipv6/inet6_connection_sock.c |   4 +-
 net/ipv6/udp.c   |  48 +---
 5 files changed, 141 insertions(+), 35 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 78003df..47f52d3 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -87,7 +87,8 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr 
*addr,
  u32 banned_flags);
 int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
u32 banned_flags);
-int ipv6_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2);
+int ipv6_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
+bool match_wildcard);
 void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr);
 void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr 
*addr);
 
diff --git a/include/net/udp.h b/include/net/udp.h
index 6d4ed18..3b5d7f9 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -191,7 +191,7 @@ static inline void udp_lib_close(struct sock *sk, long 
timeout)
 }
 
 int udp_lib_get_port(struct sock *sk, unsigned short snum,
-int (*)(const struct sock *, const struct sock *),
+int (*)(const struct sock *, const struct sock *, bool),
 unsigned int hash2_nulladdr);
 
 u32 udp_flow_hashrnd(void);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 8841e98..de2e1c0 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -113,6 +113,7 @@
 #include 
 #include 
 #include "udp_impl.h"
+#include 
 
 struct udp_table udp_table __read_mostly;
 EXPORT_SYMBOL(udp_table);
@@ -137,7 +138,8 @@ static int udp_lib_lport_inuse(struct net *net, __u16 num,
   unsigned long *bitmap,
   struct sock *sk,
   int (*saddr_comp)(const struct sock *sk1,
-const struct sock *sk2),
+const struct sock *sk2,
+bool match_wildcard),
   unsigned int log)
 {
struct sock *sk2;
@@ -152,8 +154,9 @@ static int udp_lib_lport_inuse(struct net *net, __u16 num,
(!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if ||
 sk2->sk_bound_dev_if == sk->sk_bound_dev_if) &&
(!sk2->sk_reuseport || !sk->sk_reuseport ||
+rcu_access_pointer(sk->sk_reuseport_cb) ||
 !uid_eq(uid, sock_i_uid(sk2))) &&
-   saddr_comp(sk, sk2)) {
+   saddr_comp(sk, sk2, true)) {
if (!bitmap)
return 1;
__set_bit(udp_sk(sk2)->udp_port_hash >> log, bitmap);
@@ -170,7 +173,8 @@ static int udp_lib_lport_inuse2(struct net *net, __u16 num,
struct udp_hslot *hslot2,
struct sock *sk,
int (*saddr_comp)(const struct sock *sk1,
- const struct sock *sk2))
+ const struct sock *sk2,
+ bool match_wildcard))
 {
struct sock *sk2;
struct hlist_nulls_node *node;
@@ -186,8 +190,9 @@ static int udp_lib_lport_inuse2(struct net *net, __u16 num,
(!sk2->sk_bound_dev_if || 

Re: [PATCH] ath6kl: Use vmalloc to allocate ar->fw for api1 method

2015-12-29 Thread Souptick Joarder
Brent,

On Tue, Dec 22, 2015 at 2:42 PM, Kalle Valo  wrote:
> Souptick Joarder  writes:
>
>> Hi Brent,
>>
>> On Tue, Dec 22, 2015 at 3:23 AM, Brent Taylor  wrote:
>>> On Mon, Dec 21, 2015 at 1:23 PM, Souptick Joarder  
>>> wrote:
 Hi Brent,

 On Tue, Dec 1, 2015 at 11:11 AM, Brent Taylor  wrote:

> --- a/drivers/net/wireless/ath/ath6kl/init.c
> +++ b/drivers/net/wireless/ath/ath6kl/init.c
> @@ -673,10 +673,15 @@ static int ath6kl_get_fw(struct ath6kl *ar, const 
> char *filename,
> return ret;
>
> *fw_len = fw_entry->size;
> -   *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
> +   if (>fw == fw)
> +   *fw = vmalloc(fw_entry->size);
> +   else
> +   *fw = kmalloc(fw_entry->size, GFP_KERNEL)

   Why vmalloc and kmalloc both are required? can't use either
 vmalloc or kmalloc?
>>>
>>> My original problem was that kmemdup (which uses kmalloc) could not
>>> allocate enough memory
>>
>> If kmemdump ( which uses kmalloc) could not allocate memory then
>> using kmalloc again can lead to same problem.
>> I guess it will be correct to use
>> *fw = vmalloc(fw_entry->size);
>> Correct me if i am wrong.
>
> That sounds best. But remember take into account DMA requirements, IIRC
> you cannot DMA from vmalloc memory on all platforms.

Is it possible to modify the patch as per feedback from Kalle.

>
> --
> Kalle Valo

-Souptick
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

2015-12-29 Thread Rob Herring
On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> Signed-off-by: Bjorn Andersson 
> ---
>  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> ++
>  1 file changed, 76 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> new file mode 100644
> index ..7b314b9f30af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> @@ -0,0 +1,76 @@
> +Qualcomm WCN36xx WiFi Binding
> +
> +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware block
> +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> variety
> +of Qualcomm platforms.

Are BT/FM functions completely separate? If so, separate bindings are 
okay. If not, then we need to describe the full chip.

Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" 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 3/3] bpf: hash: use per-bucket spinlock

2015-12-29 Thread Daniel Borkmann

On 12/29/2015 03:40 PM, Ming Lei wrote:

Both htab_map_update_elem() and htab_map_delete_elem() can be
called from eBPF program, and they may be in kernel hot path,
so it isn't efficient to use a per-hashtable lock in this two
helpers.

The per-hashtable spinlock is used for protecting bucket's
hlist, and per-bucket lock is just enough. This patch converts
the per-hashtable lock into per-bucket spinlock, so that
contention can be decreased a lot.

Signed-off-by: Ming Lei 


Looks better, thanks!

Acked-by: Daniel Borkmann 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

2015-12-29 Thread Bjorn Andersson
On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:

> On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > ++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > new file mode 100644
> > index ..7b314b9f30af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > @@ -0,0 +1,76 @@
> > +Qualcomm WCN36xx WiFi Binding
> > +
> > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > block
> > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > variety
> > +of Qualcomm platforms.
> 
> Are BT/FM functions completely separate? If so, separate bindings are 
> okay. If not, then we need to describe the full chip.
> 

It's three different hardware blocks (WiFi, BT and FM-radio) with shared
RF-hardware and an ARM core for control logic.

There seems to be some control commands going towards the BT part that
controls coexistence properties of the RF-hardware, but other than that
I see it as logically separate blocks.


So I think it's fine to model this as separate pieces in DT.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed

2015-12-29 Thread Rustad, Mark D
Emil S  wrote:

>>  */
>> -if (hw->mac.type == ixgbe_mac_X540)
>> +if ((hw->mac.type == ixgbe_mac_X540) &&
>> +(netdev->flags & IFF_SLAVE))
>>  if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
>>  return;
> 
> If you were to enter ixgbe_watchdog_link_is_up() with unknown speed, then I 
> would
> assume that you also have a dmesg that shows:
> "NIC Link is Up unknown speed"
> 
> by the interface you use in the bond?

It seems odd to be checking the MAC type for this. Is this behavior perhaps 
more related to the copper phy? If so, then the check should be changed. Or 
would the check for unknown link speed be sufficient? It seems like an 
interface as a slave would not work with an unknown link speed, so it may as 
well wait in all cases, not just for X540.

--
Mark Rustad, Networking Division, Intel Corporation


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [PATCH net-next 3/4] soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF

2015-12-29 Thread Craig Gallek
On Sat, Dec 26, 2015 at 2:05 PM, Craig Gallek  wrote:
> On Thu, Dec 24, 2015 at 11:36 AM, Alexei Starovoitov
>  wrote:
>> On Tue, Dec 22, 2015 at 03:05:09PM -0500, Craig Gallek wrote:
>>> + /* temporarily advance data past protocol header */
>>> + if (skb_headlen(skb) < hdr_len || !skb_pull_inline(skb, hdr_len)) {
>>
>> though bpf core will read just fine past linear part of the packet,
>> here we're limiting this feature only to packets where udp header is
>> part of headlen. Will it make it somewhat unreliable?
>> May be we can avoid doing this pull/push and use negative load
>> instructions with SKF_NET_OFF ? Something like:
>> load_word(skb, SKF_NET_OFF + sizeof(struct udphdr)));
> This is an excellent point and will be even more relevant for TCP.
> I'll try to get this to work for v2.
Looking at this more closely, I think the right thing to do is to
simply change the headlen check here to pskb_may_pull.  This mirrors
the behavior in the receive path when pulling headers.  It will also
maintain the convention of passing an skb to the bpf filter with the
data pointer advanced to the payload.
--
To unsubscribe from this list: send the line "unsubscribe netdev" 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, socket, socket_wq: fix missing initialization of flags

2015-12-29 Thread Eric Dumazet
On Tue, 2015-12-29 at 13:29 +0100, Nicolai Stange wrote:
> Fixes: ceb5d58b2170 ("net: fix sock_wake_async() rcu protection")

>  Sorry for any inconvenience this late-night induced brainfart might
>  have caused at your side...

Not really, because I read the source code and saw the bug there ;)

Acked-by: Eric Dumazet 



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


[PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

2015-12-29 Thread Jacob Siverskog
This should fix a NULL pointer dereference I encountered (dump
below). Since __skb_unlink is called while walking,
skb_queue_walk_safe should be used.

I investigated the oops and it seems like skb->next was NULL.

Oops:
Unable to handle kernel NULL pointer dereference at virtual address 0004
pgd = c5a7c000
[0004] *pgd=85ab6831, *pte=, *ppte=
Internal error: Oops: 817 [#1] PREEMPT ARM
Modules linked in: xt_tcpudp xt_state xt_nat wlcore_sdio wl18xx wl12xx wlcore 
rfcomm nf_log_arp nf_log_common iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 
nf_defrag_ipv4 iptable_filter ipt_REJECT nh
CPU: 0 PID: 11902 Comm: mdnsd Not tainted 4.3.0 #2
Hardware name: Generic AM33XX (Flattened Device Tree)udpv6_recvmsg
task: c7123040 ti: c58ce000 task.ti: c58ce000
PC is at __skb_recv_datagram+0x428/0x598
LR is at udpv6_recvmsg+0x1d0/0x6d0
pc : []lr : []psr: 6093
sp : c58cfd98  ip : 2013  fp : c7781040
r10: c58ce000  r9 :   r8 : c58cfe20
r7 : c58cfe1c  r6 : c06351d0  r5 : c77810ac  r4 : c583eac0
r3 :   r2 :   r1 :   r0 : 2013
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 85a7c019  DAC: 0051
Process mdnsd (pid: 11902, stack limit = 0xc58ce208)
Stack: (0xc58cfd98 to 0xc58d)
fd80:   0029 0008
fda0: c02fbc64   0040 c778115c c03a9ed8 c58cfdc4 0065
fdc0: 005d 00ff   fb00 0004  c0398d4c
fde0: c7781040 c58cff6c 22f8 be8383ec c06351d0  c06351d0 c0398f1c
fe00: c58cfe24 c58cfe70 be8383e4 0040  c77812a8  
fe20:  c58cfe2c 0004 c0398d4c c58cff6c c6a25c00 c58cfeb8 be8383ec
fe40: be838408   c0367a2c  c58cfe5c c58cff6c 
fe60: c6a25c00 c58cff6c 0040 c02efff4  be838874 be8388c0 22f8
fe80: c0618d78  ff14338a 9abb1afe b2b617e7 0ab4 b2b99e16 0ab4
fea0: c6a1fcc0 c0608374 c0608374   0001 e914000a 
fec0: 80fe  ff14338a 9abb1afe 0004   c00499ac
fee0: c77ac000 0002 c063a848   c0049c9c  c5a74c80
ff00: c77ac018 c7123040 2dfb 0c95f107 c58cff78 05106300 2dfb 0051
ff20: be83ac08 0001 0018 be83ac08 0008  0004 be8383ec
ff40: c6a25c00  0129 c000f3a4 c58ce000 c02f0d74  be83ac08
ff60: c58cff78  fff7 c58cfeb8    22f8
ff80: c58cfe78 0001 be838408 0400   be838890 be83883f
ffa0:  c000f1e0 be838890 be83883f 000e be8383ec  
ffc0: be838890 be83883f  0129 be838848  be838844 
ffe0: 0006a228 be8383c8 ea5c b6f39fd8 6010 000e  
[] (__skb_recv_datagram) from [] (udpv6_recvmsg+0x1d0/0x6d0)
[] (udpv6_recvmsg) from [] (inet_recvmsg+0x38/0x4c)
[] (inet_recvmsg) from [] (___sys_recvmsg+0x94/0x170)
[] (___sys_recvmsg) from [] (__sys_recvmsg+0x3c/0x6c)
[] (__sys_recvmsg) from [] (ret_fast_syscall+0x0/0x3c)
Code: e58b3074 e894000c e5841000 e5841004 (e5823004)
---[ end trace d16f25559f81d2a9 ]---
note: mdnsd[11902] exited with preempt_count 1
Unable to handle kernel NULL pointer dereference at virtual address 0004
pgd = c0004000
[0004] *pgd=
Internal error: Oops: 817 [#2] PREEMPT ARM
Modules linked in: xt_tcpudp xt_state xt_nat wlcore_sdio wl18xx wl12xx wlcore 
rfcomm nf_log_arp nf_log_common iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 
nf_defrag_ipv4 iptable_filter ipt_REJECT nh
CPU: 0 PID: 11902 Comm: mdnsd Tainted: G  D 4.3.0 #2
Hardware name: Generic AM33XX (Flattened Device Tree)
task: c7123040 ti: c58ce000 task.ti: c58ce000
PC is at inet_sock_destruct+0x40/0x1d0
LR is at sk_destruct+0x18/0xe0
pc : []lr : []psr: a113
sp : c58cfb28  ip : 001180f9  fp : c7123040
r10: c5941a08  r9 :   r8 : 0008
r7 : c7051950  r6 : c77810ac  r5 :   r4 : c7781040
r3 : c583eac0  r2 :   r1 :   r0 : c583eac0
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 858fc019  DAC: 0051
Process mdnsd (pid: 11902, stack limit = 0xc58ce208)
Stack: (0xc58cfb28 to 0xc58d)
fb20:   c7781040 c6a25c00 c6a534c8 c02f3d7c c06351d0 c7781040
fb40: c6a25c00 c0367f0c c037cfa8 c6a25c00  c02ee878 c02ee8f0 c5941a00
fb60: c6a25c20 c02ee8fc c02ee8f0 c00c2f04   c7123338 c5a8a700
fb80: c7123040 c063bd08 c5a74cb4 0001 c06079d0 c0047600 007f 
fba0: c06079d0 6193 c58cfbb8 c0030308 c063be28 c0087514 c0668f2c c063a9c4
fbc0: c06079d0 c063a9c4 c06079d0 6193 000b 0001 c02fc0aa c06079d0
fbe0: c0534fa0 c00127e4 c58ce208 000b   0008 c063a9c4
fc00: c58ce000 bf00 658cfd48 33623835 20343730 34393865 63303030 38356520
fc20: 30303134 35652030 30313438 28203430 32383565 34303033 

Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

2015-12-29 Thread Andy Gross
On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> 
> Signed-off-by: Bjorn Andersson 
> ---



> +
> +- qcom,wcnss-mmio:
> + Usage: required
> + Value type: 

nit:  encoded

> + Definition: should specify base address and size of the WiFi related
> + registers of WCNSS
> +
> +- qcom,state:
> + Usage: required
> + Value type: 
> + Definition: should specify the tx-enable and tx-ring-empty state
> + references
> +



Otherwise looks good.

Reviewed-by: Andy Gross 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Q: bad routing table cache entries

2015-12-29 Thread Stas Sergeev
29.12.2015 18:38, Stas Sergeev пишет:
> Likely the router's side is doing the right thing, but of
Or maybe not?
Here's the ifconfig of router:

eth0  Link encap:Ethernet  HWaddr 00:1e:8c:a7:b5:36
  inet addr:192.168.0.220  Bcast:192.168.3.255  Mask:255.255.252.0

eth0:1Link encap:Ethernet  HWaddr 00:1e:8c:a7:b5:36
  inet addr:192.168.8.1  Bcast:192.168.11.255  Mask:255.255.252.0


# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
default 192.168.0.1 0.0.0.0 UG0  00 eth0
10.1.10.0   192.168.10.143  255.255.255.0   UG0  00 eth0
localnet*   255.255.252.0   U 0  00 eth0
192.168.8.0 *   255.255.252.0   U 0  00 eth0


Masks look correct.
So why would it send redirects to hosts of 192.168.8.0 subnet
with the gateway of 192.168.0.0 subnet?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Q: bad routing table cache entries

2015-12-29 Thread Stas Sergeev
29.12.2015 18:22, Sowmini Varadhan пишет:
> Do you have admin control over the ubuntu router?
> If yes, you might want to check the shared_media [#] setting 
> on that router for the interfaces with overlapping subnets.
> (it is on by default, I would try turning it off).
Ahha, good catch, thanks!
Done that, then
ip route flush cache
on host, and am waiting for the problem to re-appear.
Hope it won't... but to say for sure I'll need a day or 2,
as it is not very fast to appear.


> AFAICT, the code does the right thing per rfc1812 when setting
> IPSKB_DOREDIRECT if shared_media is turned off.
Likely the router's side is doing the right thing, but of
course there are still many questions about the host's side.
Namely, why the bad entries were allowed, and how to list them?
The problem would not happen if they are rejected based on a
simple netmask check.

Thanks for your help so far! With shared_media hint you've pretty
likely saved me from lots of headache. :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed

2015-12-29 Thread Tantilov, Emil S
>-Original Message-
>From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
>Behalf Of zyjzyj2...@gmail.com
>Sent: Monday, December 28, 2015 6:32 PM
>To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
>Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John; Williams, Mitch
>A; intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; e1000-
>de...@lists.sourceforge.net
>Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
>Vincent (Wind River)
>Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of
>link_up and speed
>
>From: Zhu Yanjun 
>
>When the X540 NIC acts as a slave of some virtual NICs, it is very
>important to synchronize link_up and link_speed, such as a bonding
>driver in 802.3ad mode. When X540 NIC acts as an independent interface,
>it is not necessary to synchronize link_up and link_speed. That is,
>the time span between link_up and link_speed is acceptable.

What exactly do you mean by "time span between link_up and link_speed"?
Where is it you think the de-synchronization occurs?

>Signed-off-by: Zhu Yanjun 
>---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>index ace21b9..1bb6056 100644
>--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>@@ -6436,8 +6436,15 @@ static void ixgbe_watchdog_link_is_up(struct
>ixgbe_adapter *adapter)
>* time. To X540 NIC, there is a time span between link_up and
>* link_speed. As such, only continue if link_up and link_speed are
>* ready to X540 NIC.
>+   * The time span between link_up and link_speed is very important
>+   * when the X540 NIC acts as a slave in some virtual NICs, such as
>+   * a bonding driver in 802.3ad mode. When X540 NIC acts as an
>+   * independent interface, it is not necessary to synchronize link_up
>+   * and link_speed.
>+   * In the end, not continue if (X540 NIC && SLAVE && link_speed
>UNKNOWN)

This is a patch on top of your previous patch which I don't think was applied, 
so this is not going to apply cleanly.

>*/
>-  if (hw->mac.type == ixgbe_mac_X540)
>+  if ((hw->mac.type == ixgbe_mac_X540) &&
>+  (netdev->flags & IFF_SLAVE))
>   if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
>   return;

If you were to enter ixgbe_watchdog_link_is_up() with unknown speed, then I 
would
assume that you also have a dmesg that shows:
"NIC Link is Up unknown speed"

by the interface you use in the bond?

Thanks,
Emil

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


[PATCH v2 net-next 0/4] Faster SO_REUSEPORT

2015-12-29 Thread Craig Gallek
From: Craig Gallek 

This series contains two optimizations for the SO_REUSEPORT feature:
Faster lookup when selecting a socket for an incoming packet and
the ability to select the socket from the group using a BPF program.

This series only includes the UDP path.  I plan to submit a follow-up
including the TCP path if the implementation in this series is
acceptable.

Changes in v2:
- Fix ARM build; remove unnecessary include.
- Handle case where protocol header is not in linear section (per
  Alexei Starovoitov).

Craig Gallek (4):
  soreuseport: define reuseport groups
  soreuseport: fast reuseport UDP socket selection
  soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF
  soreuseport: BPF selection functional test

 arch/alpha/include/uapi/asm/socket.h|   3 +
 arch/avr32/include/uapi/asm/socket.h|   3 +
 arch/frv/include/uapi/asm/socket.h  |   3 +
 arch/ia64/include/uapi/asm/socket.h |   3 +
 arch/m32r/include/uapi/asm/socket.h |   3 +
 arch/mips/include/uapi/asm/socket.h |   3 +
 arch/mn10300/include/uapi/asm/socket.h  |   3 +
 arch/parisc/include/uapi/asm/socket.h   |   3 +
 arch/powerpc/include/uapi/asm/socket.h  |   3 +
 arch/s390/include/uapi/asm/socket.h |   3 +
 arch/sparc/include/uapi/asm/socket.h|   3 +
 arch/xtensa/include/uapi/asm/socket.h   |   3 +
 include/linux/filter.h  |   2 +
 include/net/addrconf.h  |   3 +-
 include/net/sock.h  |   2 +
 include/net/sock_reuseport.h|  28 ++
 include/net/udp.h   |   7 +-
 include/uapi/asm-generic/socket.h   |   3 +
 net/core/Makefile   |   2 +-
 net/core/filter.c   | 120 +--
 net/core/sock.c |  29 ++
 net/core/sock_reuseport.c   | 251 +++
 net/ipv4/udp.c  | 127 ++--
 net/ipv4/udp_diag.c |   4 +-
 net/ipv6/inet6_connection_sock.c|   4 +-
 net/ipv6/udp.c  |  56 +++-
 tools/testing/selftests/net/.gitignore  |   1 +
 tools/testing/selftests/net/Makefile|   2 +-
 tools/testing/selftests/net/reuseport_bpf.c | 467 
 29 files changed, 1076 insertions(+), 68 deletions(-)
 create mode 100644 include/net/sock_reuseport.h
 create mode 100644 net/core/sock_reuseport.c
 create mode 100644 tools/testing/selftests/net/reuseport_bpf.c

-- 
2.6.0.rc2.230.g3dd15c0

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


Re: Q: bad routing table cache entries

2015-12-29 Thread Sowmini Varadhan

Do you have admin control over the ubuntu router?
If yes, you might want to check the shared_media [#] setting 
on that router for the interfaces with overlapping subnets.
(it is on by default, I would try turning it off).

AFAICT, the code does the right thing per rfc1812 when setting
IPSKB_DOREDIRECT if shared_media is turned off.

--Sowmini

[#] https://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/theconfvariables.html

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


Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

2015-12-29 Thread Rob Herring
On Tue, Dec 29, 2015 at 11:03:57AM -0800, Bjorn Andersson wrote:
> On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:
> 
> > On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > > ++
> > >  1 file changed, 76 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > new file mode 100644
> > > index ..7b314b9f30af
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > > @@ -0,0 +1,76 @@
> > > +Qualcomm WCN36xx WiFi Binding
> > > +
> > > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > > block
> > > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > > variety
> > > +of Qualcomm platforms.
> > 
> > Are BT/FM functions completely separate? If so, separate bindings are 
> > okay. If not, then we need to describe the full chip.
> > 
> 
> It's three different hardware blocks (WiFi, BT and FM-radio) with shared
> RF-hardware and an ARM core for control logic.
> 
> There seems to be some control commands going towards the BT part that
> controls coexistence properties of the RF-hardware, but other than that
> I see it as logically separate blocks.
> 
> 
> So I think it's fine to model this as separate pieces in DT.

Okay.

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: nf_unregister_net_hook: hook not found!

2015-12-29 Thread Pablo Neira Ayuso
On Mon, Dec 28, 2015 at 09:05:03PM +0100, Sander Eikelenboom wrote:
> Hi,
> 
> Running a 4.4.0-rc6 kernel i encountered the warning below.

Cc'ing Eric Biederman.

@Sander, could you provide a way to reproduce this?

Thanks.

> [   13.740472] ip_tables: (C) 2000-2006 Netfilter Core Team
> [   13.936237] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
> [   13.945391] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
> [   13.947434] iwlwifi :03:00.0: Radio type=0x2-0x1-0x0
> [   14.223990] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
> [   14.232065] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
> [   14.233570] iwlwifi :03:00.0: Radio type=0x2-0x1-0x0
> [   14.328141] systemd-logind[2485]: Failed to start user service: Unknown
> unit: user@117.service
> [   14.356634] systemd-logind[2485]: New session c1 of user lightdm.
> [   14.357320] [ cut here ]
> [   14.357327] WARNING: CPU: 2 PID: 102 at net/netfilter/core.c:143
> netfilter_net_exit+0x25/0x50()
> [   14.357328] nf_unregister_net_hook: hook not found!
> [   14.357371] Modules linked in: iptable_security(+) iptable_raw
> iptable_filter ip_tables x_tables input_polldev bnep binfmt_misc nfsd
> auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc uvcvideo
> videobuf2_vmalloc iTCO_wdt arc4 videobuf2_memops iTCO_vendor_support
> intel_rapl iosf_mbi videobuf2_v4l2 x86_pkg_temp_thermal intel_powerclamp
> btusb coretemp snd_hda_codec_hdmi iwldvm videobuf2_core btrtl kvm_intel
> v4l2_common mac80211 videodev btbcm snd_hda_codec_conexant btintel media kvm
> snd_hda_codec_generic bluetooth psmouse thinkpad_acpi iwlwifi snd_hda_intel
> pcspkr serio_raw snd_hda_codec nvram cfg80211 snd_hwdep snd_hda_core rfkill
> i2c_i801 lpc_ich snd_pcm mfd_core snd_timer evdev snd soundcore shpchp
> tpm_tis tpm algif_skcipher af_alg crct10dif_pclmul crc32_pclmul crc32c_intel
> aesni_intel
> [   14.357380]  ehci_pci sdhci_pci aes_x86_64 glue_helper ehci_hcd e1000e
> lrw ablk_helper sg sdhci cryptd sd_mod ptp mmc_core usbcore usb_common
> pps_core
> [   14.357383] CPU: 2 PID: 102 Comm: kworker/u16:3 Tainted: G U
> 4.4.0-rc6-x220-20151224+ #1
> [   14.357384] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW (1.39 )
> 07/18/2013
> [   14.357390] Workqueue: netns cleanup_net
> [   14.357393]  81a27dfd 81359c69 88030e7cbd40
> 81060297
> [   14.357395]  88030e820d80 88030e7cbd90 81c962d8
> 81c962e0
> [   14.357397]  88030e7cbdf8 81060317 81a2c010
> 88030018
> [   14.357398] Call Trace:
> [   14.357405]  [] ? dump_stack+0x40/0x57
> [   14.357408]  [] ? warn_slowpath_common+0x77/0xb0
> [   14.357410]  [] ? warn_slowpath_fmt+0x47/0x50
> [   14.357416]  [] ? mutex_lock+0x9/0x30
> [   14.357418]  [] ? netfilter_net_exit+0x25/0x50
> [   14.357421]  [] ? ops_exit_list.isra.6+0x2e/0x60
> [   14.357424]  [] ? cleanup_net+0x1ab/0x280
> [   14.357427]  [] ? process_one_work+0x133/0x330
> [   14.357429]  [] ? worker_thread+0x60/0x470
> [   14.357430]  [] ? process_one_work+0x330/0x330
> [   14.357434]  [] ? kthread+0xca/0xe0
> [   14.357436]  [] ? kthread_create_on_node+0x170/0x170
> [   14.357439]  [] ? ret_from_fork+0x3f/0x70
> [   14.357441]  [] ? kthread_create_on_node+0x170/0x170
> [   14.357443] ---[ end trace 9984cc4b0e89f818 ]---
> [   14.357443] [ cut here ]
> [   14.357446] WARNING: CPU: 2 PID: 102 at net/netfilter/core.c:143
> netfilter_net_exit+0x25/0x50()
> [   14.357446] nf_unregister_net_hook: hook not found!
> [   14.357472] Modules linked in: iptable_security(+) iptable_raw
> iptable_filter ip_tables x_tables input_polldev bnep binfmt_misc nfsd
> auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc uvcvideo
> videobuf2_vmalloc iTCO_wdt arc4 videobuf2_memops iTCO_vendor_support
> intel_rapl iosf_mbi videobuf2_v4l2 x86_pkg_temp_thermal intel_powerclamp
> btusb coretemp snd_hda_codec_hdmi iwldvm videobuf2_core btrtl kvm_intel
> v4l2_common mac80211 videodev btbcm snd_hda_codec_conexant btintel media kvm
> snd_hda_codec_generic bluetooth psmouse thinkpad_acpi iwlwifi snd_hda_intel
> pcspkr serio_raw snd_hda_codec nvram cfg80211 snd_hwdep snd_hda_core rfkill
> i2c_i801 lpc_ich snd_pcm mfd_core snd_timer evdev snd soundcore shpchp
> tpm_tis tpm algif_skcipher af_alg crct10dif_pclmul crc32_pclmul crc32c_intel
> aesni_intel
> [   14.357478]  ehci_pci sdhci_pci aes_x86_64 glue_helper ehci_hcd e1000e
> lrw ablk_helper sg sdhci cryptd sd_mod ptp mmc_core usbcore usb_common
> pps_core
> [   14.357480] CPU: 2 PID: 102 Comm: kworker/u16:3 Tainted: G U  W
> 4.4.0-rc6-x220-20151224+ #1
> [   14.357481] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW (1.39 )
> 07/18/2013
> [   14.357484] Workqueue: netns cleanup_net
> [   14.357486]  81a27dfd 81359c69 88030e7cbd40
> 81060297
> [   14.357488]  88030e820db8 88030e7cbd90 81c962d8
> 81c962e0
> [   14.357489]  

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

2015-12-29 Thread kbuild test robot
Hi Gilad,

[auto build test WARNING on net/master]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Avidov/net-emac-emac-gigabit-ethernet-controller-driver/20151230-095104
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c:1090:9: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
 writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
^

vim +1090 drivers/net/ethernet/qualcomm/emac/emac-mac.c

  1074  }
  1075  }
  1076  
  1077  ret = request_irq(irq->irq, emac_isr, 0, EMAC_MAC_IRQ_RES, irq);
  1078  if (ret) {
  1079  netdev_err(adpt->netdev,
  1080 "error:%d on request_irq(%d:%s flags:0)\n", 
ret,
  1081 irq->irq, EMAC_MAC_IRQ_RES);
  1082  goto err_request_irq;
  1083  }
  1084  
  1085  emac_mac_rx_descs_refill(adpt, >rx_q);
  1086  
  1087  napi_enable(>rx_q.napi);
  1088  
  1089  /* enable mac irq */
> 1090  writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
  1091  writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
  1092  
  1093  netif_start_queue(netdev);
  1094  clear_bit(EMAC_STATUS_DOWN, >status);
  1095  
  1096  /* check link status */
  1097  set_bit(EMAC_STATUS_TASK_LSC_REQ, >status);
  1098  adpt->link_chk_timeout = jiffies + EMAC_TRY_LINK_TIMEOUT;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH v2 net-next 3/4] soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF

2015-12-29 Thread Alexei Starovoitov
On Tue, Dec 29, 2015 at 12:29:09PM -0500, Craig Gallek wrote:
> From: Craig Gallek 
> 
> Expose socket options for setting a classic or extended BPF program
> for use when selecting sockets in an SO_REUSEPORT group.  These options
> can be used on the first socket to belong to a group before bind or
> on any socket in the group after bind.
> 
> This change includes refactoring of the existing sk_filter code to
> allow reuse of the existing BPF filter validation checks.
> 
> Signed-off-by: Craig Gallek 
...
> @@ -75,6 +79,10 @@ static struct sock_reuseport *reuseport_grow(struct 
> sock_reuseport *reuse)
>   rcu_assign_pointer(reuse->socks[i]->sk_reuseport_cb,
>  more_reuse);
>  
> + /* Note: we use kfree_rcu here instead of reuseport_free_rcu so
> +  * that reuse and more_reuse can temporarily share a reference
> +  * to prog.
> +  */
>   kfree_rcu(reuse, rcu);
>   return more_reuse;

thanks for the comment. that bit definitely is tricky, but looks fine.

> +static struct sock *run_bpf(struct sock_reuseport *reuse, u16 socks,
> + struct bpf_prog *prog, struct sk_buff *skb,
> + int hdr_len)
> +{
> + struct sk_buff *nskb = NULL;
> + u32 index;
> +
> + if (skb_shared(skb)) {
> + nskb = skb_clone(skb, GFP_ATOMIC);
> + if (!nskb)
> + return NULL;
> + skb = nskb;
> + }
> +
> + /* temporarily advance data past protocol header */
> + if (!pskb_may_pull(skb, hdr_len) || !skb_pull_inline(skb, hdr_len)) {

pskb_pull() would be cleaner.

> + consume_skb(nskb);
> + return NULL;
> + }
> + index = bpf_prog_run_save_cb(prog, skb);
> + __skb_push(skb, hdr_len);

This indeed matches what normal bpf filters see with udp sockets, so
I guess that's fine.
Acked-by: Alexei Starovoitov 

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


Re: [PATCH] ixgbe: correctly handling failed allocation

2015-12-29 Thread Alexander Duyck
On Tue, Dec 29, 2015 at 1:55 PM, Insu Yun  wrote:
> Since kzalloc can be failed in memory pressure,
> NULL derefence could be happened.
>
> Signed-off-by: Insu Yun 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index aed8d02..aa5eda0 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -5331,6 +5331,8 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
> adapter->mac_table = kzalloc(sizeof(struct ixgbe_mac_addr) *
>  hw->mac.num_rar_entries,
>  GFP_ATOMIC);
> +   if (!adapter->mac_table)
> +   return -ENOMEM;
>
> /* Set MAC specific capability flags and exceptions */
> switch (hw->mac.type) {
> --
> 1.9.1

That change is already present in the current net-next.

Take a look at commit 530fd82a9fea ("ixgbe: Return error on failure to
allocate mac_table").

- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" 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 4/4] soreuseport: BPF selection functional test

2015-12-29 Thread Alexei Starovoitov
On Tue, Dec 29, 2015 at 12:29:10PM -0500, Craig Gallek wrote:
> From: Craig Gallek 
> 
> This program will build classic and extended BPF programs and
> validate the socket selection logic when used with
> SO_ATTACH_REUSEPORT_CBPF and SO_ATTACH_REUSEPORT_EBPF.
> 
> It also validates the re-programing flow and several edge cases.
> 
> Signed-off-by: Craig Gallek 

nice test.
Acked-by: Alexei Starovoitov 

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


Re: nf_unregister_net_hook: hook not found!

2015-12-29 Thread Eric W. Biederman
Pablo Neira Ayuso  writes:

> On Mon, Dec 28, 2015 at 09:05:03PM +0100, Sander Eikelenboom wrote:
>> Hi,
>> 
>> Running a 4.4.0-rc6 kernel i encountered the warning below.
>
> Cc'ing Eric Biederman.
>
> @Sander, could you provide a way to reproduce this?

I am on vacation until the new year, but if this is reproducible we
should be able to print out reg, reg->pf, reg->hooknum, reg->hook
to figure out which hook is having something very weird happen to it.

This is happening in some network namespace exit.

Eric


> Thanks.
>
>> [   13.740472] ip_tables: (C) 2000-2006 Netfilter Core Team
>> [   13.936237] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
>> [   13.945391] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
>> [   13.947434] iwlwifi :03:00.0: Radio type=0x2-0x1-0x0
>> [   14.223990] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
>> [   14.232065] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
>> [   14.233570] iwlwifi :03:00.0: Radio type=0x2-0x1-0x0
>> [   14.328141] systemd-logind[2485]: Failed to start user service: Unknown
>> unit: user@117.service
>> [   14.356634] systemd-logind[2485]: New session c1 of user lightdm.
>> [   14.357320] [ cut here ]
>> [   14.357327] WARNING: CPU: 2 PID: 102 at net/netfilter/core.c:143
>> netfilter_net_exit+0x25/0x50()
>> [   14.357328] nf_unregister_net_hook: hook not found!
>> [   14.357371] Modules linked in: iptable_security(+) iptable_raw
>> iptable_filter ip_tables x_tables input_polldev bnep binfmt_misc nfsd
>> auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc uvcvideo
>> videobuf2_vmalloc iTCO_wdt arc4 videobuf2_memops iTCO_vendor_support
>> intel_rapl iosf_mbi videobuf2_v4l2 x86_pkg_temp_thermal intel_powerclamp
>> btusb coretemp snd_hda_codec_hdmi iwldvm videobuf2_core btrtl kvm_intel
>> v4l2_common mac80211 videodev btbcm snd_hda_codec_conexant btintel media kvm
>> snd_hda_codec_generic bluetooth psmouse thinkpad_acpi iwlwifi snd_hda_intel
>> pcspkr serio_raw snd_hda_codec nvram cfg80211 snd_hwdep snd_hda_core rfkill
>> i2c_i801 lpc_ich snd_pcm mfd_core snd_timer evdev snd soundcore shpchp
>> tpm_tis tpm algif_skcipher af_alg crct10dif_pclmul crc32_pclmul crc32c_intel
>> aesni_intel
>> [   14.357380]  ehci_pci sdhci_pci aes_x86_64 glue_helper ehci_hcd e1000e
>> lrw ablk_helper sg sdhci cryptd sd_mod ptp mmc_core usbcore usb_common
>> pps_core
>> [   14.357383] CPU: 2 PID: 102 Comm: kworker/u16:3 Tainted: G U
>> 4.4.0-rc6-x220-20151224+ #1
>> [   14.357384] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW (1.39 )
>> 07/18/2013
>> [   14.357390] Workqueue: netns cleanup_net
>> [   14.357393]  81a27dfd 81359c69 88030e7cbd40
>> 81060297
>> [   14.357395]  88030e820d80 88030e7cbd90 81c962d8
>> 81c962e0
>> [   14.357397]  88030e7cbdf8 81060317 81a2c010
>> 88030018
>> [   14.357398] Call Trace:
>> [   14.357405]  [] ? dump_stack+0x40/0x57
>> [   14.357408]  [] ? warn_slowpath_common+0x77/0xb0
>> [   14.357410]  [] ? warn_slowpath_fmt+0x47/0x50
>> [   14.357416]  [] ? mutex_lock+0x9/0x30
>> [   14.357418]  [] ? netfilter_net_exit+0x25/0x50
>> [   14.357421]  [] ? ops_exit_list.isra.6+0x2e/0x60
>> [   14.357424]  [] ? cleanup_net+0x1ab/0x280
>> [   14.357427]  [] ? process_one_work+0x133/0x330
>> [   14.357429]  [] ? worker_thread+0x60/0x470
>> [   14.357430]  [] ? process_one_work+0x330/0x330
>> [   14.357434]  [] ? kthread+0xca/0xe0
>> [   14.357436]  [] ? kthread_create_on_node+0x170/0x170
>> [   14.357439]  [] ? ret_from_fork+0x3f/0x70
>> [   14.357441]  [] ? kthread_create_on_node+0x170/0x170
>> [   14.357443] ---[ end trace 9984cc4b0e89f818 ]---
>> [   14.357443] [ cut here ]
>> [   14.357446] WARNING: CPU: 2 PID: 102 at net/netfilter/core.c:143
>> netfilter_net_exit+0x25/0x50()
>> [   14.357446] nf_unregister_net_hook: hook not found!
>> [   14.357472] Modules linked in: iptable_security(+) iptable_raw
>> iptable_filter ip_tables x_tables input_polldev bnep binfmt_misc nfsd
>> auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc uvcvideo
>> videobuf2_vmalloc iTCO_wdt arc4 videobuf2_memops iTCO_vendor_support
>> intel_rapl iosf_mbi videobuf2_v4l2 x86_pkg_temp_thermal intel_powerclamp
>> btusb coretemp snd_hda_codec_hdmi iwldvm videobuf2_core btrtl kvm_intel
>> v4l2_common mac80211 videodev btbcm snd_hda_codec_conexant btintel media kvm
>> snd_hda_codec_generic bluetooth psmouse thinkpad_acpi iwlwifi snd_hda_intel
>> pcspkr serio_raw snd_hda_codec nvram cfg80211 snd_hwdep snd_hda_core rfkill
>> i2c_i801 lpc_ich snd_pcm mfd_core snd_timer evdev snd soundcore shpchp
>> tpm_tis tpm algif_skcipher af_alg crct10dif_pclmul crc32_pclmul crc32c_intel
>> aesni_intel
>> [   14.357478]  ehci_pci sdhci_pci aes_x86_64 glue_helper ehci_hcd e1000e
>> lrw ablk_helper sg sdhci cryptd sd_mod ptp mmc_core usbcore usb_common
>> pps_core
>> [   14.357480] CPU: 2 PID: 102 Comm: 

Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed

2015-12-29 Thread zhuyj

On 12/30/2015 12:18 AM, Tantilov, Emil S wrote:

-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of zyjzyj2...@gmail.com
Sent: Monday, December 28, 2015 6:32 PM
To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John; Williams, Mitch
A; intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; e1000-
de...@lists.sourceforge.net
Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
Vincent (Wind River)
Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of
link_up and speed

From: Zhu Yanjun 

When the X540 NIC acts as a slave of some virtual NICs, it is very
important to synchronize link_up and link_speed, such as a bonding
driver in 802.3ad mode. When X540 NIC acts as an independent interface,
it is not necessary to synchronize link_up and link_speed. That is,
the time span between link_up and link_speed is acceptable.

What exactly do you mean by "time span between link_up and link_speed"?


In the previous mail, I show you some ethtool logs. In these logs, there 
is some
time with NIC up while speed is unknown. I think this "some time" is 
time span between

link_up and link_speed. Please see the previous mail for details.


Where is it you think the de-synchronization occurs?


When a NIC interface acts as a slave, a flag "IFF_SLAVE" is set in 
netdevice struct.
Before we enter this function, we check IFF_SLAVE flag. If this flag is 
set, we continue to check
link_speed. If not, this function is executed whether this link_speed is 
unknown or not.





Signed-off-by: Zhu Yanjun 
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index ace21b9..1bb6056 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6436,8 +6436,15 @@ static void ixgbe_watchdog_link_is_up(struct
ixgbe_adapter *adapter)
 * time. To X540 NIC, there is a time span between link_up and
 * link_speed. As such, only continue if link_up and link_speed are
 * ready to X540 NIC.
+* The time span between link_up and link_speed is very important
+* when the X540 NIC acts as a slave in some virtual NICs, such as
+* a bonding driver in 802.3ad mode. When X540 NIC acts as an
+* independent interface, it is not necessary to synchronize link_up
+* and link_speed.
+* In the end, not continue if (X540 NIC && SLAVE && link_speed
UNKNOWN)

This is a patch on top of your previous patch which I don't think was applied,
so this is not going to apply cleanly.


 */
-   if (hw->mac.type == ixgbe_mac_X540)
+   if ((hw->mac.type == ixgbe_mac_X540) &&
+   (netdev->flags & IFF_SLAVE))
if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
return;

If you were to enter ixgbe_watchdog_link_is_up() with unknown speed, then I 
would
assume that you also have a dmesg that shows:
"NIC Link is Up unknown speed"

by the interface you use in the bond?

Sure. There is a dmesg log from the customer.
"
...
2015-10-05T06:14:34.350 controller-0 kernel: info bonding: bond0: link 
status definitely up for interface eth0, 0 Mbps full duplex.

...
"

Thanks a lot.
Zhu Yanjun


Thanks,
Emil



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


Re: [PATCH 2/3] drivers: net: cpsw: fix error messages when using phy-handle DT property

2015-12-29 Thread Rob Herring
On Tue, Dec 22, 2015 at 07:36:33PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> and only one need be specified. However if phy-handle was specified, an
> error message would complain about the lack of phy_id or fixed-link.
> 
> Also, if phy-handle was specified and the subsequent of_phy_connect()
> failed, the error message still referenced slaved->data->phy_id, which
> would be empty. Instead, use the name of the device_node as a useful
> identifier.
> 
> Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
> Signed-off-by: David Rivshin 
> ---
> This would require some adjustments to backport to 4.3-stable due to
> other changes in this area. Let me know if you want a version of this
> against v4.3.3.
> 
>  Documentation/devicetree/bindings/net/cpsw.txt |  4 ++--

For the binding:

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND PATCH v1 3/4] net: ethernet: arc: Add support emac for RK3036

2015-12-29 Thread Florian Fainelli
On December 27, 2015 11:22:20 PM PST, Xing Zheng  
wrote:
>The RK3036's GRFs offset are different with RK3066/RK3188, and need to
>set
>mac TX/RX clock before probe emac.
>
>Signed-off-by: Xing Zheng 
>---

> };
> 
> static const struct of_device_id emac_rockchip_dt_ids[] = {
>-  { .compatible = "rockchip,rk3066-emac", .data =
>_rockchip_dt_data[0] },
>-  { .compatible = "rockchip,rk3188-emac", .data =
>_rockchip_dt_data[1] },
>+  { .compatible = "rockchip,rk3036-emac", .data =
>_rockchip_dt_data[0] },
>+  { .compatible = "rockchip,rk3066-emac", .data =
>_rockchip_dt_data[1] },
>+  { .compatible = "rockchip,rk3188-emac", .data =
>_rockchip_dt_data[2] },
>   { /* Sentinel */ }

Food for thought, you might want to use an enum here to index 
emac_rockchip_dt_data which would be less error prone if you add/remove entries 
in this structure.

-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND PATCH v1 3/4] net: ethernet: arc: Add support emac for RK3036

2015-12-29 Thread Heiko Stübner
Am Dienstag, 29. Dezember 2015, 14:59:59 schrieb Florian Fainelli:
> On December 27, 2015 11:22:20 PM PST, Xing Zheng  
wrote:
> >The RK3036's GRFs offset are different with RK3066/RK3188, and need to
> >set
> >mac TX/RX clock before probe emac.
> >
> >Signed-off-by: Xing Zheng 
> >---
> 
> 
> 
> > };
> > 
> > static const struct of_device_id emac_rockchip_dt_ids[] = {
> >
> >-{ .compatible = "rockchip,rk3066-emac", .data =
> >_rockchip_dt_data[0] },
> >-{ .compatible = "rockchip,rk3188-emac", .data =
> >_rockchip_dt_data[1] },
> >+{ .compatible = "rockchip,rk3036-emac", .data =
> >_rockchip_dt_data[0] },
> >+{ .compatible = "rockchip,rk3066-emac", .data =
> >_rockchip_dt_data[1] },
> >+{ .compatible = "rockchip,rk3188-emac", .data =
> >_rockchip_dt_data[2] },
> >
> > { /* Sentinel */ }
> 
> Food for thought, you might want to use an enum here to index
> emac_rockchip_dt_data which would be less error prone if you add/remove
> entries in this structure.

Or just have the structs separately and not in array-form at all, aka
rk3066_emac_dt_data, rk3036_emac_dt_data.

I don't think the original array really improves anything.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

2015-12-29 Thread David Miller
From: Heiko Stübner 
Date: Tue, 29 Dec 2015 23:27:55 +0100

> Hi Dave,
> 
> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend twice
>> now.
>> 
>> When you submit a series you should:
>> 
>> 1) Make it clear which tree you expect these changes to be applied
>>to.  Here it is completely ambiguous, do you want it to go into
>>my networking tree or some other subsystem tree?
>> 
>> 2) You MUST keep all parties informed about all patches for a series
>>like this.  That means you cannot drop netdev from patch #4 as
>>you did both times.  Doing this aggravates the situation for
>>#1 even more, because if a patch is not CC:'d to netdev it does
>>not enter patchwork.  And if it doesn't go into patchwork, I'm
>>not looking at it.
> 
> I guess that is some unfortunate result of git send-email combined with 
> get_maintainer.pl . In general I also prefer to see the whole series, but 
> have 
> gotten such partial series from other maintainers as well in the past, so it 
> seems to be depending on preferences somewhat.
> 
> For the series at hand, the 4th patch is the devicetree addition, which the 
> expected way is me picking it up, after you are comfortable with the code-
> related changes.

Why would it not be appropriate for a DT file change to go into my tree
if it corresponds to functionality created by the rest of the patches
in the series?

It looks better to put it all together as a unit, via one series, with
a merge commit containing your "[PATCH 0/N]" description in the commit
message.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

2015-12-29 Thread Florian Fainelli
On December 29, 2015 2:27:55 PM PST, "Heiko Stübner"  wrote:
>Hi Dave,
>
>Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend
>twice
>> now.
>> 
>> When you submit a series you should:
>> 
>> 1) Make it clear which tree you expect these changes to be applied
>>to.  Here it is completely ambiguous, do you want it to go into
>>my networking tree or some other subsystem tree?
>> 
>> 2) You MUST keep all parties informed about all patches for a series
>>like this.  That means you cannot drop netdev from patch #4 as
>>you did both times.  Doing this aggravates the situation for
>>#1 even more, because if a patch is not CC:'d to netdev it does
>>not enter patchwork.  And if it doesn't go into patchwork, I'm
>>not looking at it.
>
>I guess that is some unfortunate result of git send-email combined with
>
>get_maintainer.pl . In general I also prefer to see the whole series,
>but have 
>gotten such partial series from other maintainers as well in the past,
>so it 
>seems to be depending on preferences somewhat.

You could run get_maintainer.pl against the individual patches in the series, 
merge the cc list somewhere in a file/variable and then do the actual mail 
submission with that full list for all patches. There could be a way to 
automate that with a bit of help from git send-email eventually.

-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] mwifiex: correctly handling kzalloc

2015-12-29 Thread Andy Shevchenko
On Tue, Dec 29, 2015 at 10:17 PM, Insu Yun  wrote:

Empty commit message?

> Signed-off-by: Insu Yun 
> ---
>  drivers/net/wireless/mwifiex/sdio.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/sdio.c 
> b/drivers/net/wireless/mwifiex/sdio.c
> index 78a8474..a8af72d 100644
> --- a/drivers/net/wireless/mwifiex/sdio.c
> +++ b/drivers/net/wireless/mwifiex/sdio.c
> @@ -2053,8 +2053,19 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
> *adapter)
> /* Allocate skb pointer buffers */
> card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
>card->mp_agg_pkt_limit, GFP_KERNEL);

Just noticed: Looks like good candidate for kcalloc or kmalloc_array,
whichever is suitable.

> +   if (!card->mpa_rx.skb_arr) {
> +   kfree(card->mp_regs);
> +   return -ENOMEM;
> +   }
> +
> card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
>card->mp_agg_pkt_limit, GFP_KERNEL);

Ditto.

> +   if (!card->mpa_rx.len_arr) {
> +   kfree(card->mp_regs);
> +   kfree(card->mpa_rx.skb_arr);


> +   return -ENOMEM;
> +   }
> +
> ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
>  card->mp_tx_agg_buf_size,
>  card->mp_rx_agg_buf_size);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv3 net-next 1/3] ethtool: Add phy statistics

2015-12-29 Thread David Miller
From: Andrew Lunn 
Date: Tue, 29 Dec 2015 20:51:22 +0100

> @@ -191,6 +191,23 @@ static int ethtool_set_features(struct net_device *dev, 
> void __user *useraddr)
>   return ret;
>  }
>  
> +int phy_get_sset_count(struct phy_device *phydev)
> +{

This needs to be static.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH net-next v2 00/10] be2net: patch set

2015-12-29 Thread David Miller

Please fix the problems reported by the kbuild test robot, they happened
when I tried to build this too.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] mISDN: correctly handling failed allocation

2015-12-29 Thread Insu Yun
Since kzalloc can be failed in memory pressure,
NULL dereference might be happened.

Signed-off-by: Insu Yun 
---
 drivers/isdn/hardware/mISDN/hfcsusb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c 
b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 114f3bc..15164e9 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -264,6 +264,9 @@ hfcsusb_ph_info(struct hfcsusb *hw)
 
phi = kzalloc(sizeof(struct ph_info) +
  dch->dev.nrbchan * sizeof(struct ph_info_ch), GFP_ATOMIC);
+   if (!phi)
+   return;
+
phi->dch.ch.protocol = hw->protocol;
phi->dch.ch.Flags = dch->Flags;
phi->dch.state = dch->state;
-- 
1.9.1

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


Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

2015-12-29 Thread Heiko Stübner
Hi Dave,

Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
> You have to submit this series properly, the same problem happend twice
> now.
> 
> When you submit a series you should:
> 
> 1) Make it clear which tree you expect these changes to be applied
>to.  Here it is completely ambiguous, do you want it to go into
>my networking tree or some other subsystem tree?
> 
> 2) You MUST keep all parties informed about all patches for a series
>like this.  That means you cannot drop netdev from patch #4 as
>you did both times.  Doing this aggravates the situation for
>#1 even more, because if a patch is not CC:'d to netdev it does
>not enter patchwork.  And if it doesn't go into patchwork, I'm
>not looking at it.

I guess that is some unfortunate result of git send-email combined with 
get_maintainer.pl . In general I also prefer to see the whole series, but have 
gotten such partial series from other maintainers as well in the past, so it 
seems to be depending on preferences somewhat.

For the series at hand, the 4th patch is the devicetree addition, which the 
expected way is me picking it up, after you are comfortable with the code-
related changes.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH net-next 1/3] r8169:Fix typo in setting RTL8168EP and RTL8168H D3cold PFM mode

2015-12-29 Thread Francois Romieu
Chunhao Lin  :
> The register for setting D3code PFM mode is  MISC_1, not DLLPR.
> 
> Signed-off-by: Chunhao Lin 

Reviewed-by: Francois Romieu 

-- 
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv3 net-next 2/3] phy: marvell: Add ethtool statistics counters

2015-12-29 Thread Andrew Lunn
The PHY counters receiver errors and errors while idle.

Signed-off-by: Andrew Lunn 
---
 drivers/net/phy/marvell.c | 135 ++
 1 file changed, 135 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 0240552b50f3..50b5eac75854 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -137,6 +137,22 @@ MODULE_DESCRIPTION("Marvell PHY driver");
 MODULE_AUTHOR("Andy Fleming");
 MODULE_LICENSE("GPL");
 
+struct marvell_hw_stat {
+   const char *string;
+   u8 page;
+   u8 reg;
+   u8 bits;
+};
+
+static struct marvell_hw_stat marvell_hw_stats[] = {
+   { "phy_receive_errors", 0, 21, 16},
+   { "phy_idle_errors", 0, 10, 8 },
+};
+
+struct marvell_priv {
+   u64 stats[ARRAY_SIZE(marvell_hw_stats)];
+};
+
 static int marvell_ack_interrupt(struct phy_device *phydev)
 {
int err;
@@ -986,12 +1002,80 @@ static int m88e1318_set_wol(struct phy_device *phydev, 
struct ethtool_wolinfo *w
return 0;
 }
 
+static int marvell_get_sset_count(struct phy_device *phydev)
+{
+   return ARRAY_SIZE(marvell_hw_stats);
+}
+
+static void marvell_get_strings(struct phy_device *phydev, u8 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++) {
+   memcpy(data + i * ETH_GSTRING_LEN,
+  marvell_hw_stats[i].string, ETH_GSTRING_LEN);
+   }
+}
+
+#ifndef UINT64_MAX
+#define UINT64_MAX  (u64)(~((u64)0))
+#endif
+static u64 marvell_get_stat(struct phy_device *phydev, int i)
+{
+   struct marvell_hw_stat stat = marvell_hw_stats[i];
+   struct marvell_priv *priv = phydev->priv;
+   int err, oldpage;
+   u64 val;
+
+   oldpage = phy_read(phydev, MII_MARVELL_PHY_PAGE);
+   err = phy_write(phydev, MII_MARVELL_PHY_PAGE,
+   stat.page);
+   if (err < 0)
+   return UINT64_MAX;
+
+   val = phy_read(phydev, stat.reg);
+   if (val < 0) {
+   val = UINT64_MAX;
+   } else {
+   val = val & ((1 << stat.bits) - 1);
+   priv->stats[i] += val;
+   val = priv->stats[i];
+   }
+
+   phy_write(phydev, MII_MARVELL_PHY_PAGE, oldpage);
+
+   return val;
+}
+
+static void marvell_get_stats(struct phy_device *phydev,
+ struct ethtool_stats *stats, u64 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++)
+   data[i] = marvell_get_stat(phydev, i);
+}
+
+static int marvell_probe(struct phy_device *phydev)
+{
+   struct marvell_priv *priv;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   phydev->priv = priv;
+
+   return 0;
+}
+
 static struct phy_driver marvell_drivers[] = {
{
.phy_id = MARVELL_PHY_ID_88E1101,
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1101",
.features = PHY_GBIT_FEATURES,
+   .probe = marvell_probe,
.flags = PHY_HAS_INTERRUPT,
.config_aneg = _config_aneg,
.read_status = _read_status,
@@ -999,6 +1083,9 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = _config_intr,
.resume = _resume,
.suspend = _suspend,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1007,6 +1094,7 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E1112",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+   .probe = marvell_probe,
.config_init = _config_init,
.config_aneg = _config_aneg,
.read_status = _read_status,
@@ -1014,6 +1102,9 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = _config_intr,
.resume = _resume,
.suspend = _suspend,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
.driver = { .owner = THIS_MODULE },
},
{
@@ -1022,6 +1113,7 @@ static struct phy_driver marvell_drivers[] = {
.name = "Marvell 88E",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
+   .probe = marvell_probe,
.config_init = _config_init,
.config_aneg = _config_aneg,
.read_status = _read_status,
@@ -1029,6 +1121,9 @@ static struct phy_driver marvell_drivers[] = {
.config_intr = _config_intr,
.resume = _resume,
  

Re: [PATCH net] openvswitch: Fix template leak in error cases.

2015-12-29 Thread David Miller
From: Joe Stringer 
Date: Wed, 23 Dec 2015 14:39:27 -0800

> Commit 5b48bb8506c5 ("openvswitch: Fix helper reference leak") fixed a
> reference leak on helper objects, but inadvertently introduced a leak on
> the ct template.
> 
> Previously, ct_info.ct->general.use was initialized to 0 by
> nf_ct_tmpl_alloc() and only incremented when ovs_ct_copy_action()
> returned successful. If an error occurred while adding the helper or
> adding the action to the actions buffer, the __ovs_ct_free_action()
> cleanup would use nf_ct_put() to free the entry; However, this relies on
> atomic_dec_and_test(ct_info.ct->general.use). This reference must be
> incremented first, or nf_ct_put() will never free it.
> 
> Fix the issue by acquiring a reference to the template immediately after
> allocation.
> 
> Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
> Fixes: 5b48bb8506c5 ("openvswitch: Fix helper reference leak")
> Signed-off-by: Joe Stringer 

Looks good, applied, thanks Joe.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] cxgb4: correctly handling failed allocation

2015-12-29 Thread Insu Yun
Since t4_alloc_mem can be failed in memory pressure,
if not properly handled, NULL dereference could be happened.

Signed-off-by: Insu Yun 
---
 drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c 
b/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
index c308429..11dd91e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
@@ -295,6 +295,10 @@ struct clip_tbl *t4_init_clip_tbl(unsigned int clipt_start,
INIT_LIST_HEAD(>hash_list[i]);
 
cl_list = t4_alloc_mem(clipt_size*sizeof(struct clip_entry));
+   if (!cl_list) {
+   t4_free_mem(ctbl);
+   return NULL;
+   }
ctbl->cl_list = (void *)cl_list;
 
for (i = 0; i < clipt_size; i++) {
-- 
1.9.1

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


[PATCH 1/1] include/uapi/linux/sockios.h: mark SIOCRTMSG unused

2015-12-29 Thread Heinrich Schuchardt
IOCTL SIOCRTMSG does nothing but return EINVAL.

So comment it as unused.

Signed-off-by: Heinrich Schuchardt 
---
 include/uapi/linux/sockios.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/sockios.h b/include/uapi/linux/sockios.h
index e888b1a..8e7890b 100644
--- a/include/uapi/linux/sockios.h
+++ b/include/uapi/linux/sockios.h
@@ -27,7 +27,7 @@
 /* Routing table calls. */
 #define SIOCADDRT  0x890B  /* add routing table entry  */
 #define SIOCDELRT  0x890C  /* delete routing table entry   */
-#define SIOCRTMSG  0x890D  /* call to routing system   */
+#define SIOCRTMSG  0x890D  /* unused   */
 
 /* Socket configuration controls. */
 #define SIOCGIFNAME0x8910  /* get iface name   */
-- 
2.1.4

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


[PATCH] qlcnic: correctly handle qlcnic_alloc_mbx_args

2015-12-29 Thread Insu Yun
Signed-off-by: Insu Yun 
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c 
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index a5f422f..a9a2c33 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -772,8 +772,10 @@ int qlcnic_82xx_config_intrpt(struct qlcnic_adapter 
*adapter, u8 op_type)
int i, err = 0;
 
for (i = 0; i < ahw->num_msix; i++) {
-   qlcnic_alloc_mbx_args(, adapter,
+   err = qlcnic_alloc_mbx_args(, adapter,
  QLCNIC_CMD_MQ_TX_CONFIG_INTR);
+   if (err)
+   return err;
type = op_type ? QLCNIC_INTRPT_ADD : QLCNIC_INTRPT_DEL;
val = type | (ahw->intr_tbl[i].type << 4);
if (ahw->intr_tbl[i].type == QLCNIC_INTRPT_MSIX)
-- 
1.9.1

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


Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

2015-12-29 Thread David Miller
From: Rainer Weikusat 
Date: Tue, 29 Dec 2015 19:42:36 +

> Jacob Siverskog  writes:
>> This should fix a NULL pointer dereference I encountered (dump
>> below). Since __skb_unlink is called while walking,
>> skb_queue_walk_safe should be used.
> 
> The code in question is:
 ...
> __skb_unlink is only called prior to returning from the function.
> Consequently, it won't affect the skb_queue_walk code.

Agreed, this patch doesn't fix anything.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

2015-12-29 Thread David Miller

You have to submit this series properly, the same problem happend twice
now.

When you submit a series you should:

1) Make it clear which tree you expect these changes to be applied
   to.  Here it is completely ambiguous, do you want it to go into
   my networking tree or some other subsystem tree?

2) You MUST keep all parties informed about all patches for a series
   like this.  That means you cannot drop netdev from patch #4 as
   you did both times.  Doing this aggravates the situation for
   #1 even more, because if a patch is not CC:'d to netdev it does
   not enter patchwork.  And if it doesn't go into patchwork, I'm
   not looking at it.

Thanks.

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


[PATCH] mISDN: correctly handling failed allocation in fsm

2015-12-29 Thread Insu Yun
Since kzalloc can be failed in memory pressure,
NULL dereference can be happened.

Signed-off-by: Insu Yun 
---
 drivers/isdn/mISDN/fsm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/isdn/mISDN/fsm.c b/drivers/isdn/mISDN/fsm.c
index 26477d4..3c3ffb0 100644
--- a/drivers/isdn/mISDN/fsm.c
+++ b/drivers/isdn/mISDN/fsm.c
@@ -34,6 +34,8 @@ mISDN_FsmNew(struct Fsm *fsm,
 
fsm->jumpmatrix = kzalloc(sizeof(FSMFNPTR) * fsm->state_count *
  fsm->event_count, GFP_KERNEL);
+   if (!fsm->jumpmatrix)
+   return;
 
for (i = 0; i < fncount; i++)
if ((fnlist[i].state >= fsm->state_count) ||
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe netdev" 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 0/3] bpf: hash: use per-bucket spinlock

2015-12-29 Thread David Miller
From: Ming Lei 
Date: Tue, 29 Dec 2015 22:40:24 +0800

> Hi,
> 
> This patchset tries to optimize ebpf hash map, and follows
> the idea:
> 
> Both htab_map_update_elem() and htab_map_delete_elem()
> can be called from eBPF program, and they may be in kernel
> hot path, it isn't efficient to use a per-hashtable lock
> in this two helpers, so this patch converts the lock into
> per-bucket spinlock.
> 
> With this patchset, looks the performance penalty from eBPF
> decreased a lot, see the following test:
> 
> 1) run 'tools/biolatency' of bcc before running block test;
> 
> 2) run fio to test block throught over /dev/nullb0,
> (randread, 16jobs, libaio, 4k bs) and the test box
> is one 24cores(dual sockets) VM server:
> - without patchset:  607K IOPS
> - with this patchset: 1184K IOPS
> - without running eBPF prog: 1492K IOPS

Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-29 Thread Willy Tarreau
On Tue, Dec 29, 2015 at 03:48:45PM +0100, Hannes Frederic Sowa wrote:
> On 28.12.2015 15:14, Willy Tarreau wrote:
> >It is possible for a process to allocate and accumulate far more FDs than
> >the process' limit by sending them over a unix socket then closing them
> >to keep the process' fd count low.
> >
> >This change addresses this problem by keeping track of the number of FDs
> >in flight per user and preventing non-privileged processes from having
> >more FDs in flight than their configured FD limit.
> >
> >Reported-by: socketp...@gmail.com
> >Suggested-by: Linus Torvalds 
> >Signed-off-by: Willy Tarreau 
> 
> Thanks for the patch!
> 
> I think this does not close the DoS attack completely as we duplicate 
> fds if the reader uses MSG_PEEK on the unix domain socket and thus 
> clones the fd. Have I overlooked something?

I didn't know this behaviour. However, then the fd remains in flight, right ?
So as long as it's not removed from the queue, the sender cannot add more
than its FD limit. I may be missing something obvious though :-/

Thanks,
Willy

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


Re: [PATCH 1/9] atm: solos-pci: use to_pci_dev()

2015-12-29 Thread David Miller
From: Geliang Tang 
Date: Sun, 27 Dec 2015 18:45:57 +0800

> Use to_pci_dev() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 06/10] net: hns: use to_platform_device()

2015-12-29 Thread David Miller
From: Geliang Tang 
Date: Sun, 27 Dec 2015 21:15:44 +0800

> Use to_platform_device() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang 

Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ixgbe: correctly handling failed allocation

2015-12-29 Thread Insu Yun
Since kzalloc can be failed in memory pressure,
NULL derefence could be happened.

Signed-off-by: Insu Yun 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index aed8d02..aa5eda0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5331,6 +5331,8 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
adapter->mac_table = kzalloc(sizeof(struct ixgbe_mac_addr) *
 hw->mac.num_rar_entries,
 GFP_ATOMIC);
+   if (!adapter->mac_table)
+   return -ENOMEM;
 
/* Set MAC specific capability flags and exceptions */
switch (hw->mac.type) {
-- 
1.9.1

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


Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

2015-12-29 Thread Rainer Weikusat
Jacob Siverskog  writes:
> This should fix a NULL pointer dereference I encountered (dump
> below). Since __skb_unlink is called while walking,
> skb_queue_walk_safe should be used.

The code in question is:

skb_queue_walk(queue, skb) {
*last = skb;
*peeked = skb->peeked;
if (flags & MSG_PEEK) {
if (_off >= skb->len && (skb->len || _off ||
 skb->peeked)) {
_off -= skb->len;
continue;
}

skb = skb_set_peeked(skb);
error = PTR_ERR(skb);
if (IS_ERR(skb)) {
spin_unlock_irqrestore(>lock,
   cpu_flags);
goto no_packet;
}

atomic_inc(>users);
}  else
__skb_unlink(skb, queue);

spin_unlock_irqrestore(>lock, cpu_flags);
*off = _off;
return skb;
}

__skb_unlink is only called prior to returning from the function.
Consequently, it won't affect the skb_queue_walk code.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv3 net-next 0/3] Ethtool support for phy stats

2015-12-29 Thread Andrew Lunn
This patchset add ethtool support for reading statistics from the PHY.
The Marvell and Micrel Phys are then extended to report receiver
packet errors and idle errors.

v2:
  Fix linking when phylib is not enabled.
v3:
  Inline helpers into ethtool.c, so fixing when phylib is a module.
  
Andrew Lunn (3):
  ethtool: Add phy statistics
  phy: marvell: Add ethtool statistics counters
  phy: micrel: Add ethtool statistics counters

 drivers/net/phy/marvell.c| 135 +++
 drivers/net/phy/micrel.c |  96 ++
 include/linux/phy.h  |   6 ++
 include/uapi/linux/ethtool.h |   3 +
 net/core/ethtool.c   |  81 +-
 5 files changed, 320 insertions(+), 1 deletion(-)

-- 
2.6.4

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


[PATCHv3 net-next 1/3] ethtool: Add phy statistics

2015-12-29 Thread Andrew Lunn
Ethernet PHYs can maintain statistics, for example errors while idle
and receive errors. Add an ethtool mechanism to retrieve these
statistics, using the same model as MAC statistics.

Signed-off-by: Andrew Lunn 
---
 include/linux/phy.h  |  6 
 include/uapi/linux/ethtool.h |  3 ++
 net/core/ethtool.c   | 81 +++-
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 05fde31b6dc6..a89cb0eef911 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -589,6 +589,12 @@ struct phy_driver {
int (*module_eeprom)(struct phy_device *dev,
 struct ethtool_eeprom *ee, u8 *data);
 
+   /* Get statistics from the phy using ethtool */
+   int (*get_sset_count)(struct phy_device *dev);
+   void (*get_strings)(struct phy_device *dev, u8 *data);
+   void (*get_stats)(struct phy_device *dev,
+ struct ethtool_stats *stats, u64 *data);
+
struct device_driver driver;
 };
 #define to_phy_driver(d) container_of(d, struct phy_driver, driver)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index cd1629170103..57fa39005e79 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -542,6 +542,7 @@ struct ethtool_pauseparam {
  * now deprecated
  * @ETH_SS_FEATURES: Device feature names
  * @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
+ * @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
  */
 enum ethtool_stringset {
ETH_SS_TEST = 0,
@@ -551,6 +552,7 @@ enum ethtool_stringset {
ETH_SS_FEATURES,
ETH_SS_RSS_HASH_FUNCS,
ETH_SS_TUNABLES,
+   ETH_SS_PHY_STATS,
 };
 
 /**
@@ -1225,6 +1227,7 @@ enum ethtool_sfeatures_retval_bits {
 #define ETHTOOL_SRSSH  0x0047 /* Set RX flow hash configuration */
 #define ETHTOOL_GTUNABLE   0x0048 /* Get tunable configuration */
 #define ETHTOOL_STUNABLE   0x0049 /* Set tunable configuration */
+#define ETHTOOL_GPHYSTATS  0x004a /* get PHY-specific statistics */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 09948a726347..42b3be6c55a2 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -191,6 +191,23 @@ static int ethtool_set_features(struct net_device *dev, 
void __user *useraddr)
return ret;
 }
 
+int phy_get_sset_count(struct phy_device *phydev)
+{
+   int ret;
+
+   if (phydev->drv->get_sset_count &&
+   phydev->drv->get_strings &&
+   phydev->drv->get_stats) {
+   mutex_lock(>lock);
+   ret = phydev->drv->get_sset_count(phydev);
+   mutex_unlock(>lock);
+
+   return ret;
+   }
+
+   return -EOPNOTSUPP;
+}
+
 static int __ethtool_get_sset_count(struct net_device *dev, int sset)
 {
const struct ethtool_ops *ops = dev->ethtool_ops;
@@ -204,6 +221,13 @@ static int __ethtool_get_sset_count(struct net_device 
*dev, int sset)
if (sset == ETH_SS_TUNABLES)
return ARRAY_SIZE(tunable_strings);
 
+   if (sset == ETH_SS_PHY_STATS) {
+   if (dev->phydev)
+   return phy_get_sset_count(dev->phydev);
+   else
+   return -EOPNOTSUPP;
+   }
+
if (ops->get_sset_count && ops->get_strings)
return ops->get_sset_count(dev, sset);
else
@@ -223,7 +247,17 @@ static void __ethtool_get_strings(struct net_device *dev,
   sizeof(rss_hash_func_strings));
else if (stringset == ETH_SS_TUNABLES)
memcpy(data, tunable_strings, sizeof(tunable_strings));
-   else
+   else if (stringset == ETH_SS_PHY_STATS) {
+   struct phy_device *phydev = dev->phydev;
+
+   if (phydev) {
+   mutex_lock(>lock);
+   phydev->drv->get_strings(phydev, data);
+   mutex_unlock(>lock);
+   } else {
+   return;
+   }
+   } else
/* ops->get_strings is valid because checked earlier */
ops->get_strings(dev, stringset, data);
 }
@@ -1401,6 +1435,47 @@ static int ethtool_get_stats(struct net_device *dev, 
void __user *useraddr)
return ret;
 }
 
+static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr)
+{
+   struct ethtool_stats stats;
+   struct phy_device *phydev = dev->phydev;
+   u64 *data;
+   int ret, n_stats;
+
+   if (!phydev)
+   return -EOPNOTSUPP;
+
+   n_stats = phy_get_sset_count(phydev);
+
+   if (n_stats < 0)
+   return n_stats;
+   WARN_ON(n_stats == 0);
+
+   if (copy_from_user(, useraddr, sizeof(stats)))
+   return -EFAULT;
+
+   

[PATCHv3 net-next 3/3] phy: micrel: Add ethtool statistics counters

2015-12-29 Thread Andrew Lunn
The PHY counters receiver errors and errors while idle.

Signed-off-by: Andrew Lunn 
---
 drivers/net/phy/micrel.c | 96 
 1 file changed, 96 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index e13ad6cdcc22..1a6048a8c29d 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -73,6 +73,17 @@
 
 #define PS_TO_REG  200
 
+struct kszphy_hw_stat {
+   const char *string;
+   u8 reg;
+   u8 bits;
+};
+
+static struct kszphy_hw_stat kszphy_hw_stats[] = {
+   { "phy_receive_errors", 21, 16},
+   { "phy_idle_errors", 10, 8 },
+};
+
 struct kszphy_type {
u32 led_mode_reg;
u16 interrupt_level_mask;
@@ -86,6 +97,7 @@ struct kszphy_priv {
int led_mode;
bool rmii_ref_clk_sel;
bool rmii_ref_clk_sel_val;
+   u64 stats[ARRAY_SIZE(kszphy_hw_stats)];
 };
 
 static const struct kszphy_type ksz8021_type = {
@@ -569,6 +581,51 @@ ksz9021_wr_mmd_phyreg(struct phy_device *phydev, int 
ptrad, int devnum,
 {
 }
 
+static int kszphy_get_sset_count(struct phy_device *phydev)
+{
+   return ARRAY_SIZE(kszphy_hw_stats);
+}
+
+static void kszphy_get_strings(struct phy_device *phydev, u8 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(kszphy_hw_stats); i++) {
+   memcpy(data + i * ETH_GSTRING_LEN,
+  kszphy_hw_stats[i].string, ETH_GSTRING_LEN);
+   }
+}
+
+#ifndef UINT64_MAX
+#define UINT64_MAX  (u64)(~((u64)0))
+#endif
+static u64 kszphy_get_stat(struct phy_device *phydev, int i)
+{
+   struct kszphy_hw_stat stat = kszphy_hw_stats[i];
+   struct kszphy_priv *priv = phydev->priv;
+   u64 val;
+
+   val = phy_read(phydev, stat.reg);
+   if (val < 0) {
+   val = UINT64_MAX;
+   } else {
+   val = val & ((1 << stat.bits) - 1);
+   priv->stats[i] += val;
+   val = priv->stats[i];
+   }
+
+   return val;
+}
+
+static void kszphy_get_stats(struct phy_device *phydev,
+struct ethtool_stats *stats, u64 *data)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(kszphy_hw_stats); i++)
+   data[i] = kszphy_get_stat(phydev, i);
+}
+
 static int kszphy_probe(struct phy_device *phydev)
 {
const struct kszphy_type *type = phydev->drv->driver_data;
@@ -642,6 +699,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -659,6 +719,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -676,6 +739,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -693,6 +759,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -710,6 +779,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,
.config_intr= kszphy_config_intr,
+   .get_sset_count = kszphy_get_sset_count,
+   .get_strings= kszphy_get_strings,
+   .get_stats  = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
.driver = { .owner = THIS_MODULE,},
@@ -727,6 +799,9 @@ static struct phy_driver ksphy_driver[] = {
.read_status= genphy_read_status,
.ack_interrupt  = kszphy_ack_interrupt,

[PATCH] mwifiex: correctly handling kzalloc

2015-12-29 Thread Insu Yun
Since kzalloc can be failed in memory pressure,
it needs to be handled as above kzalloc.

Signed-off-by: Insu Yun 
---
 drivers/net/wireless/mwifiex/sdio.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 78a8474..d114934 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -2053,8 +2053,14 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
*adapter)
/* Allocate skb pointer buffers */
card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.skb_arr)
+   return -ENOMEM;
+
card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.len_arr)
+   return -ENOMEM;
+
ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
 card->mp_tx_agg_buf_size,
 card->mp_rx_agg_buf_size);
-- 
1.9.1

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


[PATCH] qlcnic: correctly handle qlcnic_alloc_mbx_args

2015-12-29 Thread Insu Yun
Since qlcnic_alloc_mbx_args can be failed, 
return value should be checked.

Signed-off-by: Insu Yun 
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c 
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index a5f422f..daf0515 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -772,8 +772,10 @@ int qlcnic_82xx_config_intrpt(struct qlcnic_adapter 
*adapter, u8 op_type)
int i, err = 0;
 
for (i = 0; i < ahw->num_msix; i++) {
-   qlcnic_alloc_mbx_args(, adapter,
- QLCNIC_CMD_MQ_TX_CONFIG_INTR);
+   err = qlcnic_alloc_mbx_args(, adapter,
+   QLCNIC_CMD_MQ_TX_CONFIG_INTR);
+   if (err)
+   return err;
type = op_type ? QLCNIC_INTRPT_ADD : QLCNIC_INTRPT_DEL;
val = type | (ahw->intr_tbl[i].type << 4);
if (ahw->intr_tbl[i].type == QLCNIC_INTRPT_MSIX)
-- 
1.9.1

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


Re: [PATCH] qlcnic: correctly handle qlcnic_alloc_mbx_args

2015-12-29 Thread David Miller
From: Insu Yun 
Date: Tue, 29 Dec 2015 14:29:47 -0500

> Signed-off-by: Insu Yun 
> ---
>  drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c 
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
> index a5f422f..a9a2c33 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
> @@ -772,8 +772,10 @@ int qlcnic_82xx_config_intrpt(struct qlcnic_adapter 
> *adapter, u8 op_type)
>   int i, err = 0;
>  
>   for (i = 0; i < ahw->num_msix; i++) {
> - qlcnic_alloc_mbx_args(, adapter,
> + err = qlcnic_alloc_mbx_args(, adapter,
> QLCNIC_CMD_MQ_TX_CONFIG_INTR);

You must fix the indentation of the second line of the function call when
you made changes like this.  The first character on the second line of the
call must be exactly at the first column after the openning parenthesis of
the first line.

You must must the appropriate number of TAB and then SPACE characters
necessary to achieve this.

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


Re: [PATCH] mwifiex: correctly handling kzalloc

2015-12-29 Thread David Miller
From: Insu Yun 
Date: Tue, 29 Dec 2015 14:55:25 -0500

> Since kzalloc can be failed in memory pressure,
> it needs to be handled as above kzalloc.
> 
> Signed-off-by: Insu Yun 
> ---
>  drivers/net/wireless/mwifiex/sdio.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/wireless/mwifiex/sdio.c 
> b/drivers/net/wireless/mwifiex/sdio.c
> index 78a8474..d114934 100644
> --- a/drivers/net/wireless/mwifiex/sdio.c
> +++ b/drivers/net/wireless/mwifiex/sdio.c
> @@ -2053,8 +2053,14 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
> *adapter)
>   /* Allocate skb pointer buffers */
>   card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
>  card->mp_agg_pkt_limit, GFP_KERNEL);
> + if (!card->mpa_rx.skb_arr)
> + return -ENOMEM;
> +
>   card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
>  card->mp_agg_pkt_limit, GFP_KERNEL);
> + if (!card->mpa_rx.len_arr)
> + return -ENOMEM;
> +
>   ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
>card->mp_tx_agg_buf_size,
>card->mp_rx_agg_buf_size);

You can't just return, you have to release all of the resources
acquired above the point where the error happens.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] mwifiex: correctly handling kzalloc

2015-12-29 Thread Insu Yun
Signed-off-by: Insu Yun 
---
 drivers/net/wireless/mwifiex/sdio.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 78a8474..a8af72d 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -2053,8 +2053,19 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
*adapter)
/* Allocate skb pointer buffers */
card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.skb_arr) {
+   kfree(card->mp_regs);
+   return -ENOMEM;
+   }
+
card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.len_arr) {
+   kfree(card->mp_regs);
+   kfree(card->mpa_rx.skb_arr);
+   return -ENOMEM;
+   }
+
ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
 card->mp_tx_agg_buf_size,
 card->mp_rx_agg_buf_size);
-- 
1.9.1

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


[net-next v2 4/8] ixgbe: report correct media type for KR, KX and KX4 interfaces

2015-12-29 Thread Jeff Kirsher
From: Veola Nazareth 

Ethtool reports backplane type interfaces as 1000/1baseT link modes.
This has been corrected to report the media as KR, KX or KX4 based on the
backplane interface present.

Signed-off-by: Veola Nazareth 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 55 ++--
 1 file changed, 42 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index e10d197..2448eba 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -151,6 +151,34 @@ static const char ixgbe_gstrings_test[][ETH_GSTRING_LEN] = 
{
 };
 #define IXGBE_TEST_LEN sizeof(ixgbe_gstrings_test) / ETH_GSTRING_LEN
 
+/* currently supported speeds for 10G */
+#define ADVRTSD_MSK_10G (SUPPORTED_1baseT_Full | \
+SUPPORTED_1baseKX4_Full | \
+SUPPORTED_1baseKR_Full)
+
+#define ixgbe_isbackplane(type) ((type) == ixgbe_media_type_backplane)
+
+static u32 ixgbe_get_supported_10gtypes(struct ixgbe_hw *hw)
+{
+   if (!ixgbe_isbackplane(hw->phy.media_type))
+   return SUPPORTED_1baseT_Full;
+
+   switch (hw->device_id) {
+   case IXGBE_DEV_ID_82598:
+   case IXGBE_DEV_ID_82599_KX4:
+   case IXGBE_DEV_ID_82599_KX4_MEZZ:
+   case IXGBE_DEV_ID_X550EM_X_KX4:
+   return SUPPORTED_1baseKX4_Full;
+   case IXGBE_DEV_ID_82598_BX:
+   case IXGBE_DEV_ID_82599_KR:
+   case IXGBE_DEV_ID_X550EM_X_KR:
+   return SUPPORTED_1baseKR_Full;
+   default:
+   return SUPPORTED_1baseKX4_Full |
+  SUPPORTED_1baseKR_Full;
+   }
+}
+
 static int ixgbe_get_settings(struct net_device *netdev,
  struct ethtool_cmd *ecmd)
 {
@@ -165,29 +193,30 @@ static int ixgbe_get_settings(struct net_device *netdev,
 
/* set the supported link speeds */
if (supported_link & IXGBE_LINK_SPEED_10GB_FULL)
-   ecmd->supported |= SUPPORTED_1baseT_Full;
+   ecmd->supported |= ixgbe_get_supported_10gtypes(hw);
if (supported_link & IXGBE_LINK_SPEED_1GB_FULL)
ecmd->supported |= SUPPORTED_1000baseT_Full;
if (supported_link & IXGBE_LINK_SPEED_100_FULL)
-   ecmd->supported |= SUPPORTED_100baseT_Full;
+   ecmd->supported |= ixgbe_isbackplane(hw->phy.media_type) ?
+  SUPPORTED_1000baseKX_Full :
+  SUPPORTED_1000baseT_Full;
 
+   /* default advertised speed if phy.autoneg_advertised isn't set */
+   ecmd->advertising = ecmd->supported;
/* set the advertised speeds */
if (hw->phy.autoneg_advertised) {
+   ecmd->advertising = 0;
if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_100_FULL)
ecmd->advertising |= ADVERTISED_100baseT_Full;
if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_10GB_FULL)
-   ecmd->advertising |= ADVERTISED_1baseT_Full;
-   if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_1GB_FULL)
-   ecmd->advertising |= ADVERTISED_1000baseT_Full;
+   ecmd->advertising |= ecmd->supported & ADVRTSD_MSK_10G;
+   if (hw->phy.autoneg_advertised & IXGBE_LINK_SPEED_1GB_FULL) {
+   if (ecmd->supported & SUPPORTED_1000baseKX_Full)
+   ecmd->advertising |= ADVERTISED_1000baseKX_Full;
+   else
+   ecmd->advertising |= ADVERTISED_1000baseT_Full;
+   }
} else {
-   /* default modes in case phy.autoneg_advertised isn't set */
-   if (supported_link & IXGBE_LINK_SPEED_10GB_FULL)
-   ecmd->advertising |= ADVERTISED_1baseT_Full;
-   if (supported_link & IXGBE_LINK_SPEED_1GB_FULL)
-   ecmd->advertising |= ADVERTISED_1000baseT_Full;
-   if (supported_link & IXGBE_LINK_SPEED_100_FULL)
-   ecmd->advertising |= ADVERTISED_100baseT_Full;
-
if (hw->phy.multispeed_fiber && !autoneg) {
if (supported_link & IXGBE_LINK_SPEED_10GB_FULL)
ecmd->advertising = ADVERTISED_1baseT_Full;
-- 
2.5.0

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


[net-next v2 7/8] ixgbe: Correct X550EM_x revision check

2015-12-29 Thread Jeff Kirsher
From: Mark Rustad 

The X550EM_x revision check needs to check a value, not just a bit.
Use a mask and check the value. Also remove the redundant check
inside the ixgbe_enter_lplu_t_x550em, because it can only be called
when both the mac type and revision check pass.

Signed-off-by: Mark Rustad 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 06add27..5f53cc6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -3520,7 +3520,7 @@ struct ixgbe_info {
 
 #define IXGBE_FUSES0_GROUP(_i) (0x11158 + ((_i) * 4))
 #define IXGBE_FUSES0_300MHZBIT(5)
-#define IXGBE_FUSES0_REV1  BIT(6)
+#define IXGBE_FUSES0_REV_MASK  (3 << 6)
 
 #define IXGBE_KRM_PORT_CAR_GEN_CTRL(P) ((P) ? 0x8010 : 0x4010)
 #define IXGBE_KRM_LINK_CTRL_1(P)   ((P) ? 0x820C : 0x420C)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index f4ef0d1..87aca3f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -1857,10 +1857,6 @@ static s32 ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)
u32 save_autoneg;
bool link_up;
 
-   /* SW LPLU not required on later HW revisions. */
-   if (IXGBE_FUSES0_REV1 & IXGBE_READ_REG(hw, IXGBE_FUSES0_GROUP(0)))
-   return 0;
-
/* If blocked by MNG FW, then don't restart AN */
if (ixgbe_check_reset_blocked(hw))
return 0;
@@ -2000,8 +1996,9 @@ static s32 ixgbe_init_phy_ops_X550em(struct ixgbe_hw *hw)
  ixgbe_setup_internal_phy_t_x550em;
 
/* setup SW LPLU only for first revision */
-   if (!(IXGBE_FUSES0_REV1 & IXGBE_READ_REG(hw,
-   IXGBE_FUSES0_GROUP(0
+   if (hw->mac.type == ixgbe_mac_X550EM_x &&
+   !(IXGBE_READ_REG(hw, IXGBE_FUSES0_GROUP(0)) &
+ IXGBE_FUSES0_REV_MASK))
phy->ops.enter_lplu = ixgbe_enter_lplu_t_x550em;
 
phy->ops.handle_lasi = ixgbe_handle_lasi_ext_t_x550em;
-- 
2.5.0

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


[net-next v2 0/8][pull request] 10GbE Intel Wired LAN Driver Updates 2015-12-29

2015-12-29 Thread Jeff Kirsher
This series contains updates to ixgbe and ixgbevf.

William Dauchy provides a fix for ixgbevf that was implemented for ixgbe,
commit 5d6002b7b822c7 ("ixgbe: Fix handling of NAPI budget when multiple
queues are enabled per vector"). The issue was that the polling routine
would increase the budget for receive to at least 1 per queue if multiple
queues were present, which resulted in receive packets being processed
when the budget was 0.

Emil provides minor cleanups for ixgbevf, one being that we need to
check rx_itr_setting with == and not &, since it is not a mask.  Added
QSFP PHY support in ixgbe to allow for more accurate reporting of port
settings.  Fixed the max RSS limit for X550 which is 63, not 64.

Veola fixes ixgbe ethtool reporting of backplane type interfaces as
1000/1baseT link modes, instead, report the media as KR, KX or KX4
based on the backplane interface present.

Mark cleans up redundancy in the setting of hw_enc_features that makes
it appear that X550 has more encapsulation features than other devices.
Also do not set NETIF_F_SG any longer since that is set by the
register_netdev() call.  Also fixed the X550EM_x revision check, which
needs to check a value, not just a bit.

Alex Duyck fixes additional bugs in ixgbe_clear_vf_vlans(), one being
that the mask was using a divide instead of a modulus, which resulted
in the mask bit being incorrectly set to 0 or 1 based on the value of
the VF being tested.  Alex also found that he was not consistent in
using the "word" argument as an offset or as a register offset, so
made the code consistently use word as the offset in the array.

v2: dropped patch 8 of the original series, as it was undoing a part of
the fix Alex Duyck was doing in patch 9 of the original series.
Dropped based on feedback from Emil (the author).

The following are changes since commit da0bcb4e36411c1e9e327359c36507e2e04964a1:
  net: hns: use to_platform_device()
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE

Alexander Duyck (1):
  ixgbe: Fix bugs in ixgbe_clear_vf_vlans()

Emil Tantilov (3):
  ixgbevf: minor cleanups for ixgbevf_set_itr()
  ixgbe: add support for QSFP PHY types in ixgbe_get_settings()
  ixgbe: fix RSS limit for X550

Mark Rustad (2):
  ixgbe: Clean up redundancy in hw_enc_features
  ixgbe: Correct X550EM_x revision check

Veola Nazareth (1):
  ixgbe: report correct media type for KR, KX and KX4 interfaces

William Dauchy (1):
  ixgbevf: Fix handling of NAPI budget when multiple queues are enabled
per vector

 drivers/net/ethernet/intel/ixgbe/ixgbe.h  |  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c  | 59 ++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  7 +--
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c|  8 +--
 drivers/net/ethernet/intel/ixgbe/ixgbe_type.h |  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c |  9 ++--
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |  7 ++-
 7 files changed, 62 insertions(+), 32 deletions(-)

-- 
2.5.0

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


[net-next v2 3/8] ixgbe: add support for QSFP PHY types in ixgbe_get_settings()

2015-12-29 Thread Jeff Kirsher
From: Emil Tantilov 

Add missing QSFP PHY types to allow for more accurate reporting of
port settings.

Signed-off-by: Emil Tantilov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 1ed4c9a..e10d197 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -225,6 +225,10 @@ static int ixgbe_get_settings(struct net_device *netdev,
case ixgbe_phy_sfp_avago:
case ixgbe_phy_sfp_intel:
case ixgbe_phy_sfp_unknown:
+   case ixgbe_phy_qsfp_passive_unknown:
+   case ixgbe_phy_qsfp_active_unknown:
+   case ixgbe_phy_qsfp_intel:
+   case ixgbe_phy_qsfp_unknown:
/* SFP+ devices, further checking needed */
switch (adapter->hw.phy.sfp_type) {
case ixgbe_sfp_type_da_cu:
-- 
2.5.0

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


[net-next v2 5/8] ixgbe: Clean up redundancy in hw_enc_features

2015-12-29 Thread Jeff Kirsher
From: Mark Rustad 

Clean up minor redundancy in the setting of hw_enc_features that
makes it appears that X550 uniquely has more encapsulation features
than other devices. The driver only supports one more feature, so
make it look that way. No longer set NETIF_F_SG since that is set
by the register_netdev call. Thanks to Alex Duyck for noticing this
slight confusion.

Reported-by: Alexander Duyck 
Signed-off-by: Mark Rustad 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index c5c0fb4..ea9537d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9015,8 +9015,7 @@ skip_sriov:
netdev->vlan_features |= NETIF_F_IPV6_CSUM;
netdev->vlan_features |= NETIF_F_SG;
 
-   netdev->hw_enc_features |= NETIF_F_SG | NETIF_F_IP_CSUM |
-  NETIF_F_IPV6_CSUM;
+   netdev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
 
netdev->priv_flags |= IFF_UNICAST_FLT;
netdev->priv_flags |= IFF_SUPP_NOFCS;
@@ -9025,9 +9024,7 @@ skip_sriov:
switch (adapter->hw.mac.type) {
case ixgbe_mac_X550:
case ixgbe_mac_X550EM_x:
-   netdev->hw_enc_features |= NETIF_F_RXCSUM |
-  NETIF_F_IP_CSUM |
-  NETIF_F_IPV6_CSUM;
+   netdev->hw_enc_features |= NETIF_F_RXCSUM;
break;
default:
break;
-- 
2.5.0

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


[net-next v2 8/8] ixgbe: Fix bugs in ixgbe_clear_vf_vlans()

2015-12-29 Thread Jeff Kirsher
From: Alexander Duyck 

When I had rewritten the code for ixgbe_clear_vf_vlans() it looks like I
had transitioned back and forth between using word as an offset and using
word as a register offset.  As a result I honestly don't see how the code
was working before other than the fact that resetting the VLANs on the VF
like didn't do much to clear them.

Another issue found is that the mask was using a divide instead of a
modulus.  As a result the mask bit was incorrectly being set to either bit
0 or 1 based on the value of the VF being tested.  As a result the wrong
VFs were having their VLANs cleared if they were enabled.

I have updated the code so that word represents the offset in the array.
This way we can use the modulus and xor operations and they will make sense
instead of being performed on a 4 byte aligned value.

I replaced the statement "(word % 2) ^ 1" with "~word % 2" in order to
reduce the line length as the line exceeded 80 characters with the register
name inserted.  The two should be equivalent so the change should be safe.

Reported-by: Emil Tantilov 
Signed-off-by: Alexander Duyck 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index eeff3d0..8025a3f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -593,11 +593,11 @@ static void ixgbe_clear_vf_vlans(struct ixgbe_adapter 
*adapter, u32 vf)
 
/* post increment loop, covers VLVF_ENTRIES - 1 to 0 */
for (i = IXGBE_VLVF_ENTRIES; i--;) {
-   u32 word = IXGBE_VLVFB(i * 2 + vf / 32);
u32 bits[2], vlvfb, vid, vfta, vlvf;
-   u32 mask = 1 << (vf / 32);
+   u32 word = i * 2 + vf / 32;
+   u32 mask = 1 << (vf % 32);
 
-   vlvfb = IXGBE_READ_REG(hw, word);
+   vlvfb = IXGBE_READ_REG(hw, IXGBE_VLVFB(word));
 
/* if our bit isn't set we can skip it */
if (!(vlvfb & mask))
@@ -608,7 +608,7 @@ static void ixgbe_clear_vf_vlans(struct ixgbe_adapter 
*adapter, u32 vf)
 
/* create 64b mask to chedk to see if we should clear VLVF */
bits[word % 2] = vlvfb;
-   bits[(word % 2) ^ 1] = IXGBE_READ_REG(hw, word ^ 1);
+   bits[~word % 2] = IXGBE_READ_REG(hw, IXGBE_VLVFB(word ^ 1));
 
/* if promisc is enabled, PF will be present, leave VFTA */
if (adapter->flags2 & IXGBE_FLAG2_VLAN_PROMISC) {
-- 
2.5.0

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


[net-next v2 6/8] ixgbe: fix RSS limit for X550

2015-12-29 Thread Jeff Kirsher
From: Emil Tantilov 

X550 allows for up to 64 RSS queues, but the driver can have max
of 63 (-1 MSIX vector for link).

On systems with >= 64 CPUs the driver will set the redirection table
for all 64 queues which will result in packets being dropped.

Signed-off-by: Emil Tantilov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index f4c9a42..4b9156c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -317,7 +317,7 @@ enum ixgbe_ring_f_enum {
 };
 
 #define IXGBE_MAX_RSS_INDICES  16
-#define IXGBE_MAX_RSS_INDICES_X550 64
+#define IXGBE_MAX_RSS_INDICES_X550 63
 #define IXGBE_MAX_VMDQ_INDICES 64
 #define IXGBE_MAX_FDIR_INDICES 63  /* based on q_vector limit */
 #define IXGBE_MAX_FCOE_INDICES 8
-- 
2.5.0

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


[net-next v2 2/8] ixgbevf: minor cleanups for ixgbevf_set_itr()

2015-12-29 Thread Jeff Kirsher
From: Emil Tantilov 

adapter->rx_itr_setting is not a mask so check it with == instead of &
do not default to 12K interrupts in ixgbevf_set_itr()

There should be no functional effect from these changes.

Signed-off-by: Emil Tantilov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c 
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 478c0f1..3558f01 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1047,7 +1047,7 @@ static int ixgbevf_poll(struct napi_struct *napi, int 
budget)
return budget;
/* all work done, exit the polling mode */
napi_complete_done(napi, work_done);
-   if (adapter->rx_itr_setting & 1)
+   if (adapter->rx_itr_setting == 1)
ixgbevf_set_itr(q_vector);
if (!test_bit(__IXGBEVF_DOWN, >state) &&
!test_bit(__IXGBEVF_REMOVING, >state))
@@ -1250,9 +1250,10 @@ static void ixgbevf_set_itr(struct ixgbevf_q_vector 
*q_vector)
new_itr = IXGBE_20K_ITR;
break;
case bulk_latency:
-   default:
new_itr = IXGBE_12K_ITR;
break;
+   default:
+   break;
}
 
if (new_itr != q_vector->itr) {
-- 
2.5.0

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


[net-next v2 1/8] ixgbevf: Fix handling of NAPI budget when multiple queues are enabled per vector

2015-12-29 Thread Jeff Kirsher
From: William Dauchy 

This is the same patch as for ixgbe but applied differently according to
busy polling.  See commit 5d6002b7b822c74 ("ixgbe: Fix handling of NAPI
budget when multiple queues are enabled per vector")

Signed-off-by: William Dauchy 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c 
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index f098952..478c0f1 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1016,6 +1016,8 @@ static int ixgbevf_poll(struct napi_struct *napi, int 
budget)
ixgbevf_for_each_ring(ring, q_vector->tx)
clean_complete &= ixgbevf_clean_tx_irq(q_vector, ring);
 
+   if (budget <= 0)
+   return budget;
 #ifdef CONFIG_NET_RX_BUSY_POLL
if (!ixgbevf_qv_lock_napi(q_vector))
return budget;
-- 
2.5.0

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


Re: [PATCH net-next v2 00/10] be2net: patch set

2015-12-29 Thread Sathya Perla
On Wed, Dec 30, 2015 at 2:20 AM, David Miller  wrote:
>
> Please fix the problems reported by the kbuild test robot, they happened
> when I tried to build this too.

David, the test robot is complaining that all values of the enum are
not being handled by the switch statement.
There is a "return -EFAULT" after the switch statement that handles
all the other enum values. Anyway, I'm going to send a v3 adding a
default case to the switch to satisfy the compilerthanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 4.4-rc7 failure report

2015-12-29 Thread Doug Ledford
On 12/29/2015 10:43 PM, Alexei Starovoitov wrote:
> On Mon, Dec 28, 2015 at 08:26:44PM -0500, Doug Ledford wrote:
>> On 12/28/2015 05:20 PM, Daniel Borkmann wrote:
>>> On 12/28/2015 10:53 PM, Doug Ledford wrote:
 The 4.4-rc7 kernel is failing for me.  In my case, all of my vlan
 interfaces are failing to obtain a dhcp address using dhclient.  I've
 tried a hand built 4.4-rc7, and the Fedora rawhide 4.4-rc7 kernel, both
 failed.  I've tried NetworkManager and the old SysV network service,
 both fail.  I tried a working dhclient from rhel7 on the Fedora rawhide
 install and it failed too.  Running tcpdump on the interface shows the
 dhcp request going out, and a dhcp response coming back in.  Running
 strace on dhclient shows that it writes the dhcp request, but it never
 recvs a dhcp response.  If I manually bring the interface up with a
 static IP address then I'm able to run typical IP traffic across the
 link (aka, ping).  It would seem that when dhclient registers a packet
 filter on the socket, that filter is preventing it from ever getting the
 dhcp response.  The same dhclient works on any non-vlan interfaces in
 the system, so the filter must work for non-vlan interfaces.  Aside from
 the fact that the interface is a vlan, we also use a priority egress map
 on the interface, and we use PFC flow control.  Let me know if you need
 anymore to debug the issue, or email me off list and I can get you
 logins to my reproducer machines.
>>>
>>> When you say 4.4-rc7 kernel is failing for you, what latest kernel version
>>> was working, where the socket filter was properly receiving the response on
>>> your vlan iface?
>>
>> v4.3 final works.  I haven't bisected where in the 4.4 series it quits
>> working.  I can do that tomorrow.
> 
> I've tried to reproduce, but cannot seem to make dnsmasq work properly
> over vlan, so bisect would be great.
> 

Yeah, I've been working on it.  Issues with available machines that
reproduce combined with what hardware they have and whether or not that
hardware works at various steps in the bisection :-/

-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature


Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

2015-12-29 Thread kbuild test robot
Hi Gilad,

[auto build test WARNING on net/master]
[also build test WARNING on v4.4-rc7 next-20151223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Avidov/net-emac-emac-gigabit-ethernet-controller-driver/20151230-095104
config: ia64-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All warnings (new ones prefixed by >>):

   In file included from arch/ia64/include/asm/smp.h:20:0,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from include/linux/textsearch.h:8,
from include/linux/skbuff.h:30,
from include/linux/tcp.h:21,
from drivers/net/ethernet/qualcomm/emac/emac-mac.c:16:
   drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function 'emac_mac_up':
   arch/ia64/include/asm/io.h:394:30: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
#define writel(v,a) __writel((v), (a))
 ^
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c:1090:2: note: in expansion of 
>> macro 'writel'
 writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
 ^

vim +/writel +1090 drivers/net/ethernet/qualcomm/emac/emac-mac.c

  1074  }
  1075  }
  1076  
  1077  ret = request_irq(irq->irq, emac_isr, 0, EMAC_MAC_IRQ_RES, irq);
  1078  if (ret) {
  1079  netdev_err(adpt->netdev,
  1080 "error:%d on request_irq(%d:%s flags:0)\n", 
ret,
  1081 irq->irq, EMAC_MAC_IRQ_RES);
  1082  goto err_request_irq;
  1083  }
  1084  
  1085  emac_mac_rx_descs_refill(adpt, >rx_q);
  1086  
  1087  napi_enable(>rx_q.napi);
  1088  
  1089  /* enable mac irq */
> 1090  writel(~DIS_INT, adpt->base + EMAC_INT_STATUS);
  1091  writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
  1092  
  1093  netif_start_queue(netdev);
  1094  clear_bit(EMAC_STATUS_DOWN, >status);
  1095  
  1096  /* check link status */
  1097  set_bit(EMAC_STATUS_TASK_LSC_REQ, >status);
  1098  adpt->link_chk_timeout = jiffies + EMAC_TRY_LINK_TIMEOUT;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed

2015-12-29 Thread Tantilov, Emil S
>-Original Message-
>From: zhuyj [mailto:zyjzyj2...@gmail.com]
>Sent: Tuesday, December 29, 2015 6:49 PM
>To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>John; Williams, Mitch A; intel-wired-...@lists.osuosl.org;
>netdev@vger.kernel.org; e1000-de...@lists.sourceforge.net
>Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
>Vincent (Wind River)
>Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
>of link_up and speed
>
>On 12/30/2015 12:18 AM, Tantilov, Emil S wrote:
>>> -Original Message-
>>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org]
>On
>>> Behalf Of zyjzyj2...@gmail.com
>>> Sent: Monday, December 28, 2015 6:32 PM
>>> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
>>> Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John; Williams,
>Mitch
>>> A; intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; e1000-
>>> de...@lists.sourceforge.net
>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>Bourg,
>>> Vincent (Wind River)
>>> Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
>of
>>> link_up and speed
>>>
>>> From: Zhu Yanjun 
>>>
>>> When the X540 NIC acts as a slave of some virtual NICs, it is very
>>> important to synchronize link_up and link_speed, such as a bonding
>>> driver in 802.3ad mode. When X540 NIC acts as an independent interface,
>>> it is not necessary to synchronize link_up and link_speed. That is,
>>> the time span between link_up and link_speed is acceptable.
>> What exactly do you mean by "time span between link_up and link_speed"?
>
>In the previous mail, I show you some ethtool logs. In these logs, there
>is some
>time with NIC up while speed is unknown. I think this "some time" is
>time span between
>link_up and link_speed. Please see the previous mail for details.

Was this when reporting the link state from check_link() (reading the LINKS
register) or reporting the adapter->link_speed?

>> Where is it you think the de-synchronization occurs?
>
>When a NIC interface acts as a slave, a flag "IFF_SLAVE" is set in
>netdevice struct.
>Before we enter this function, we check IFF_SLAVE flag. If this flag is
>set, we continue to check
>link_speed. If not, this function is executed whether this link_speed is
>unknown or not.

I can already see this in your patch. I was asking about the reason why your 
change is needed.

>>
>>> Signed-off-by: Zhu Yanjun 
>>> ---
>>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |9 -
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> index ace21b9..1bb6056 100644
>>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> @@ -6436,8 +6436,15 @@ static void ixgbe_watchdog_link_is_up(struct
>>> ixgbe_adapter *adapter)
>>>  * time. To X540 NIC, there is a time span between link_up and
>>>  * link_speed. As such, only continue if link_up and link_speed are
>>>  * ready to X540 NIC.
>>> +* The time span between link_up and link_speed is very important
>>> +* when the X540 NIC acts as a slave in some virtual NICs, such as
>>> +* a bonding driver in 802.3ad mode. When X540 NIC acts as an
>>> +* independent interface, it is not necessary to synchronize link_up
>>> +* and link_speed.
>>> +* In the end, not continue if (X540 NIC && SLAVE && link_speed
>>> UNKNOWN)
>> This is a patch on top of your previous patch which I don't think was
>applied,
>> so this is not going to apply cleanly.
>>
>>>  */
>>> -   if (hw->mac.type == ixgbe_mac_X540)
>>> +   if ((hw->mac.type == ixgbe_mac_X540) &&
>>> +   (netdev->flags & IFF_SLAVE))
>>> if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
>>> return;
>> If you were to enter ixgbe_watchdog_link_is_up() with unknown speed, then
>I would
>> assume that you also have a dmesg that shows:
>> "NIC Link is Up unknown speed"
>>
>> by the interface you use in the bond?
>Sure. There is a dmesg log from the customer.
>"
>...
>2015-10-05T06:14:34.350 controller-0 kernel: info bonding: bond0: link
>status definitely up for interface eth0, 0 Mbps full duplex.

This message is from the bonding driver not from ixgbe.

In your patch you are adding a check for unknown link to 
ixgbe_watchdog_link_is_up()
if that condition was true then you should also see "unknown link" being 
reported by ixgbe.

Thanks,
Emil

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


Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed

2015-12-29 Thread zhuyj

On 12/30/2015 03:17 AM, Rustad, Mark D wrote:

Emil S  wrote:


  */
-   if (hw->mac.type == ixgbe_mac_X540)
+   if ((hw->mac.type == ixgbe_mac_X540) &&
+   (netdev->flags & IFF_SLAVE))
if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
return;

If you were to enter ixgbe_watchdog_link_is_up() with unknown speed, then I 
would
assume that you also have a dmesg that shows:
"NIC Link is Up unknown speed"

by the interface you use in the bond?

It seems odd to be checking the MAC type for this. Is this behavior perhaps 
more related to the copper phy? If so, then the check should be changed. Or 
would the check for unknown link speed be sufficient? It seems like an 
interface as a slave would not work with an unknown link speed, so it may as 
well wait in all cases, not just for X540.

--
Mark Rustad, Networking Division, Intel Corporation

Hi, Mark

Thanks for your suggestions.
The following is the feedback from the customer.
"
...
We observing this issue on x540T interfaces (8086:1528), but not on 
82599_SFP (8086:10FB).

...
"
To narrow this problem, I restrict mac.type to ixgbe_mac_X540. I agree 
with you. Maybe this problem is
related with the copper phy. But I only have X540 NIC to test. So it is 
difficult for me to confirm whether this

problem occurs on other mac type or not, such as X550.

I will consider your suggestions in the latest patch.

Thanks again.

Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH net-next v3 01/10] be2net: fix VF link state transition from disabled to auto

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

The VF link state setting transition from "disable" to "auto" does not work
due to a bug in SET_LOGICAL_LINK_CONFIG_V1 cmd in FW. This issue could not
be fixed in FW due to some backward compatibility issues it causes with
some released drivers. The issue has been fixed by introducing a new
version (v2) of the cmd from 10.6 FW onwards. In v2, to set the VF link
state to auto, both PLINK_ENABLE and PLINK_TRACK bits have to be set to 1.

The VF link state setting feature now works on Lancer chips too from
FW ver 10.6.315.0 onwards.

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be_cmds.c | 35 +
 drivers/net/ethernet/emulex/benet/be_cmds.h |  3 ++-
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 1795c93..8083eca 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -4260,16 +4260,13 @@ err:
return status;
 }
 
-int be_cmd_set_logical_link_config(struct be_adapter *adapter,
-  int link_state, u8 domain)
+int __be_cmd_set_logical_link_config(struct be_adapter *adapter,
+int link_state, int version, u8 domain)
 {
struct be_mcc_wrb *wrb;
struct be_cmd_req_set_ll_link *req;
int status;
 
-   if (BEx_chip(adapter) || lancer_chip(adapter))
-   return -EOPNOTSUPP;
-
spin_lock_bh(>mcc_lock);
 
wrb = wrb_from_mccq(adapter);
@@ -4284,14 +4281,15 @@ int be_cmd_set_logical_link_config(struct be_adapter 
*adapter,
   OPCODE_COMMON_SET_LOGICAL_LINK_CONFIG,
   sizeof(*req), wrb, NULL);
 
-   req->hdr.version = 1;
+   req->hdr.version = version;
req->hdr.domain = domain;
 
-   if (link_state == IFLA_VF_LINK_STATE_ENABLE)
-   req->link_config |= 1;
+   if (link_state == IFLA_VF_LINK_STATE_ENABLE ||
+   link_state == IFLA_VF_LINK_STATE_AUTO)
+   req->link_config |= PLINK_ENABLE;
 
if (link_state == IFLA_VF_LINK_STATE_AUTO)
-   req->link_config |= 1 << PLINK_TRACK_SHIFT;
+   req->link_config |= PLINK_TRACK;
 
status = be_mcc_notify_wait(adapter);
 err:
@@ -4299,6 +4297,25 @@ err:
return status;
 }
 
+int be_cmd_set_logical_link_config(struct be_adapter *adapter,
+  int link_state, u8 domain)
+{
+   int status;
+
+   if (BEx_chip(adapter))
+   return -EOPNOTSUPP;
+
+   status = __be_cmd_set_logical_link_config(adapter, link_state,
+ 2, domain);
+
+   /* Version 2 of the command will not be recognized by older FW.
+* On such a failure issue version 1 of the command.
+*/
+   if (base_status(status) == MCC_STATUS_ILLEGAL_REQUEST)
+   status = __be_cmd_set_logical_link_config(adapter, link_state,
+ 1, domain);
+   return status;
+}
 int be_roce_mcc_cmd(void *netdev_handle, void *wrb_payload,
int wrb_payload_size, u16 *cmd_status, u16 *ext_status)
 {
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h 
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 91155ea..9690c3a 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -2246,7 +2246,8 @@ struct be_cmd_resp_get_iface_list {
 };
 
 /*** Set logical link /
-#define PLINK_TRACK_SHIFT  8
+#define PLINK_ENABLEBIT(0)
+#define PLINK_TRACK BIT(8)
 struct be_cmd_req_set_ll_link {
struct be_cmd_req_hdr hdr;
u32 link_config; /* Bit 0: UP_DOWN, Bit 9: PLINK */
-- 
2.4.1

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


[PATCH net-next v3 04/10] be2net: move FW flash cmd code to be_cmds.c

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

All code relating to FW cmds is in be_cmds.[ch] excepting FW flash cmd
related code. This patch moves these routines from be_main.c to be_cmds.c

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be_cmds.c | 583 +++-
 drivers/net/ethernet/emulex/benet/be_cmds.h |  15 +-
 drivers/net/ethernet/emulex/benet/be_main.c | 564 ---
 3 files changed, 578 insertions(+), 584 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 8083eca..da3b398 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2291,10 +2291,11 @@ err:
return status;
 }
 
-int lancer_cmd_write_object(struct be_adapter *adapter, struct be_dma_mem *cmd,
-   u32 data_size, u32 data_offset,
-   const char *obj_name, u32 *data_written,
-   u8 *change_status, u8 *addn_status)
+static int lancer_cmd_write_object(struct be_adapter *adapter,
+  struct be_dma_mem *cmd, u32 data_size,
+  u32 data_offset, const char *obj_name,
+  u32 *data_written, u8 *change_status,
+  u8 *addn_status)
 {
struct be_mcc_wrb *wrb;
struct lancer_cmd_req_write_object *req;
@@ -2410,7 +2411,8 @@ int be_cmd_query_sfp_info(struct be_adapter *adapter)
return status;
 }
 
-int lancer_cmd_delete_object(struct be_adapter *adapter, const char *obj_name)
+static int lancer_cmd_delete_object(struct be_adapter *adapter,
+   const char *obj_name)
 {
struct lancer_cmd_req_delete_object *req;
struct be_mcc_wrb *wrb;
@@ -2485,9 +2487,9 @@ err_unlock:
return status;
 }
 
-int be_cmd_write_flashrom(struct be_adapter *adapter, struct be_dma_mem *cmd,
- u32 flash_type, u32 flash_opcode, u32 img_offset,
- u32 buf_size)
+static int be_cmd_write_flashrom(struct be_adapter *adapter,
+struct be_dma_mem *cmd, u32 flash_type,
+u32 flash_opcode, u32 img_offset, u32 buf_size)
 {
struct be_mcc_wrb *wrb;
struct be_cmd_write_flashrom *req;
@@ -2533,8 +2535,8 @@ err_unlock:
return status;
 }
 
-int be_cmd_get_flash_crc(struct be_adapter *adapter, u8 *flashed_crc,
-u16 img_optype, u32 img_offset, u32 crc_offset)
+static int be_cmd_get_flash_crc(struct be_adapter *adapter, u8 *flashed_crc,
+   u16 img_optype, u32 img_offset, u32 crc_offset)
 {
struct be_cmd_read_flash_crc *req;
struct be_mcc_wrb *wrb;
@@ -2571,6 +2573,567 @@ err:
return status;
 }
 
+static char flash_cookie[2][16] = {"*** SE FLAS", "H DIRECTORY *** "};
+
+static bool phy_flashing_required(struct be_adapter *adapter)
+{
+   return (adapter->phy.phy_type == PHY_TYPE_TN_8022 &&
+   adapter->phy.interface_type == PHY_TYPE_BASET_10GB);
+}
+
+static bool is_comp_in_ufi(struct be_adapter *adapter,
+  struct flash_section_info *fsec, int type)
+{
+   int i = 0, img_type = 0;
+   struct flash_section_info_g2 *fsec_g2 = NULL;
+
+   if (BE2_chip(adapter))
+   fsec_g2 = (struct flash_section_info_g2 *)fsec;
+
+   for (i = 0; i < MAX_FLASH_COMP; i++) {
+   if (fsec_g2)
+   img_type = le32_to_cpu(fsec_g2->fsec_entry[i].type);
+   else
+   img_type = le32_to_cpu(fsec->fsec_entry[i].type);
+
+   if (img_type == type)
+   return true;
+   }
+   return false;
+}
+
+static struct flash_section_info *get_fsec_info(struct be_adapter *adapter,
+   int header_size,
+   const struct firmware *fw)
+{
+   struct flash_section_info *fsec = NULL;
+   const u8 *p = fw->data;
+
+   p += header_size;
+   while (p < (fw->data + fw->size)) {
+   fsec = (struct flash_section_info *)p;
+   if (!memcmp(flash_cookie, fsec->cookie, sizeof(flash_cookie)))
+   return fsec;
+   p += 32;
+   }
+   return NULL;
+}
+
+static int be_check_flash_crc(struct be_adapter *adapter, const u8 *p,
+ u32 img_offset, u32 img_size, int hdr_size,
+ u16 img_optype, bool *crc_match)
+{
+   u32 crc_offset;
+   int status;
+   u8 crc[4];
+
+   status = be_cmd_get_flash_crc(adapter, crc, img_optype, img_offset,
+ img_size - 4);
+   if (status)
+   

[PATCH net-next v3 00/10] be2net: patch set

2015-12-29 Thread Sathya Perla
Hi David,
The following patch set contains some feature additions, code re-organization
and cleanup and a few non-critical fixes. Pls consider applying this to
the net-next tree. Thanks.

v3 changes: add a default case to the switch statement in patch 5 to
satisfy the compiler (-Wswitch).
v2 changes: replaced an if/else block that checks for error values with a
switch/case statement in patch 5.

Patch 1 fixes VF link state transition from disabled to auto that did
not work due to an issue in the FW. This issue could not be fixed in FW due
to some backward compatibility issues it causes with released drivers.
The issue has been fixed by introducing a new version (v2) of the cmd
from 10.6 FW onwards. This patch adds support for v2 version of this cmd.

Patch 2 reports a EOPNOTSUPP status to ethtool when the user tries to
configure BE3/SRIOV in VEPA mode as it is not supported by the chip.

Patch 3 cleansup FW flash image related constant definitions. Many of these
definitions (such as section offset values) were defined in decimal format
rather than hexa-decimal. This makes this part of the code un-readable.
Also some defines related to BE2 are labeld "g2" and defines related to BE3
are labeled "g3".  This patch cleans up all of this to make this code more
readable.

Patch 4 moves the FW cmd code to be_cmds.c. All code relating to FW cmds
has been in be_cmds.[ch], excepting FW flash cmd related code.
This patch moves these routines from be_main.c to be_cmds.c.

Patch 5 adds a log message to report digital signature errors while
flashing a FW image. From FW version 11.0 onwards, the FW supports a new
"secure mode" feature (based on a jumper setting on the adapter.) In this
mode, the FW image when flashed is authenticated with a digital signature.

Patch 6 removes a line of code that has no effect.

Patch 7 removes some unused variables.

Patch 8 fixes port resource descriptor query via the GET_PROFILE FW cmd.
An earlier commit passed a specific pf_num while issuing this cmd as FW
returns descriptors for all functions when pf_num is zero. But, when pf_num
is set to a non-zero value, FW does not return the port resource descriptor.
This patch fixes this by setting pf_num to 0 while issuing the query cmd
and adds code to pick the correct NIC resource descriptor from the list of
descriptors returned by FW.

Patch 9 adds support for ethtool get-dump feature. In the past when this
option was not yet available, this feature was supported via the
--register-dump option as a workaround.  This patch removes support for
FW-dump via --register-dump option as it is now available via --get-dump
option. Even though the "ethtool --register-dump" cmd which used to work
earlier, will now fail with ENOTSUPP error, we feel it is not an issue as
this is used only for diagnostics purpose.

Patch 10 bumps up the driver version.

Sathya Perla (1):
  be2net: remove a line of code that has no effect

Suresh Reddy (7):
  be2net: fix VF link state transition from disabled to auto
  be2net: avoid configuring VEPA mode on BE3
  be2net: cleanup FW flash image related macro defines
  be2net: move FW flash cmd code to be_cmds.c
  be2net: log digital signature errors while flashing FW image
  be2net: fix port-res desc query of GET_PROFILE_CONFIG FW cmd
  be2net: bump up the driver version to 11.0.0.0

Venkat Duvvuru (2):
  be2net: remove unused error variables
  be2net: support ethtool get-dump option

 drivers/net/ethernet/emulex/benet/be.h |  13 +-
 drivers/net/ethernet/emulex/benet/be_cmds.c| 756 ++---
 drivers/net/ethernet/emulex/benet/be_cmds.h| 178 +++---
 drivers/net/ethernet/emulex/benet/be_ethtool.c |  82 ++-
 drivers/net/ethernet/emulex/benet/be_main.c| 588 +--
 5 files changed, 841 insertions(+), 776 deletions(-)

-- 
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH net-next v3 07/10] be2net: remove unused error variables

2015-12-29 Thread Sathya Perla
From: Venkat Duvvuru 

eeh_error, fw_timeout, hw_error variables in the be_adapter structure are
not used anymore. An earlier patch that introduced adapter->err_flags to
store this information missed removing these variables.

Signed-off-by: Venkat Duvvuru 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be.h 
b/drivers/net/ethernet/emulex/benet/be.h
index 93e5eab..0af32f1 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -547,10 +547,6 @@ struct be_adapter {
 
u32 beacon_state;   /* for set_phys_id */
 
-   bool eeh_error;
-   bool fw_timeout;
-   bool hw_error;
-
u32 port_num;
char port_name;
u8 mc_type;
-- 
2.4.1

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


[PATCH net-next v3 03/10] be2net: cleanup FW flash image related macro defines

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

Many constant definitions relating to the FW-image layout
(such as section offset values) were defined in decimal format rather than
hexa-decimal. This makes this part of the code un-readable. Also some
defines related to BE2 are labeld "g2" and defines related to BE3 are
labeled "g3".  This patch cleans up all of this to make this code more
readable.

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be_cmds.h | 141 
 drivers/net/ethernet/emulex/benet/be_main.c |  78 +++
 2 files changed, 118 insertions(+), 101 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h 
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 9690c3a..8c6b606 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -1207,68 +1207,85 @@ struct be_cmd_resp_get_beacon_state {
 /* Flashrom related descriptors */
 #define MAX_FLASH_COMP 32
 
-#define OPTYPE_ISCSI_ACTIVE0
-#define OPTYPE_REDBOOT 1
-#define OPTYPE_BIOS2
-#define OPTYPE_PXE_BIOS3
-#define OPTYPE_OFFSET_SPECIFIED7
-#define OPTYPE_FCOE_BIOS   8
-#define OPTYPE_ISCSI_BACKUP9
-#define OPTYPE_FCOE_FW_ACTIVE  10
-#define OPTYPE_FCOE_FW_BACKUP  11
-#define OPTYPE_NCSI_FW 13
-#define OPTYPE_REDBOOT_DIR 18
-#define OPTYPE_REDBOOT_CONFIG  19
-#define OPTYPE_SH_PHY_FW   21
-#define OPTYPE_FLASHISM_JUMPVECTOR 22
-#define OPTYPE_UFI_DIR 23
-#define OPTYPE_PHY_FW  99
-
-#define FLASH_BIOS_IMAGE_MAX_SIZE_g2   262144  /* Max OPTION ROM image sz */
-#define FLASH_REDBOOT_IMAGE_MAX_SIZE_g2262144  /* Max Redboot image sz 
   */
-#define FLASH_IMAGE_MAX_SIZE_g21310720 /* Max firmware image 
size */
-
-#define FLASH_NCSI_IMAGE_MAX_SIZE_g3   262144
-#define FLASH_PHY_FW_IMAGE_MAX_SIZE_g3 262144
-#define FLASH_BIOS_IMAGE_MAX_SIZE_g3   524288  /* Max OPTION ROM image sz */
-#define FLASH_REDBOOT_IMAGE_MAX_SIZE_g31048576 /* Max Redboot image sz 
   */
-#define FLASH_IMAGE_MAX_SIZE_g32097152 /* Max firmware image 
size */
-
-/* Offsets for components on Flash. */
-#define FLASH_REDBOOT_START_g2 0
-#define FLASH_FCoE_BIOS_START_g2   524288
-#define FLASH_iSCSI_PRIMARY_IMAGE_START_g2 1048576
-#define FLASH_iSCSI_BACKUP_IMAGE_START_g2  2359296
-#define FLASH_FCoE_PRIMARY_IMAGE_START_g2  3670016
-#define FLASH_FCoE_BACKUP_IMAGE_START_g2   4980736
-#define FLASH_iSCSI_BIOS_START_g2  7340032
-#define FLASH_PXE_BIOS_START_g27864320
-
-#define FLASH_REDBOOT_START_g3 262144
-#define FLASH_PHY_FW_START_g3  1310720
-#define FLASH_iSCSI_PRIMARY_IMAGE_START_g3 2097152
-#define FLASH_iSCSI_BACKUP_IMAGE_START_g3  4194304
-#define FLASH_FCoE_PRIMARY_IMAGE_START_g3  6291456
-#define FLASH_FCoE_BACKUP_IMAGE_START_g3   8388608
-#define FLASH_iSCSI_BIOS_START_g3  12582912
-#define FLASH_PXE_BIOS_START_g313107200
-#define FLASH_FCoE_BIOS_START_g3   13631488
-#define FLASH_NCSI_START_g315990784
-
-#define IMAGE_NCSI 16
-#define IMAGE_OPTION_ROM_PXE   32
-#define IMAGE_OPTION_ROM_FCoE  33
-#define IMAGE_OPTION_ROM_ISCSI 34
-#define IMAGE_FLASHISM_JUMPVECTOR  48
-#define IMAGE_FIRMWARE_iSCSI   160
-#define IMAGE_FIRMWARE_FCoE162
-#define IMAGE_FIRMWARE_BACKUP_iSCSI176
-#define IMAGE_FIRMWARE_BACKUP_FCoE 178
-#define IMAGE_FIRMWARE_PHY 192
-#define IMAGE_REDBOOT_DIR  208
-#define IMAGE_REDBOOT_CONFIG   209
-#define IMAGE_UFI_DIR  210
-#define IMAGE_BOOT_CODE224
+/* Optypes of each component in the UFI */
+enum {
+   OPTYPE_ISCSI_ACTIVE = 0,
+   OPTYPE_REDBOOT = 1,
+   OPTYPE_BIOS = 2,
+   OPTYPE_PXE_BIOS = 3,
+   OPTYPE_OFFSET_SPECIFIED = 7,
+   OPTYPE_FCOE_BIOS = 8,
+   OPTYPE_ISCSI_BACKUP = 9,
+   OPTYPE_FCOE_FW_ACTIVE = 10,
+   OPTYPE_FCOE_FW_BACKUP = 11,
+   OPTYPE_NCSI_FW = 13,
+   OPTYPE_REDBOOT_DIR = 18,
+   OPTYPE_REDBOOT_CONFIG = 19,
+   OPTYPE_SH_PHY_FW = 21,
+   OPTYPE_FLASHISM_JUMPVECTOR = 22,
+   OPTYPE_UFI_DIR = 23,
+   OPTYPE_PHY_FW = 99
+};
+
+/* Maximum sizes of components in BE2 FW UFI */
+enum {
+   BE2_BIOS_COMP_MAX_SIZE = 0x4,
+   BE2_REDBOOT_COMP_MAX_SIZE = 0x4,
+   BE2_COMP_MAX_SIZE = 0x14
+};
+
+/* Maximum sizes of components in BE3 FW UFI */
+enum {
+   BE3_NCSI_COMP_MAX_SIZE = 0x4,
+   BE3_PHY_FW_COMP_MAX_SIZE = 0x4,
+   

[PATCH net-next v3 09/10] be2net: support ethtool get-dump option

2015-12-29 Thread Sathya Perla
From: Venkat Duvvuru 

This patch adds support for ethtool's --get-dump option in be2net,
to retrieve FW dump. In the past when this option was not yet available,
this feature was supported via the --register-dump option as a workaround.
This patch removes support for FW-dump via --register-dump option as it is
now available via --get-dump option. Even though the
"ethtool --register-dump" cmd which used to work earlier, will now fail
with ENOTSUPP error, we feel it is not an issue as this is used only
for diagnostics purpose.

Signed-off-by: Venkat Duvvuru 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be.h |  1 +
 drivers/net/ethernet/emulex/benet/be_cmds.c| 38 
 drivers/net/ethernet/emulex/benet/be_cmds.h|  4 +-
 drivers/net/ethernet/emulex/benet/be_ethtool.c | 82 --
 drivers/net/ethernet/emulex/benet/be_main.c|  3 +
 5 files changed, 71 insertions(+), 57 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be.h 
b/drivers/net/ethernet/emulex/benet/be.h
index 66988f4..8b8212f 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -592,6 +592,7 @@ struct be_adapter {
struct rss_info rss_info;
/* Filters for packets that need to be sent to BMC */
u32 bmc_filt_mask;
+   u32 fat_dump_len;
u16 serial_num[CNTL_SERIAL_NUM_WORDS];
 };
 
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index b92ee06..b63d8ad 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1712,49 +1712,40 @@ err:
 }
 
 /* Uses synchronous mcc */
-int be_cmd_get_reg_len(struct be_adapter *adapter, u32 *log_size)
+int be_cmd_get_fat_dump_len(struct be_adapter *adapter, u32 *dump_size)
 {
-   struct be_mcc_wrb *wrb;
+   struct be_mcc_wrb wrb = {0};
struct be_cmd_req_get_fat *req;
int status;
 
-   spin_lock_bh(>mcc_lock);
-
-   wrb = wrb_from_mccq(adapter);
-   if (!wrb) {
-   status = -EBUSY;
-   goto err;
-   }
-   req = embedded_payload(wrb);
+   req = embedded_payload();
 
be_wrb_cmd_hdr_prepare(>hdr, CMD_SUBSYSTEM_COMMON,
-  OPCODE_COMMON_MANAGE_FAT, sizeof(*req), wrb,
-  NULL);
+  OPCODE_COMMON_MANAGE_FAT, sizeof(*req),
+  , NULL);
req->fat_operation = cpu_to_le32(QUERY_FAT);
-   status = be_mcc_notify_wait(adapter);
+   status = be_cmd_notify_wait(adapter, );
if (!status) {
-   struct be_cmd_resp_get_fat *resp = embedded_payload(wrb);
+   struct be_cmd_resp_get_fat *resp = embedded_payload();
 
-   if (log_size && resp->log_size)
-   *log_size = le32_to_cpu(resp->log_size) -
+   if (dump_size && resp->log_size)
+   *dump_size = le32_to_cpu(resp->log_size) -
sizeof(u32);
}
-err:
-   spin_unlock_bh(>mcc_lock);
return status;
 }
 
-int be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
+int be_cmd_get_fat_dump(struct be_adapter *adapter, u32 buf_len, void *buf)
 {
struct be_dma_mem get_fat_cmd;
struct be_mcc_wrb *wrb;
struct be_cmd_req_get_fat *req;
u32 offset = 0, total_size, buf_size,
log_offset = sizeof(u32), payload_len;
-   int status = 0;
+   int status;
 
if (buf_len == 0)
-   return -EIO;
+   return 0;
 
total_size = buf_len;
 
@@ -1762,11 +1753,8 @@ int be_cmd_get_regs(struct be_adapter *adapter, u32 
buf_len, void *buf)
get_fat_cmd.va = dma_zalloc_coherent(>pdev->dev,
 get_fat_cmd.size,
 _fat_cmd.dma, GFP_ATOMIC);
-   if (!get_fat_cmd.va) {
-   dev_err(>pdev->dev,
-   "Memory allocation failure while reading FAT data\n");
+   if (!get_fat_cmd.va)
return -ENOMEM;
-   }
 
spin_lock_bh(>mcc_lock);
 
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h 
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 5098170..241819b 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -2365,9 +2365,9 @@ int be_cmd_config_qos(struct be_adapter *adapter, u32 
max_rate,
 void be_detect_error(struct be_adapter *adapter);
 int be_cmd_get_die_temperature(struct be_adapter *adapter);
 int be_cmd_get_cntl_attributes(struct be_adapter *adapter);
+int be_cmd_get_fat_dump_len(struct be_adapter *adapter, u32 *dump_size);
+int be_cmd_get_fat_dump(struct be_adapter *adapter, u32 

[PATCH net-next v3 10/10] be2net: bump up the driver version to 11.0.0.0

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/emulex/benet/be.h 
b/drivers/net/ethernet/emulex/benet/be.h
index 8b8212f..22bf7af 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -37,7 +37,7 @@
 #include "be_hw.h"
 #include "be_roce.h"
 
-#define DRV_VER"10.6.0.3"
+#define DRV_VER"11.0.0.0"
 #define DRV_NAME   "be2net"
 #define BE_NAME"Emulex BladeEngine2"
 #define BE3_NAME   "Emulex BladeEngine3"
-- 
2.4.1

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


[PATCH net-next v3 08/10] be2net: fix port-res desc query of GET_PROFILE_CONFIG FW cmd

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

Commit 72ef3a88fa8e ("be2net: set pci_func_num while issuing
GET_PROFILE_CONFIG cmd") passed a specific pf_num while issuing a
GET_PROFILE_CONFIG cmd as FW returns descriptors for all functions when
pf_num is zero. But, when pf_num is set to a non-zero value, FW does not
return the Port resource descriptor.
This patch fixes this by setting pf_num to 0 while issuing the query cmd
and adds code to pick the correct NIC resource descriptor from the list of
descriptors returned by FW.

Fixes: 72ef3a88fa8e ("be2net: set pci_func_num while issuing
 GET_PROFILE_CONFIG cmd")
Signed-off-by: Suresh Reddy 

Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be.h  |  4 +-
 drivers/net/ethernet/emulex/benet/be_cmds.c | 85 -
 drivers/net/ethernet/emulex/benet/be_cmds.h | 11 +---
 drivers/net/ethernet/emulex/benet/be_main.c | 16 --
 4 files changed, 63 insertions(+), 53 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be.h 
b/drivers/net/ethernet/emulex/benet/be.h
index 0af32f1..66988f4 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -570,6 +570,8 @@ struct be_adapter {
struct be_resources pool_res;   /* resources available for the port */
struct be_resources res;/* resources available for the func */
u16 num_vfs;/* Number of VFs provisioned by PF */
+   u8 pf_num;  /* Numbering used by FW, starts at 0 */
+   u8 vf_num;  /* Numbering used by FW, starts at 1 */
u8 virtfn;
struct be_vf_cfg *vf_cfg;
bool be3_native;
@@ -587,8 +589,6 @@ struct be_adapter {
u32 msg_enable;
int be_get_temp_freq;
struct be_hwmon hwmon_info;
-   u8 pf_number;
-   u8 pci_func_num;
struct rss_info rss_info;
/* Filters for packets that need to be sent to BMC */
u32 bmc_filt_mask;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 7c0e7ff..b92ee06 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -3466,7 +3466,6 @@ int be_cmd_get_cntl_attributes(struct be_adapter *adapter)
if (!status) {
attribs = attribs_cmd.va + sizeof(struct be_cmd_resp_hdr);
adapter->hba_port_num = attribs->hba_attribs.phy_port;
-   adapter->pci_func_num = attribs->pci_func_num;
serial_num = attribs->hba_attribs.controller_serial_number;
for (i = 0; i < CNTL_SERIAL_NUM_WORDS; i++)
adapter->serial_num[i] = le32_to_cpu(serial_num[i]) &
@@ -4149,14 +4148,16 @@ int be_cmd_query_port_name(struct be_adapter *adapter)
return status;
 }
 
-/* Descriptor type */
-enum {
-   FUNC_DESC = 1,
-   VFT_DESC = 2
-};
-
+/* When more than 1 NIC descriptor is present in the descriptor list,
+ * the caller must specify the pf_num to obtain the NIC descriptor
+ * corresponding to its pci function.
+ * get_vft must be true when the caller wants the VF-template desc of the
+ * PF-pool.
+ * The pf_num should be set to PF_NUM_IGNORE when the caller knows
+ * that only it's NIC descriptor is present in the descriptor list.
+ */
 static struct be_nic_res_desc *be_get_nic_desc(u8 *buf, u32 desc_count,
-  int desc_type)
+  bool get_vft, u8 pf_num)
 {
struct be_res_desc_hdr *hdr = (struct be_res_desc_hdr *)buf;
struct be_nic_res_desc *nic;
@@ -4166,40 +4167,42 @@ static struct be_nic_res_desc *be_get_nic_desc(u8 *buf, 
u32 desc_count,
if (hdr->desc_type == NIC_RESOURCE_DESC_TYPE_V0 ||
hdr->desc_type == NIC_RESOURCE_DESC_TYPE_V1) {
nic = (struct be_nic_res_desc *)hdr;
-   if (desc_type == FUNC_DESC ||
-   (desc_type == VFT_DESC &&
-nic->flags & (1 << VFT_SHIFT)))
+
+   if ((pf_num == PF_NUM_IGNORE ||
+nic->pf_num == pf_num) &&
+   (!get_vft || nic->flags & BIT(VFT_SHIFT)))
return nic;
}
-
hdr->desc_len = hdr->desc_len ? : RESOURCE_DESC_SIZE_V0;
hdr = (void *)hdr + hdr->desc_len;
}
return NULL;
 }
 
-static struct be_nic_res_desc *be_get_vft_desc(u8 *buf, u32 desc_count)
+static struct be_nic_res_desc *be_get_vft_desc(u8 *buf, u32 desc_count,
+  u8 pf_num)
 {
-   return be_get_nic_desc(buf, desc_count, VFT_DESC);
+   return be_get_nic_desc(buf, desc_count, true, pf_num);
 }
 
-static struct be_nic_res_desc 

[PATCH net-next v3 05/10] be2net: log digital signature errors while flashing FW image

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

>From FW version 11.0 onwards, the FW supports a new "secure mode" feature
(based on a jumper setting on the adapter.) In this mode, the FW image when
flashed is authenticated with a digital signature. This patch logs
appropriate error messages and return a status to ethtool when errors
relating to FW image authentication occur.

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be_cmds.c | 14 +-
 drivers/net/ethernet/emulex/benet/be_cmds.h |  4 +++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index da3b398..451f9ea 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2959,7 +2959,19 @@ flash:
} else if (status) {
dev_err(dev, "Flashing section type 0x%x failed\n",
img_type);
-   return -EFAULT;
+
+   switch (addl_status(status)) {
+   case MCC_ADDL_STATUS_MISSING_SIGNATURE:
+   dev_err(dev,
+   "Digital signature missing in FW\n");
+   return -EINVAL;
+   case MCC_ADDL_STATUS_INVALID_SIGNATURE:
+   dev_err(dev,
+   "Invalid digital signature in FW\n");
+   return -EINVAL;
+   default:
+   return -EFAULT;
+   }
}
}
return 0;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h 
b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 4b0ca99..16415ca 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -66,7 +66,9 @@ enum mcc_addl_status {
MCC_ADDL_STATUS_INSUFFICIENT_RESOURCES = 0x16,
MCC_ADDL_STATUS_FLASH_IMAGE_CRC_MISMATCH = 0x4d,
MCC_ADDL_STATUS_TOO_MANY_INTERFACES = 0x4a,
-   MCC_ADDL_STATUS_INSUFFICIENT_VLANS = 0xab
+   MCC_ADDL_STATUS_INSUFFICIENT_VLANS = 0xab,
+   MCC_ADDL_STATUS_INVALID_SIGNATURE = 0x56,
+   MCC_ADDL_STATUS_MISSING_SIGNATURE = 0x57
 };
 
 #define CQE_BASE_STATUS_MASK   0x
-- 
2.4.1

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


[PATCH net-next v3 06/10] be2net: remove a line of code that has no effect

2015-12-29 Thread Sathya Perla
This patch removes a line of code that changes adapter->recommended_prio
value followed by yet another assignment.
Also, the variable is used to store the vlan priority value that is already
shifted to the PCP bits position in the vlan tag format. Hence, the name of
this variable is changed to recommended_prio_bits.

Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be.h  | 2 +-
 drivers/net/ethernet/emulex/benet/be_cmds.c | 3 +--
 drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be.h 
b/drivers/net/ethernet/emulex/benet/be.h
index d463563..93e5eab 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -521,7 +521,7 @@ struct be_adapter {
struct be_drv_stats drv_stats;
struct be_aic_obj aic_obj[MAX_EVT_QS];
u8 vlan_prio_bmap;  /* Available Priority BitMap */
-   u16 recommended_prio;   /* Recommended Priority */
+   u16 recommended_prio_bits;/* Recommended Priority bits in vlan tag */
struct be_dma_mem rx_filter; /* Cmd DMA mem for rx-filter */
 
struct be_dma_mem stats_cmd;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c 
b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 451f9ea..7c0e7ff 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -308,8 +308,7 @@ static void be_async_grp5_cos_priority_process(struct 
be_adapter *adapter,
 
if (evt->valid) {
adapter->vlan_prio_bmap = evt->available_priority_bmap;
-   adapter->recommended_prio &= ~VLAN_PRIO_MASK;
-   adapter->recommended_prio =
+   adapter->recommended_prio_bits =
evt->reco_default_priority << VLAN_PRIO_SHIFT;
}
 }
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c 
b/drivers/net/ethernet/emulex/benet/be_main.c
index 646b021..c9f9d4b 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -729,7 +729,7 @@ static inline u16 be_get_tx_vlan_tag(struct be_adapter 
*adapter,
/* If vlan priority provided by OS is NOT in available bmap */
if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
-   adapter->recommended_prio;
+   adapter->recommended_prio_bits;
 
return vlan_tag;
 }
-- 
2.4.1

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


[PATCH net-next v3 02/10] be2net: avoid configuring VEPA mode on BE3

2015-12-29 Thread Sathya Perla
From: Suresh Reddy 

BE3 chip doesn't support VEPA mode.

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
---
 drivers/net/ethernet/emulex/benet/be_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/emulex/benet/be_main.c 
b/drivers/net/ethernet/emulex/benet/be_main.c
index 34e324f..2f76cbe 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -5108,6 +5108,9 @@ static int be_ndo_bridge_setlink(struct net_device *dev, 
struct nlmsghdr *nlh,
return -EINVAL;
 
mode = nla_get_u16(attr);
+   if (BE3_chip(adapter) && mode == BRIDGE_MODE_VEPA)
+   return -EOPNOTSUPP;
+
if (mode != BRIDGE_MODE_VEPA && mode != BRIDGE_MODE_VEB)
return -EINVAL;
 
-- 
2.4.1

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


Re: 4.4-rc7 failure report

2015-12-29 Thread Alexei Starovoitov
On Mon, Dec 28, 2015 at 08:26:44PM -0500, Doug Ledford wrote:
> On 12/28/2015 05:20 PM, Daniel Borkmann wrote:
> > On 12/28/2015 10:53 PM, Doug Ledford wrote:
> >> The 4.4-rc7 kernel is failing for me.  In my case, all of my vlan
> >> interfaces are failing to obtain a dhcp address using dhclient.  I've
> >> tried a hand built 4.4-rc7, and the Fedora rawhide 4.4-rc7 kernel, both
> >> failed.  I've tried NetworkManager and the old SysV network service,
> >> both fail.  I tried a working dhclient from rhel7 on the Fedora rawhide
> >> install and it failed too.  Running tcpdump on the interface shows the
> >> dhcp request going out, and a dhcp response coming back in.  Running
> >> strace on dhclient shows that it writes the dhcp request, but it never
> >> recvs a dhcp response.  If I manually bring the interface up with a
> >> static IP address then I'm able to run typical IP traffic across the
> >> link (aka, ping).  It would seem that when dhclient registers a packet
> >> filter on the socket, that filter is preventing it from ever getting the
> >> dhcp response.  The same dhclient works on any non-vlan interfaces in
> >> the system, so the filter must work for non-vlan interfaces.  Aside from
> >> the fact that the interface is a vlan, we also use a priority egress map
> >> on the interface, and we use PFC flow control.  Let me know if you need
> >> anymore to debug the issue, or email me off list and I can get you
> >> logins to my reproducer machines.
> > 
> > When you say 4.4-rc7 kernel is failing for you, what latest kernel version
> > was working, where the socket filter was properly receiving the response on
> > your vlan iface?
> 
> v4.3 final works.  I haven't bisected where in the 4.4 series it quits
> working.  I can do that tomorrow.

I've tried to reproduce, but cannot seem to make dnsmasq work properly
over vlan, so bisect would be great.

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


Re: 4.4-rc7 failure report

2015-12-29 Thread Alexei Starovoitov
On Tue, Dec 29, 2015 at 10:44:31PM -0500, Doug Ledford wrote:
> On 12/29/2015 10:43 PM, Alexei Starovoitov wrote:
> > On Mon, Dec 28, 2015 at 08:26:44PM -0500, Doug Ledford wrote:
> >> On 12/28/2015 05:20 PM, Daniel Borkmann wrote:
> >>> On 12/28/2015 10:53 PM, Doug Ledford wrote:
>  The 4.4-rc7 kernel is failing for me.  In my case, all of my vlan
>  interfaces are failing to obtain a dhcp address using dhclient.  I've
>  tried a hand built 4.4-rc7, and the Fedora rawhide 4.4-rc7 kernel, both
>  failed.  I've tried NetworkManager and the old SysV network service,
>  both fail.  I tried a working dhclient from rhel7 on the Fedora rawhide
>  install and it failed too.  Running tcpdump on the interface shows the
>  dhcp request going out, and a dhcp response coming back in.  Running
>  strace on dhclient shows that it writes the dhcp request, but it never
>  recvs a dhcp response.  If I manually bring the interface up with a
>  static IP address then I'm able to run typical IP traffic across the
>  link (aka, ping).  It would seem that when dhclient registers a packet
>  filter on the socket, that filter is preventing it from ever getting the
>  dhcp response.  The same dhclient works on any non-vlan interfaces in
>  the system, so the filter must work for non-vlan interfaces.  Aside from
>  the fact that the interface is a vlan, we also use a priority egress map
>  on the interface, and we use PFC flow control.  Let me know if you need
>  anymore to debug the issue, or email me off list and I can get you
>  logins to my reproducer machines.
> >>>
> >>> When you say 4.4-rc7 kernel is failing for you, what latest kernel version
> >>> was working, where the socket filter was properly receiving the response 
> >>> on
> >>> your vlan iface?
> >>
> >> v4.3 final works.  I haven't bisected where in the 4.4 series it quits
> >> working.  I can do that tomorrow.
> > 
> > I've tried to reproduce, but cannot seem to make dnsmasq work properly
> > over vlan, so bisect would be great.
> > 
> 
> Yeah, I've been working on it.  Issues with available machines that
> reproduce combined with what hardware they have and whether or not that
> hardware works at various steps in the bisection :-/

I've looked through all bpf related commits between v4.3..HEAD and don't see
anything suspicious. Could it be that your setup exploited a bug that was fixed 
by 
28f9ee22bcdd ("vlan: Do not put vlan headers back on bridge and macvlan ports")

Could you also provide more details on vlan+dhcp setup to help narrow it
down if bisect is taking too long.

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


RE: [PATCHv3 net-next 2/3] phy: marvell: Add ethtool statistics counters

2015-12-29 Thread Shaohui Xie
> Subject: [PATCHv3 net-next 2/3] phy: marvell: Add ethtool statistics counters
> +static int marvell_probe(struct phy_device *phydev) {
> + struct marvell_priv *priv;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + phydev->priv = priv;
> +
> + return 0;
> +}
> +
[S.H] Is a remove() function needed to free the memory?

Thanks,
Shaohui
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv2 net] sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close

2015-12-29 Thread Xin Long
In sctp_close, sctp_make_abort_user may return NULL because of memory
allocation failure. If this happens, it will bypass any state change
and never free the assoc. The assoc has no chance to be freed and it
will be kept in memory with the state it had even after the socket is
closed by sctp_close().

So if sctp_make_abort_user fails to allocate memory, we should abort
the asoc via sctp_primitive_ABORT as well. Just like the annotation in
sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said,
"Even if we can't send the ABORT due to low memory delete the TCB.
This is a departure from our typical NOMEM handling".

But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would
dereference the chunk pointer, and system crash. So we should add
SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other
places where it adds SCTP_CMD_REPLY cmd.

Signed-off-by: Xin Long 
Acked-by: Marcelo Ricardo Leitner 
---
 net/sctp/sm_statefuns.c | 6 --
 net/sctp/socket.c   | 3 +--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index cd34a4a..22c2bf3 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -4829,7 +4829,8 @@ sctp_disposition_t sctp_sf_do_9_1_prm_abort(
 
retval = SCTP_DISPOSITION_CONSUME;
 
-   sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
+   if (abort)
+   sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
 
/* Even if we can't send the ABORT due to low memory delete the
 * TCB.  This is a departure from our typical NOMEM handling.
@@ -4966,7 +4967,8 @@ sctp_disposition_t sctp_sf_cookie_wait_prm_abort(
SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
retval = SCTP_DISPOSITION_CONSUME;
 
-   sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
+   if (abort)
+   sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
 
sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
SCTP_STATE(SCTP_STATE_CLOSED));
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 9b6cc6d..6b2f901 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1513,8 +1513,7 @@ static void sctp_close(struct sock *sk, long timeout)
struct sctp_chunk *chunk;
 
chunk = sctp_make_abort_user(asoc, NULL, 0);
-   if (chunk)
-   sctp_primitive_ABORT(net, asoc, chunk);
+   sctp_primitive_ABORT(net, asoc, chunk);
} else
sctp_primitive_SHUTDOWN(net, asoc, NULL);
}
-- 
2.1.0

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


RE: [PATCH] net: phy: adds backplane driver for Freescale's PCS PHY

2015-12-29 Thread Shaohui Xie
Hello Florian,

Thanks for reviewing the patch! 

> > +struct training_state_machine {
> > +   bool bin_m1_late_early;
> > +   bool bin_long_late_early;
> > +   bool bin_m1_stop;
> > +   bool bin_long_stop;
> > +   bool tx_complete;
> > +   bool an_ok;
> > +   bool link_up;
> > +   bool running;
> > +   bool sent_init;
> > +   int m1_min_max_cnt;
> > +   int long_min_max_cnt;
> 
> Can you change this into a succession of enum values to make it clear how
> many states there are, and how to get from one to the other?
[S.H] OK. I'll make the states clear in next version. 
Actually, the structure members above are not all states, most of them are 
conditions used to decide what actions should be taken during training.

> 
> [snip]
> 
> > +
> > +static void init_state_machine(struct training_state_machine *s_m) {
> > +   s_m->bin_m1_late_early = true;
> > +   s_m->bin_long_late_early = false;
> > +   s_m->bin_m1_stop = false;
> > +   s_m->bin_long_stop = false;
> > +   s_m->tx_complete = false;
> > +   s_m->an_ok = false;
> > +   s_m->link_up = false;
> > +   s_m->running = false;
> > +   s_m->sent_init = false;
> > +   s_m->m1_min_max_cnt = 0;
> > +   s_m->long_min_max_cnt = 0;
> 
> That alone is a good indication that your state machine is not readable.
[S.H] Will improve it.

> 
> > +}
> > +
> > +void tune_tecr0(struct fsl_xgkr_inst *inst) {
> > +   struct per_lane_ctrl_status *reg_base;
> > +   u32 val;
> > +
> > +   reg_base = (struct per_lane_ctrl_status *)inst->reg_base;
> 
> Typical practice is not to cast a register base address into a pointer to
> a structure, but instead use offsets to the base register address, which
> is less error prone and more readable, anything that uses
> inst->reg_base in this driver is modeled after a structure pattern,
> please fix that.
[S.H] OK. The inst->reg_base can be used directly without cast since it's
defined as void*, will drop the cast.

> 
> > +
> > +   val = TECR0_INIT |
> > +   inst->adpt_eq << ZERO_COE_SHIFT |
> > +   inst->ratio_preq << PRE_COE_SHIFT |
> > +   inst->ratio_pst1q << POST_COE_SHIFT;
> > +
> > +   /* reset the lane */
> > +   iowrite32be(ioread32be(_base->gcr0) & ~GCR0_RESET_MASK,
> > +   _base->gcr0);
> > +   udelay(1);
> > +   iowrite32be(val, _base->tecr0);
> > +   udelay(1);
> > +   /* unreset the lane */
> > +   iowrite32be(ioread32be(_base->gcr0) | GCR0_RESET_MASK,
> > +   _base->gcr0);
> > +   udelay(1);
> 
> Since this is a reset control register, you might want to explore using
> the reset controller subsystem in case this register serves multiple
> peripherals.
[S.H] this is per lane register, the lane cannot serve multiple peripherals 
at a time, when it serves backplane, it only serves backplane.

> 
> [snip]
> 
> I skipped through all the state machine logic, but you should consider
> trying to simplify it using different enum values and a switch() case()
> statements to make it easy to audit and understand.
[S.H] OK. I'll make state machine logic clear.

> 
> > +
> > +static int fsl_backplane_probe(struct phy_device *phydev) {
> > +   struct fsl_xgkr_inst *xgkr_inst;
> > +   struct device_node *child, *parent, *lane_node;
> > +   const char *lane_name;
> > +   int len;
> > +   int ret;
> > +   u32 mode;
> > +   u32 lane[2];
> > +
> > +   child = phydev->dev.of_node;
> > +   parent = of_get_parent(child);
> > +   if (!parent) {
> > +   dev_err(>dev, "could not get parent node");
> > +   return 0;
> > +   }
> > +
> > +   lane_name = of_get_property(parent, "lane-instance", );
> > +   if (!lane_name)
> > +   return 0;
> > +
> > +   if (strstr(lane_name, "1000BASE-KX"))
> > +   mode = BACKPLANE_1G_KX;
> > +   else
> > +   mode = BACKPLANE_10G_KR;
> 
> That seems like I could put whatever value in "lane-instance" and as long
> as it contains 1000BASE-KX we are golden, that does not sound very robust
> nor well defined.
[S.H] Will use strcmp instead of strstr, also add check for 10GBASE-KR.

> 
> > +
> > +   lane_node = of_parse_phandle(child, "lane-handle", 0);
> > +   if (lane_node) {
> 
> Treat this as an error so you can return early and reduce indentation.
[S.H] Ok. Will use if (!lane_node).

> 
> > +   struct resource res_lane;
> > +
> > +   ret = of_address_to_resource(lane_node, 0, _lane);
> > +   if (ret) {
> > +   dev_err(>dev, "could not obtain memory map\n");
> > +   return ret;
> > +   }
> > +
> > +   ret = of_property_read_u32_array(child, "lane-range",
> > +(u32 *), 2);
> > +   if (ret) {
> > +   dev_info(>dev, "could not get lane-range\n");
> > +   return -EINVAL;
> > +   }
> 
> Is not the standard "ranges" property usable here?
[S.H] "lane-range" defines offset and length of register set for a serdes lane,
The standard "ranges" property might not quite fit here.

> 
> > +

Re: [PATCH] af_unix: Fix splice-bind deadlock

2015-12-29 Thread Hannes Frederic Sowa

Hello Rainer,

On 27.12.2015 21:13, Rainer Weikusat wrote:

-static int unix_mknod(const char *sun_path, umode_t mode, struct path *res)
+static int unix_mknod(struct dentry *dentry, struct path *path, umode_t mode,
+ struct path *res)
  {
-   struct dentry *dentry;
-   struct path path;
-   int err = 0;
-   /*
-* Get the parent directory, calculate the hash for last
-* component.
-*/
-   dentry = kern_path_create(AT_FDCWD, sun_path, , 0);
-   err = PTR_ERR(dentry);
-   if (IS_ERR(dentry))
-   return err;
+   int err;

-   /*
-* All right, let's create it.
-*/
-   err = security_path_mknod(, dentry, mode, 0);
+   err = security_path_mknod(path, dentry, mode, 0);
if (!err) {
-   err = vfs_mknod(d_inode(path.dentry), dentry, mode, 0);
+   err = vfs_mknod(d_inode(path->dentry), dentry, mode, 0);
if (!err) {
-   res->mnt = mntget(path.mnt);
+   res->mnt = mntget(path->mnt);
res->dentry = dget(dentry);
}
}
-   done_path_create(, dentry);
+


The reordered call to done_path_create will change the locking ordering 
between the i_mutexes and the unix readlock. Can you comment on this? On 
a first sight this looks like a much more dangerous change than the 
original deadlock report. Can't this also conflict with splice code deep 
down in vfs layer?


Thanks,
  Hannes

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


Re: [RFC PATCH net-next 3/3] macsec: introduce IEEE 802.1AE driver

2015-12-29 Thread Sabrina Dubroca
2015-12-29, 02:14:06 +0100, Florian Westphal wrote:
> Sabrina Dubroca  wrote:
> > +   if (h->short_length)
> > +   return len == h->short_length + 24;
> > +   else
> > +   return len >= 72;
> [..]
> > +   return len == h->short_length + 32;
> [..]
> > +   return len >= 80;
> [..]
> > +   return len == 8 + icv_len + h->short_length;
> > +   else
> > +   return len >= 8 + icv_len + 48;
> [..]
> > +   if (h->short_length)
> > +   return len == 16 + icv_len + h->short_length;
> > +   else
> > +   return len >= 16 + icv_len + 48;
> 
> Could you add some defines instead of magic numbers?

Sure.


> > +   tx_sa->next_pn++;
> > +   if (tx_sa->next_pn == 0) {
> > +   pr_notice("PN wrapped, transitionning to !oper\n");
> 
> Is that _notice intentional?
> I'm only asking because it seems we printk unconditionally in response
> to network traffic & I don't get what operator should do in response to
> that message.

The operator should install a new tx_sa, or MKA should have already
installed a new one and switched to it.
I can remove this message, or make it a pr_debug.


> > +static void macsec_encrypt_done(struct crypto_async_request *base, int err)
> > +{
> > +   struct sk_buff *skb = base->data;
> > +   struct net_device *dev = skb->dev;
> > +   struct macsec_dev *macsec = macsec_priv(dev);
> > +   struct macsec_tx_sa *sa = macsec_skb_cb(skb)->tx_sa;
> > +   int len, ret;
> > +
> > +   aead_request_free(macsec_skb_cb(skb)->req);
> > +
> > +   rcu_read_lock_bh();
> > +   macsec_encrypt_finish(skb, dev);
> > +   macsec_count_tx(skb, >secy.tx_sc, macsec_skb_cb(skb)->tx_sa);
> > +   len = skb->len;
> > +   ret = dev_queue_xmit(skb);
> > +   count_tx(dev, ret, len);
> > +   rcu_read_unlock_bh();
> 
> What was the rcu_read_lock_bh protecting?

this_cpu_ptr in macsec_count_tx and count_tx.  Separate get_cpu_ptr in
both functions seem a bit wasteful, and dev_queue_xmit will also
disable bh.

I could turn that into a preempt_disable with a comment (something
like "covers multiple accesses to pcpu variables").  Or I could get
rid of it, and use get/put_cpu_ptr in macsec_count_tx/count_tx.
Note that macsec_count_tx/count_tx (and count_rx below) are also
called from the normal packet processing path, where we already run
under rcu_read_lock_bh anyway, so avoiding the overhead of an extra
get_cpu_ptr seems preferable.


> > +static void macsec_decrypt_done(struct crypto_async_request *base, int err)
> > +{
> > +   struct sk_buff *skb = base->data;
> > +   struct net_device *dev = skb->dev;
> > +   struct macsec_dev *macsec = macsec_priv(dev);
> > +   struct macsec_rx_sa *rx_sa = macsec_skb_cb(skb)->rx_sa;
> > +   int len, ret;
> > +
> > +   aead_request_free(macsec_skb_cb(skb)->req);
> > +
> > +   rcu_read_lock_bh();
> > +   macsec_finalize_skb(skb, macsec->secy.icv_len,
> > +   macsec_extra_len(macsec_skb_cb(skb)->has_sci));
> > +   macsec_reset_skb(skb, macsec->secy.netdev);
> > +
> > +   macsec_rxsa_put(rx_sa);
> > +   len = skb->len;
> > +   ret = netif_rx(skb);
> > +   if (ret == NET_RX_SUCCESS)
> > +   count_rx(dev, len);
> > +   else
> > +   macsec->secy.netdev->stats.rx_dropped++;
> > +
> > +   rcu_read_unlock_bh();
> 
> Same question.

Yes, that's pretty much the same situation.


> > +static void handle_not_macsec(struct sk_buff *skb)
> > +{
> > +   struct macsec_rxh_data *rxd = macsec_data_rcu(skb->dev);
> > +   struct macsec_dev *macsec;
> > +
> > +   /* 10.6 If the management control validateFrames is not
> > +* Strict, frames without a SecTAG are received, counted, and
> > +* delivered to the Controlled Port
> > +*/
> > +   list_for_each_entry_rcu(macsec, >secys, secys) {
> > +   struct sk_buff *nskb;
> > +   int ret;
> > +   struct pcpu_secy_stats *secy_stats = 
> > this_cpu_ptr(macsec->stats);
> > +
> > +   if (macsec->secy.validate_frames == MACSEC_VALIDATE_STRICT) {
> > +   u64_stats_update_begin(_stats->syncp);
> > +   secy_stats->stats.InPktsNoTag++;
> > +   u64_stats_update_end(_stats->syncp);
> > +   continue;
> > +   }
> > +
> > +   /* deliver on this port */
> > +   nskb = skb_clone(skb, GFP_ATOMIC);
> > +   nskb->dev = macsec->secy.netdev;
> 
> nskb == NULL handling?

Right, I'll take care of both of these, thanks.


> > +static rx_handler_result_t macsec_handle_frame(struct sk_buff **pskb)
> > +{
> > +   struct sk_buff *skb = *pskb;
> > +   struct net_device *dev = skb->dev;
> > +   struct macsec_eth_header *hdr;
> > +   struct macsec_secy *secy = NULL;
> > +   struct macsec_rx_sc *rx_sc;
> > +   struct macsec_rx_sa *rx_sa;
> > +   struct macsec_rxh_data *rxd;
> > +   struct macsec_dev *macsec;
> > +   sci_t sci;
> > +   u32 pn, 

[PATCH net-next V3 3/4] net/mlx5e: Add HW timestamping (TS) support

2015-12-29 Thread Saeed Mahameed
From: Eran Ben Elisha 

Add support for enable/disable HW timestamping for incoming and/or
outgoing packets. To enable/disable HW timestamping appropriate
ioctl should be used. Currently HWTSTAMP_FILTER_ALL/NONE and
HWTSAMP_TX_ON/OFF only are supported. Make all relevant changes in
RX/TX flows to consider TS request and plant HW timestamps into
relevant structures.

Add internal clock for converting hardware timestamp to nanoseconds. In
addition, add a service task to catch internal clock overflow, to make
sure timestamping is accurate.

Signed-off-by: Eran Ben Elisha 
Signed-off-by: Saeed Mahameed 
---
 drivers/net/ethernet/mellanox/mlx5/core/Makefile   |2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h   |   23 +++
 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c |  187 
 .../net/ethernet/mellanox/mlx5/core/en_ethtool.c   |   29 +++
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |   19 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c|9 +
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c|   12 ++
 7 files changed, 279 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile 
b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index fe11e96..01c0256 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -5,4 +5,4 @@ mlx5_core-y :=  main.o cmd.o debugfs.o fw.o eq.o uar.o 
pagealloc.o \
mad.o transobj.o vport.o sriov.o fs_cmd.o fs_core.o
 mlx5_core-$(CONFIG_MLX5_CORE_EN) += wq.o eswitch.o \
en_main.o en_fs.o en_ethtool.o en_tx.o en_rx.o \
-   en_txrx.o
+   en_txrx.o en_clock.o
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h 
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index ae3f0e3..477e248 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -32,6 +32,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -284,6 +286,17 @@ struct mlx5e_params {
u32 indirection_rqt[MLX5E_INDIR_RQT_SIZE];
 };
 
+struct mlx5e_tstamp {
+   rwlock_t   lock;
+   struct cyclecountercycles;
+   struct timecounter clock;
+   struct hwtstamp_config hwtstamp_config;
+   u32nominal_c_mult;
+   unsigned long  overflow_period;
+   struct delayed_workoverflow_work;
+   struct mlx5_core_dev  *mdev;
+};
+
 enum {
MLX5E_RQ_STATE_POST_WQES_ENABLE,
 };
@@ -315,6 +328,7 @@ struct mlx5e_rq {
 
struct device *pdev;
struct net_device *netdev;
+   struct mlx5e_tstamp   *tstamp;
struct mlx5e_rq_stats  stats;
struct mlx5e_cqcq;
 
@@ -382,6 +396,7 @@ struct mlx5e_sq {
u16max_inline;
u16edge;
struct device *pdev;
+   struct mlx5e_tstamp   *tstamp;
__be32 mkey_be;
unsigned long  state;
 
@@ -518,6 +533,7 @@ struct mlx5e_priv {
struct mlx5_core_dev  *mdev;
struct net_device *netdev;
struct mlx5e_stats stats;
+   struct mlx5e_tstamptstamp;
 };
 
 #define MLX5E_NET_IP_ALIGN 2
@@ -584,6 +600,13 @@ void mlx5e_destroy_flow_tables(struct mlx5e_priv *priv);
 void mlx5e_init_eth_addr(struct mlx5e_priv *priv);
 void mlx5e_set_rx_mode_work(struct work_struct *work);
 
+void mlx5e_fill_hwstamp(struct mlx5e_tstamp *clock, u64 timestamp,
+   struct skb_shared_hwtstamps *hwts);
+void mlx5e_timestamp_init(struct mlx5e_priv *priv);
+void mlx5e_timestamp_cleanup(struct mlx5e_priv *priv);
+int mlx5e_hwstamp_set(struct net_device *dev, struct ifreq *ifr);
+int mlx5e_hwstamp_get(struct net_device *dev, struct ifreq *ifr);
+
 int mlx5e_vlan_rx_add_vid(struct net_device *dev, __always_unused __be16 proto,
  u16 vid);
 int mlx5e_vlan_rx_kill_vid(struct net_device *dev, __always_unused __be16 
proto,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
new file mode 100644
index 000..49a8238
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015, Mellanox Technologies. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, 

[PATCH net-next V3 1/4] net/mlx5e: Do not modify the TX SKB

2015-12-29 Thread Saeed Mahameed
From: Achiad Shochat 

If the SKB is cloned, or has an elevated users count, someone else
can be looking at it at the same time.

Signed-off-by: Achiad Shochat 
Signed-off-by: Saeed Mahameed 
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h  |5 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c |5 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c   |   73 -
 3 files changed, 49 insertions(+), 34 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h 
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index f689ce5..ae3f0e3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -328,14 +328,12 @@ struct mlx5e_rq {
struct mlx5e_priv *priv;
 } cacheline_aligned_in_smp;
 
-struct mlx5e_tx_skb_cb {
+struct mlx5e_tx_wqe_info {
u32 num_bytes;
u8  num_wqebbs;
u8  num_dma;
 };
 
-#define MLX5E_TX_SKB_CB(__skb) ((struct mlx5e_tx_skb_cb *)__skb->cb)
-
 enum mlx5e_dma_map_type {
MLX5E_DMA_MAP_SINGLE,
MLX5E_DMA_MAP_PAGE
@@ -371,6 +369,7 @@ struct mlx5e_sq {
/* pointers to per packet info: write@xmit, read@completion */
struct sk_buff   **skb;
struct mlx5e_sq_dma   *dma_fifo;
+   struct mlx5e_tx_wqe_info  *wqe_info;
 
/* read only */
struct mlx5_wq_cyc wq;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index d4601a5..96775a2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -507,6 +507,7 @@ static void mlx5e_close_rq(struct mlx5e_rq *rq)
 
 static void mlx5e_free_sq_db(struct mlx5e_sq *sq)
 {
+   kfree(sq->wqe_info);
kfree(sq->dma_fifo);
kfree(sq->skb);
 }
@@ -519,8 +520,10 @@ static int mlx5e_alloc_sq_db(struct mlx5e_sq *sq, int numa)
sq->skb = kzalloc_node(wq_sz * sizeof(*sq->skb), GFP_KERNEL, numa);
sq->dma_fifo = kzalloc_node(df_sz * sizeof(*sq->dma_fifo), GFP_KERNEL,
numa);
+   sq->wqe_info = kzalloc_node(wq_sz * sizeof(*sq->wqe_info), GFP_KERNEL,
+   numa);
 
-   if (!sq->skb || !sq->dma_fifo) {
+   if (!sq->skb || !sq->dma_fifo || !sq->wqe_info) {
mlx5e_free_sq_db(sq);
return -ENOMEM;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
index 1341b1d..aa037eb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
@@ -92,11 +92,11 @@ static inline struct mlx5e_sq_dma *mlx5e_dma_get(struct 
mlx5e_sq *sq, u32 i)
return >dma_fifo[i & sq->dma_fifo_mask];
 }
 
-static void mlx5e_dma_unmap_wqe_err(struct mlx5e_sq *sq, struct sk_buff *skb)
+static void mlx5e_dma_unmap_wqe_err(struct mlx5e_sq *sq, u8 num_dma)
 {
int i;
 
-   for (i = 0; i < MLX5E_TX_SKB_CB(skb)->num_dma; i++) {
+   for (i = 0; i < num_dma; i++) {
struct mlx5e_sq_dma *last_pushed_dma =
mlx5e_dma_get(sq, --sq->dma_fifo_pc);
 
@@ -139,19 +139,28 @@ static inline u16 mlx5e_get_inline_hdr_size(struct 
mlx5e_sq *sq,
return MLX5E_MIN_INLINE;
 }
 
-static inline void mlx5e_insert_vlan(void *start, struct sk_buff *skb, u16 ihs)
+static inline void mlx5e_tx_skb_pull_inline(unsigned char **skb_data,
+   unsigned int *skb_len,
+   unsigned int len)
+{
+   *skb_len -= len;
+   *skb_data += len;
+}
+
+static inline void mlx5e_insert_vlan(void *start, struct sk_buff *skb, u16 ihs,
+unsigned char **skb_data,
+unsigned int *skb_len)
 {
struct vlan_ethhdr *vhdr = (struct vlan_ethhdr *)start;
int cpy1_sz = 2 * ETH_ALEN;
int cpy2_sz = ihs - cpy1_sz;
 
-   skb_copy_from_linear_data(skb, vhdr, cpy1_sz);
-   skb_pull_inline(skb, cpy1_sz);
+   memcpy(vhdr, *skb_data, cpy1_sz);
+   mlx5e_tx_skb_pull_inline(skb_data, skb_len, cpy1_sz);
vhdr->h_vlan_proto = skb->vlan_proto;
vhdr->h_vlan_TCI = cpu_to_be16(skb_vlan_tag_get(skb));
-   skb_copy_from_linear_data(skb, >h_vlan_encapsulated_proto,
- cpy2_sz);
-   skb_pull_inline(skb, cpy2_sz);
+   memcpy(>h_vlan_encapsulated_proto, *skb_data, cpy2_sz);
+   mlx5e_tx_skb_pull_inline(skb_data, skb_len, cpy2_sz);
 }
 
 static netdev_tx_t mlx5e_sq_xmit(struct mlx5e_sq *sq, struct sk_buff *skb)
@@ -160,11 +169,14 @@ static netdev_tx_t mlx5e_sq_xmit(struct mlx5e_sq *sq, 
struct sk_buff *skb)
 
u16 pi = sq->pc & wq->sz_m1;
struct mlx5e_tx_wqe  *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
+   struct 

[PATCH net-next V3 4/4] net/mlx5e: Add PTP Hardware Clock (PHC) support

2015-12-29 Thread Saeed Mahameed
From: Eran Ben Elisha 

Add a PHC support to the mlx5_en driver. Use reader/writer spinlocks to
protect the timecounter since every packet received needs to call
timecounter_cycle2time() when timestamping is enabled.  This can become
a performance bottleneck with RSS and multiple receive queues if normal
spinlocks are used.

The driver has been tested with both Documentation/ptp/testptp and the
linuxptp project (http://linuxptp.sourceforge.net/) on a Mellanox
ConnectX-4 card.

Signed-off-by: Eran Ben Elisha 
Cc: Richard Cochran 
Signed-off-by: Saeed Mahameed 
---
 drivers/net/ethernet/mellanox/mlx5/core/Kconfig|1 +
 drivers/net/ethernet/mellanox/mlx5/core/en.h   |3 +
 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c |  100 
 .../net/ethernet/mellanox/mlx5/core/en_ethtool.c   |3 +-
 4 files changed, 106 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig 
b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index 158c88c..c503ea0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -13,6 +13,7 @@ config MLX5_CORE
 config MLX5_CORE_EN
bool "Mellanox Technologies ConnectX-4 Ethernet support"
depends on NETDEVICES && ETHERNET && PCI && MLX5_CORE
+   select PTP_1588_CLOCK
default n
---help---
  Ethernet support in Mellanox Technologies ConnectX-4 NIC.
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h 
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 477e248..9ea49a8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -295,6 +296,8 @@ struct mlx5e_tstamp {
unsigned long  overflow_period;
struct delayed_workoverflow_work;
struct mlx5_core_dev  *mdev;
+   struct ptp_clock  *ptp;
+   struct ptp_clock_info  ptp_info;
 };
 
 enum {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
index 49a8238..be65435 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
@@ -130,6 +130,89 @@ int mlx5e_hwstamp_get(struct net_device *dev, struct ifreq 
*ifr)
return copy_to_user(ifr->ifr_data, cfg, sizeof(*cfg)) ? -EFAULT : 0;
 }
 
+static int mlx5e_ptp_settime(struct ptp_clock_info *ptp,
+const struct timespec64 *ts)
+{
+   struct mlx5e_tstamp *tstamp = container_of(ptp, struct mlx5e_tstamp,
+  ptp_info);
+   u64 ns = timespec64_to_ns(ts);
+
+   write_lock(>lock);
+   timecounter_init(>clock, >cycles, ns);
+   write_unlock(>lock);
+
+   return 0;
+}
+
+static int mlx5e_ptp_gettime(struct ptp_clock_info *ptp,
+struct timespec64 *ts)
+{
+   struct mlx5e_tstamp *tstamp = container_of(ptp, struct mlx5e_tstamp,
+  ptp_info);
+   u64 ns;
+
+   write_lock(>lock);
+   ns = timecounter_read(>clock);
+   write_unlock(>lock);
+
+   *ts = ns_to_timespec64(ns);
+
+   return 0;
+}
+
+static int mlx5e_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+   struct mlx5e_tstamp *tstamp = container_of(ptp, struct mlx5e_tstamp,
+  ptp_info);
+
+   write_lock(>lock);
+   timecounter_adjtime(>clock, delta);
+   write_unlock(>lock);
+
+   return 0;
+}
+
+static int mlx5e_ptp_adjfreq(struct ptp_clock_info *ptp, s32 delta)
+{
+   u64 adj;
+   u32 diff;
+   int neg_adj = 0;
+   struct mlx5e_tstamp *tstamp = container_of(ptp, struct mlx5e_tstamp,
+ ptp_info);
+
+   if (delta < 0) {
+   neg_adj = 1;
+   delta = -delta;
+   }
+
+   adj = tstamp->nominal_c_mult;
+   adj *= delta;
+   diff = div_u64(adj, 10ULL);
+
+   write_lock(>lock);
+   timecounter_read(>clock);
+   tstamp->cycles.mult = neg_adj ? tstamp->nominal_c_mult - diff :
+   tstamp->nominal_c_mult + diff;
+   write_unlock(>lock);
+
+   return 0;
+}
+
+static const struct ptp_clock_info mlx5e_ptp_clock_info = {
+   .owner  = THIS_MODULE,
+   .max_adj= 1,
+   .n_alarm= 0,
+   .n_ext_ts   = 0,
+   .n_per_out  = 0,
+   .n_pins = 0,
+   .pps= 0,
+   .adjfreq= mlx5e_ptp_adjfreq,
+   .adjtime= mlx5e_ptp_adjtime,
+   .gettime64  = mlx5e_ptp_gettime,
+   .settime64  = mlx5e_ptp_settime,
+   .enable   

[PATCH net-next V3 0/4] Introduce mlx5 ethernet timestamping

2015-12-29 Thread Saeed Mahameed
Hi Dave,

This patch series introduces the support for ConnectX-4 timestamping
and the PTP kernel interface.

Changes from V2:
net/mlx5_core: Introduce access function to read internal_timer
- Remove one line function
- Change function name

net/mlx5e: Add HW timestamping (TS) support:
- Data path performance optimization (caching tstamp struct in rq,sq)
- Change read/write_lock_irqsave to read/write_lock
- Move ioctl functions to en_clock file
- Changed overflow start algorithm according to comments from Richard
- Move timestamp init/cleanup to open/close ndos.

In details:

1st patch prevents the driver from modifying skb->data and SKB CB in
device xmit function.

2nd patch adds the needed low level helpers for:
- Fetching the hardware clock (hardware internal timer)
- Parsing CQEs timestamps
- Device frequency capability

3rd patch adds new en_clock.c file that handles all needed timestamping
operations:
- Internal clock structure initialization and other helper functions
- Added the needed ioctl for setting/getting the current timestamping
  configuration.
- used this configuration in RX/TX data path to fill the SKB with 
  the timestamp.

4th patch Introduces PTP (PHC) support.

Achiad Shochat (1):
  net/mlx5e: Do not modify the TX SKB

Eran Ben Elisha (3):
  net/mlx5_core: Introduce access function to read internal timer
  net/mlx5e: Add HW timestamping (TS) support
  net/mlx5e: Add PTP Hardware Clock (PHC) support

 drivers/net/ethernet/mellanox/mlx5/core/Kconfig|1 +
 drivers/net/ethernet/mellanox/mlx5/core/Makefile   |2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h   |   31 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c |  287 
 .../net/ethernet/mellanox/mlx5/core/en_ethtool.c   |   30 ++
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c  |   24 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c|9 +
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c|   85 --
 drivers/net/ethernet/mellanox/mlx5/core/main.c |   13 +
 .../net/ethernet/mellanox/mlx5/core/mlx5_core.h|1 +
 include/linux/mlx5/device.h|   20 ++-
 include/linux/mlx5/mlx5_ifc.h  |6 +-
 12 files changed, 467 insertions(+), 42 deletions(-)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en_clock.c

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


Re: [PATCH] netconsole: Initialize after all core networking drivers

2015-12-29 Thread Hannes Frederic Sowa

On 29.12.2015 00:21, Cong Wang wrote:

On Thu, Dec 24, 2015 at 2:25 AM, Hannes Frederic Sowa
 wrote:

Hi,

On 24.12.2015 00:03, Calvin Owens wrote:

This patch addresses the issue cited in 7332a13b038be05c by making vxlan
actually check if ipv6 is loaded, and reverts it to module_init() so
that it becomes device_initcall() when built-in, eliminating the
netconsole issue.

The ipv6 module is permanent, so there's no need to actually do the
usual module_get/module_put dance: once we find it loaded, we can just
assume that it always will be.

AFAICS, nothing actually ends up calling vxlan_open() during initcalls,
so in the (IPV6=y && VXLAN=y) case we can't end up there before ipv6 has
initialized.

Signed-off-by: Calvin Owens 


This architecture just sucks. :(


ixgbe should not have to call into vxlan but vxlan has to call to ixgbe.
Thus the vxlan_get_rx_port is absolutely unnecessary and should be
removed. This also lets ixgbe depend on vxlan which is absurd.

Simply let vxlan_get_rx_port be called from vxlan_notifier_block on
NETDEV_REGISTER or NETDEV_UP events, which is already available.

For the second vxlan_get_rx_port case, which is a
IXGBE_FLAG2_VXLAN_REREG_NEEDED needed event, I would suggest we also
push that over to the vxlan_notifier_block, maybe with a new event type
for the notifiers.

After this change ixgbe would not depend on vxlan module any more.



Agreed with this direction, but not yet convinced with this approach.

My feeling is that we should move this piece of code into core
networking, so that both vxlan and ixgbe driver can call it without
worrying about the dependencies. It looks like all we need here
is a per-netns structure about family and ports for all vxlans.
But I could overlook something here.


We actually have that already in terms of net_generic(vxlan_net_id). We 
will also need that for geneve and other offloads supported by hardware.


Your approach seems to be basically the same like mine, just in your 
proposal the driver calls to all the helper functions, while in my 
proposal the vxlan/geneve and other layers can update the offload 
settings on the hardware.


As the notifier_blocks are already available and registered, why not 
just use them?


Thanks,
Hannes

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


Re: Q: bad routing table cache entries

2015-12-29 Thread Sowmini Varadhan
On (12/29/15 13:54), Stas Sergeev wrote:
> 
> ip route get 91.189.89.238
> 91.189.89.238 via 192.168.0.1 dev eth0  src 192.168.10.202
> cache 
 :
> Now, 192.168.0.1 is also a valid gateway, but it is outside
> of the network mask for the eth0 interface:
 :
> So my question is: why does linux allow an invalid redirect
> entries? Is it a problem with my setup, or some kernel bug,
> or some router setup problem? Where should I look into, to
> nail this down?

Seems like the problem is in the router that is sending
the bad redirect. You would have to check into the configuration
and/or implementation of the router- it should not be sending
back a redirect in the above case (different netmasks) even
if the ingress and egress physical interfaces are the same.

--Sowmini

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


[PATCH net-next 2/3] r8169:Fix typo in setting RTL8168H PHY PFM mode.

2015-12-29 Thread Chunhao Lin
The PHY PFM register is in PHY page 0x0a44 register 0x11, not 0x14.

Signed-off-by: Chunhao Lin 
---
 drivers/net/ethernet/realtek/r8169.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index 0decc1b..629f5e5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3894,7 +3894,7 @@ static void rtl8168h_1_hw_phy_config(struct 
rtl8169_private *tp)
 
/* disable phy pfm mode */
rtl_writephy(tp, 0x1f, 0x0a44);
-   rtl_w0w1_phy(tp, 0x14, 0x, 0x0080);
+   rtl_w0w1_phy(tp, 0x11, 0x, 0x0080);
rtl_writephy(tp, 0x1f, 0x);
 
/* Check ALDPS bit, disable it if enabled */
@@ -3967,7 +3967,7 @@ static void rtl8168h_2_hw_phy_config(struct 
rtl8169_private *tp)
 
/* disable phy pfm mode */
rtl_writephy(tp, 0x1f, 0x0a44);
-   rtl_w0w1_phy(tp, 0x14, 0x, 0x0080);
+   rtl_w0w1_phy(tp, 0x11, 0x, 0x0080);
rtl_writephy(tp, 0x1f, 0x);
 
/* Check ALDPS bit, disable it if enabled */
-- 
1.9.1

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


[PATCH v2 1/3] bpf: hash: use atomic count

2015-12-29 Thread Ming Lei
Preparing for removing global per-hashtable lock, so
the counter need to be defined as aotmic_t first.

Acked-by: Daniel Borkmann 
Signed-off-by: Ming Lei 
---
 kernel/bpf/hashtab.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 34777b3..2615388 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -18,7 +18,7 @@ struct bpf_htab {
struct bpf_map map;
struct hlist_head *buckets;
raw_spinlock_t lock;
-   u32 count;  /* number of elements in this hashtable */
+   atomic_t count; /* number of elements in this hashtable */
u32 n_buckets;  /* number of hash buckets */
u32 elem_size;  /* size of each element in bytes */
 };
@@ -106,7 +106,7 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
INIT_HLIST_HEAD(>buckets[i]);
 
raw_spin_lock_init(>lock);
-   htab->count = 0;
+   atomic_set(>count, 0);
 
return >map;
 
@@ -256,7 +256,7 @@ static int htab_map_update_elem(struct bpf_map *map, void 
*key, void *value,
 
l_old = lookup_elem_raw(head, l_new->hash, key, key_size);
 
-   if (!l_old && unlikely(htab->count >= map->max_entries)) {
+   if (!l_old && unlikely(atomic_read(>count) >= map->max_entries)) {
/* if elem with this 'key' doesn't exist and we've reached
 * max_entries limit, fail insertion of new elem
 */
@@ -284,7 +284,7 @@ static int htab_map_update_elem(struct bpf_map *map, void 
*key, void *value,
hlist_del_rcu(_old->hash_node);
kfree_rcu(l_old, rcu);
} else {
-   htab->count++;
+   atomic_inc(>count);
}
raw_spin_unlock_irqrestore(>lock, flags);
 
@@ -319,7 +319,7 @@ static int htab_map_delete_elem(struct bpf_map *map, void 
*key)
 
if (l) {
hlist_del_rcu(>hash_node);
-   htab->count--;
+   atomic_dec(>count);
kfree_rcu(l, rcu);
ret = 0;
}
@@ -339,7 +339,7 @@ static void delete_all_elements(struct bpf_htab *htab)
 
hlist_for_each_entry_safe(l, n, head, hash_node) {
hlist_del_rcu(>hash_node);
-   htab->count--;
+   atomic_dec(>count);
kfree(l);
}
}
-- 
1.9.1

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


[PATCH v2 0/3] bpf: hash: use per-bucket spinlock

2015-12-29 Thread Ming Lei
Hi,

This patchset tries to optimize ebpf hash map, and follows
the idea:

Both htab_map_update_elem() and htab_map_delete_elem()
can be called from eBPF program, and they may be in kernel
hot path, it isn't efficient to use a per-hashtable lock
in this two helpers, so this patch converts the lock into
per-bucket spinlock.

With this patchset, looks the performance penalty from eBPF
decreased a lot, see the following test:

1) run 'tools/biolatency' of bcc before running block test;

2) run fio to test block throught over /dev/nullb0,
(randread, 16jobs, libaio, 4k bs) and the test box
is one 24cores(dual sockets) VM server:
- without patchset:  607K IOPS
- with this patchset: 1184K IOPS
- without running eBPF prog: 1492K IOPS

TODO:
- remove the per-hashtable atomic counter

V2:
- fix checking on buckets size
V1:
- fix the wrong 3/3 patch

 kernel/bpf/hashtab.c | 64 +++-
 1 file changed, 38 insertions(+), 26 deletions(-)

Thanks,
Ming Lei


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


  1   2   >