Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

2017-08-02 Thread Coelho, Luciano
On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote:
> "Luis R. Rodriguez"  writes:
> 
> > > +int request_firmware_nowait(struct module *module, bool uevent,
> > > + const char *name, struct device *device, gfp_t gfp,
> > > + void *context,
> > > + void (*cont)(const struct firmware *fw, void 
> > > *context))
> > > +{
> > > + unsigned int opt_flags = FW_OPT_FALLBACK |
> > > + (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
> > > +
> > > + return __request_firmware_nowait(module, opt_flags, name, device, gfp,
> > > +  context, cont);
> > > +}
> > >  EXPORT_SYMBOL(request_firmware_nowait);
> > >  
> > > +int __request_firmware_async(struct module *module, const char *name,
> > > +  struct firmware_opts *fw_opts, struct device *dev,
> > > +  void *context,
> > > +  void (*cont)(const struct firmware *fw, void 
> > > *context))
> > > +{
> > > + unsigned int opt_flags = FW_OPT_UEVENT;
> > 
> > This exposes a long issue. Think -- why do we want this enabled by default? 
> > Its
> > actually because even though the fallback stuff is optional and can be, the 
> > uevent
> > internal flag *also* provides caching support as a side consequence only. We
> > don't want to add a new API without first cleaning up that mess.
> > 
> > This is a slipery slope and best to clean that up before adding any new API.
> > 
> > That and also Greg recently stated he would like to see at least 3 users of
> > a feature before adding it. Although I think that's pretty arbitrary, and
> > considering that request_firmware_into_buf() only has *one* user -- its what
> > he wishes.
> 
> ath10k at least needs a way to silence the warning for missing firmware
> and I think iwlwifi also.

Yes, iwlwifi needs to silence the warning.  It the feature (only one,
really) that I've been waiting for.

--
Luca.

[PATCH net-next v2 1/2] bpf: add support for sys_enter_* and sys_exit_* tracepoints

2017-08-02 Thread Yonghong Song
Currently, bpf programs cannot be attached to sys_enter_* and sys_exit_*
style tracepoints. The iovisor/bcc issue #748
(https://github.com/iovisor/bcc/issues/748) documents this issue.
For example, if you try to attach a bpf program to tracepoints
syscalls/sys_enter_newfstat, you will get the following error:
   # ./tools/trace.py t:syscalls:sys_enter_newfstat
   Ioctl(PERF_EVENT_IOC_SET_BPF): Invalid argument
   Failed to attach BPF to tracepoint

The main reason is that syscalls/sys_enter_* and syscalls/sys_exit_*
tracepoints are treated differently from other tracepoints and there
is no bpf hook to it.

This patch adds bpf support for these syscalls tracepoints by
  . permitting bpf attachment in ioctl PERF_EVENT_IOC_SET_BPF
  . calling bpf programs in perf_syscall_enter and perf_syscall_exit

Signed-off-by: Yonghong Song 
---
 include/linux/syscalls.h  |  6 +
 kernel/events/core.c  |  8 ---
 kernel/trace/trace_syscalls.c | 53 +--
 3 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 3cb15ea..00fa3eb 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -117,6 +117,12 @@ extern struct trace_event_class event_class_syscall_exit;
 extern struct trace_event_functions enter_syscall_print_funcs;
 extern struct trace_event_functions exit_syscall_print_funcs;
 
+static inline int is_syscall_trace_event(struct trace_event_call *tp_event)
+{
+   return tp_event->class == _class_syscall_enter ||
+  tp_event->class == _class_syscall_exit;
+}
+
 #define SYSCALL_TRACE_ENTER_EVENT(sname)   \
static struct syscall_metadata __syscall_meta_##sname;  \
static struct trace_event_call __used   \
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 426c2ff..750b8d3 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8050,7 +8050,7 @@ static void perf_event_free_bpf_handler(struct perf_event 
*event)
 
 static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
 {
-   bool is_kprobe, is_tracepoint;
+   bool is_kprobe, is_tracepoint, is_syscall_tp;
struct bpf_prog *prog;
 
if (event->attr.type != PERF_TYPE_TRACEPOINT)
@@ -8061,7 +8061,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
 
is_kprobe = event->tp_event->flags & TRACE_EVENT_FL_UKPROBE;
is_tracepoint = event->tp_event->flags & TRACE_EVENT_FL_TRACEPOINT;
-   if (!is_kprobe && !is_tracepoint)
+   is_syscall_tp = is_syscall_trace_event(event->tp_event);
+   if (!is_kprobe && !is_tracepoint && !is_syscall_tp)
/* bpf programs can only be attached to u/kprobe or tracepoint 
*/
return -EINVAL;
 
@@ -8070,7 +8071,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
return PTR_ERR(prog);
 
if ((is_kprobe && prog->type != BPF_PROG_TYPE_KPROBE) ||
-   (is_tracepoint && prog->type != BPF_PROG_TYPE_TRACEPOINT)) {
+   (is_tracepoint && prog->type != BPF_PROG_TYPE_TRACEPOINT) ||
+   (is_syscall_tp && prog->type != BPF_PROG_TYPE_TRACEPOINT)) {
/* valid fd, but invalid bpf program type */
bpf_prog_put(prog);
return -EINVAL;
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 5e10395..3bd9e1c 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -559,11 +559,29 @@ static DECLARE_BITMAP(enabled_perf_exit_syscalls, 
NR_syscalls);
 static int sys_perf_refcount_enter;
 static int sys_perf_refcount_exit;
 
+static int perf_call_bpf_enter(struct bpf_prog *prog, struct pt_regs *regs,
+ struct syscall_metadata *sys_data,
+ struct syscall_trace_enter *rec) {
+   struct syscall_tp_t {
+   unsigned long long regs;
+   unsigned long syscall_nr;
+   unsigned long args[6]; /* maximum 6 arguments */
+   } param;
+   int i;
+
+   *(struct pt_regs **) = regs;
+   param.syscall_nr = rec->nr;
+   for (i = 0; i < sys_data->nb_args && i < 6; i++)
+   param.args[i] = rec->args[i];
+   return trace_call_bpf(prog, );
+}
+
 static void perf_syscall_enter(void *ignore, struct pt_regs *regs, long id)
 {
struct syscall_metadata *sys_data;
struct syscall_trace_enter *rec;
struct hlist_head *head;
+   struct bpf_prog *prog;
int syscall_nr;
int rctx;
int size;
@@ -578,8 +596,9 @@ static void perf_syscall_enter(void *ignore, struct pt_regs 
*regs, long id)
if (!sys_data)
return;
 
+   prog = READ_ONCE(sys_data->enter_event->prog);
head = this_cpu_ptr(sys_data->enter_event->perf_events);
-   if (hlist_empty(head))
+   

[PATCH net-next v2 2/2] bpf: add a test case for syscalls/sys_{enter|exit}_* tracepoints

2017-08-02 Thread Yonghong Song
Signed-off-by: Yonghong Song 
---
 samples/bpf/Makefile  |  4 +++
 samples/bpf/syscall_tp_kern.c | 62 +
 samples/bpf/syscall_tp_user.c | 71 +++
 3 files changed, 137 insertions(+)
 create mode 100644 samples/bpf/syscall_tp_kern.c
 create mode 100644 samples/bpf/syscall_tp_user.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 770d46c..f1010fe 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -39,6 +39,7 @@ hostprogs-y += per_socket_stats_example
 hostprogs-y += load_sock_ops
 hostprogs-y += xdp_redirect
 hostprogs-y += xdp_redirect_map
+hostprogs-y += syscall_tp
 
 # Libbpf dependencies
 LIBBPF := ../../tools/lib/bpf/bpf.o
@@ -82,6 +83,7 @@ test_map_in_map-objs := bpf_load.o $(LIBBPF) 
test_map_in_map_user.o
 per_socket_stats_example-objs := $(LIBBPF) cookie_uid_helper_example.o
 xdp_redirect-objs := bpf_load.o $(LIBBPF) xdp_redirect_user.o
 xdp_redirect_map-objs := bpf_load.o $(LIBBPF) xdp_redirect_map_user.o
+syscall_tp-objs := bpf_load.o $(LIBBPF) syscall_tp_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
@@ -125,6 +127,7 @@ always += tcp_iw_kern.o
 always += tcp_clamp_kern.o
 always += xdp_redirect_kern.o
 always += xdp_redirect_map_kern.o
+always += syscall_tp_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 HOSTCFLAGS += -I$(srctree)/tools/lib/
@@ -163,6 +166,7 @@ HOSTLOADLIBES_xdp_tx_iptunnel += -lelf
 HOSTLOADLIBES_test_map_in_map += -lelf
 HOSTLOADLIBES_xdp_redirect += -lelf
 HOSTLOADLIBES_xdp_redirect_map += -lelf
+HOSTLOADLIBES_syscall_tp += -lelf
 
 # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on 
cmdline:
 #  make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
CLANG=~/git/llvm/build/bin/clang
diff --git a/samples/bpf/syscall_tp_kern.c b/samples/bpf/syscall_tp_kern.c
new file mode 100644
index 000..9149c52
--- /dev/null
+++ b/samples/bpf/syscall_tp_kern.c
@@ -0,0 +1,62 @@
+/* Copyright (c) 2017 Facebook
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include "bpf_helpers.h"
+
+struct syscalls_enter_open_args {
+   unsigned long long unused;
+   long syscall_nr;
+   long filename_ptr;
+   long flags;
+   long mode;
+};
+
+struct syscalls_exit_open_args {
+   unsigned long long unused;
+   long syscall_nr;
+   long ret;
+};
+
+struct bpf_map_def SEC("maps") enter_open_map = {
+   .type = BPF_MAP_TYPE_ARRAY,
+   .key_size = sizeof(u32),
+   .value_size = sizeof(u32),
+   .max_entries = 1,
+};
+
+struct bpf_map_def SEC("maps") exit_open_map = {
+   .type = BPF_MAP_TYPE_ARRAY,
+   .key_size = sizeof(u32),
+   .value_size = sizeof(u32),
+   .max_entries = 1,
+};
+
+static __always_inline void count(void *map)
+{
+   u32 key = 0;
+   u32 *value, init_val = 1;
+
+   value = bpf_map_lookup_elem(map, );
+   if (value)
+   *value += 1;
+   else
+   bpf_map_update_elem(map, , _val, BPF_NOEXIST);
+}
+
+SEC("tracepoint/syscalls/sys_enter_open")
+int trace_enter_open(struct syscalls_enter_open_args *ctx)
+{
+   count((void *)_open_map);
+   return 0;
+}
+
+SEC("tracepoint/syscalls/sys_exit_open")
+int trace_enter_exit(struct syscalls_exit_open_args *ctx)
+{
+   count((void *)_open_map);
+   return 0;
+}
diff --git a/samples/bpf/syscall_tp_user.c b/samples/bpf/syscall_tp_user.c
new file mode 100644
index 000..a3cb91e
--- /dev/null
+++ b/samples/bpf/syscall_tp_user.c
@@ -0,0 +1,71 @@
+/* Copyright (c) 2017 Facebook
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "libbpf.h"
+#include "bpf_load.h"
+
+/* This program verifies bpf attachment to tracepoint sys_enter_* and 
sys_exit_*.
+ * This requires kernel CONFIG_FTRACE_SYSCALLS to be set.
+ */
+
+static void verify_map(int map_id)
+{
+   __u32 key = 0;
+   __u32 val;
+
+   if (bpf_map_lookup_elem(map_id, , ) != 0) {
+   fprintf(stderr, "map_lookup failed: %s\n", strerror(errno));
+   return;
+   }
+   if (val == 0)
+   fprintf(stderr, "failed: map #%d returns value 0\n", map_id);
+}
+
+int main(int argc, char **argv)
+{
+   struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
+   char filename[256];
+   int fd;
+
+   setrlimit(RLIMIT_MEMLOCK, );
+   snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
+
+   if (load_bpf_file(filename)) {
+   fprintf(stderr, "%s", bpf_log_buf);
+   return 1;
+ 

[PATCH net-next v2 0/2] bpf: add support for sys_{enter|exit}_* tracepoints

2017-08-02 Thread Yonghong Song
Currently, bpf programs cannot be attached to sys_enter_* and sys_exit_*
style tracepoints. The main reason is that syscalls/sys_enter_* and 
syscalls/sys_exit_*
tracepoints are treated differently from other tracepoints and there
is no bpf hook to it.

This patch set adds bpf support for these syscalls tracepoints and also
adds a test case for it.

Changes from v1:
 - Do not use TRACE_EVENT_FL_CAP_ANY to identify syscall tracepoint.
   Instead use trace_event_call->class.

Yonghong Song (2):
  bpf: add support for sys_enter_* and sys_exit_* tracepoints
  bpf: add a test case for syscalls/sys_{enter|exit}_* tracepoints

 include/linux/syscalls.h  |  6 
 kernel/events/core.c  |  8 +++--
 kernel/trace/trace_syscalls.c | 53 ++--
 samples/bpf/Makefile  |  4 +++
 samples/bpf/syscall_tp_kern.c | 62 +
 samples/bpf/syscall_tp_user.c | 71 +++
 6 files changed, 199 insertions(+), 5 deletions(-)
 create mode 100644 samples/bpf/syscall_tp_kern.c
 create mode 100644 samples/bpf/syscall_tp_user.c

-- 
2.9.4



Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

2017-08-02 Thread Kalle Valo
"Luis R. Rodriguez"  writes:

>> +int request_firmware_nowait(struct module *module, bool uevent,
>> +const char *name, struct device *device, gfp_t gfp,
>> +void *context,
>> +void (*cont)(const struct firmware *fw, void 
>> *context))
>> +{
>> +unsigned int opt_flags = FW_OPT_FALLBACK |
>> +(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
>> +
>> +return __request_firmware_nowait(module, opt_flags, name, device, gfp,
>> + context, cont);
>> +}
>>  EXPORT_SYMBOL(request_firmware_nowait);
>>  
>> +int __request_firmware_async(struct module *module, const char *name,
>> + struct firmware_opts *fw_opts, struct device *dev,
>> + void *context,
>> + void (*cont)(const struct firmware *fw, void 
>> *context))
>> +{
>> +unsigned int opt_flags = FW_OPT_UEVENT;
>
> This exposes a long issue. Think -- why do we want this enabled by default? 
> Its
> actually because even though the fallback stuff is optional and can be, the 
> uevent
> internal flag *also* provides caching support as a side consequence only. We
> don't want to add a new API without first cleaning up that mess.
>
> This is a slipery slope and best to clean that up before adding any new API.
>
> That and also Greg recently stated he would like to see at least 3 users of
> a feature before adding it. Although I think that's pretty arbitrary, and
> considering that request_firmware_into_buf() only has *one* user -- its what
> he wishes.

ath10k at least needs a way to silence the warning for missing firmware
and I think iwlwifi also.

-- 
Kalle Valo


Re: [PATCH 2/2] qlcnic: add const to bin_attribute structure

2017-08-02 Thread Patil, Harish
-Original Message-
From: Bhumika Goyal 
Date: Wednesday, August 2, 2017 at 11:27 PM
To: "julia.law...@lip6.fr" , "kv...@codeaurora.org"
, "linux-wirel...@vger.kernel.org"
, "netdev@vger.kernel.org"
, "linux-ker...@vger.kernel.org"
, Harish Patil ,
"Chopra, Manish" , Dept-GE Linux NIC Dev

Cc: Bhumika Goyal 
Subject: [PATCH 2/2] qlcnic: add const to bin_attribute structure

>Add const to bin_attribute structure as it is only passed to the
>functions sysfs_{remove/create}_bin_file. The corresponding
>arguments are of type const, so declare the structure to be const.
>
>Signed-off-by: Bhumika Goyal 
>---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
>b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
>index 73027a6..82fcb83 100644
>--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
>+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
>@@ -1248,7 +1248,7 @@ static ssize_t
>qlcnic_83xx_sysfs_flash_write_handler(struct file *filp,
>   .write = qlcnic_sysfs_write_pm_config,
> };
> 
>-static struct bin_attribute bin_attr_flash = {
>+static const struct bin_attribute bin_attr_flash = {
>   .attr = {.name = "flash", .mode = (S_IRUGO | S_IWUSR)},
>   .size = 0,
>   .read = qlcnic_83xx_sysfs_flash_read_handler,
>-- 
>1.9.1
>
>Acked-by: Harish Patil 



Re: [PATCH net-next 4/4] ibmvnic: Implement .get_channels

2017-08-02 Thread Stephen Hemminger
On Wed, 2 Aug 2017 16:47:17 -0500
John Allen  wrote:

> +static void ibmvnic_get_channels(struct net_device *netdev,
> +  struct ethtool_channels *channels)
> +{
> + struct ibmvnic_adapter *adapter = netdev_priv(netdev);
> +
> + channels->max_rx = adapter->max_rx_queues;
> + channels->max_tx = adapter->max_tx_queues;
> + channels->max_other = 0;
> + channels->max_combined = 0;
> + channels->rx_count = adapter->req_rx_queues;
> + channels->tx_count = adapter->req_tx_queues;
> + channels->other_count = 0;
> + channels->combined_count = 0;
> +}

Minor nit, since the structure is already initialized to zero by caller,
you don't need to fill in the values that are zero.

static noinline_for_stack int ethtool_get_channels(struct net_device *dev,
   void __user *useraddr)
{
struct ethtool_channels channels = { .cmd = ETHTOOL_GCHANNELS };  << 
all unspecifed fields are zero'd

if (!dev->ethtool_ops->get_channels)
return -EOPNOTSUPP;

dev->ethtool_ops->get_channels(dev, );


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

2017-08-02 Thread Stephen Hemminger
On Thu, 3 Aug 2017 12:01:37 +1000
Stephen Rothwell  wrote:

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/hyperv/netvsc.c
> 
> between commit:
> 
>   4a0dee1ffe0e ("netvsc: Initialize 64-bit stats seqcount")
> 
> from the net tree and commit:
> 
>   35fbbccfb417 ("netvsc: save pointer to parent netvsc_device in channel 
> table")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks, that looks right.


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

2017-08-02 Thread Stephen Rothwell
Hi all,

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

  drivers/net/hyperv/netvsc.c

between commit:

  4a0dee1ffe0e ("netvsc: Initialize 64-bit stats seqcount")

from the net tree and commit:

  35fbbccfb417 ("netvsc: save pointer to parent netvsc_device in channel table")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/hyperv/netvsc.c
index 96f90c75d1b7,9598220b3bcc..
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@@ -1302,8 -1269,7 +1269,9 @@@ struct netvsc_device *netvsc_device_add
struct netvsc_channel *nvchan = _device->chan_table[i];
  
nvchan->channel = device->channel;
+   nvchan->net_device = net_device;
 +  u64_stats_init(>tx_stats.syncp);
 +  u64_stats_init(>rx_stats.syncp);
}
  
/* Enable NAPI handler before init callbacks */


Re: [PATCH V4 net 2/2] net: fix tcp reset packet flowlabel for ipv6

2017-08-02 Thread Cong Wang
On Tue, Aug 1, 2017 at 2:42 PM, Shaohua Li  wrote:
> Is this really better? I don't see any point. I'd use my original patch other
> than this one. that said, there are just several lines of code, brutally
> 'abstract' them into a function doesn't make the code better.

The current ip6_make_flowlabel() is already a mess, with your
change you just make it worse to read. I just want to make it suck
less.


[PATCH] wcn36xx: Introduce mutual exclusion of fw configuration

2017-08-02 Thread Bjorn Andersson
As the association status changes the driver needs to configure the
hardware. This is done based on information in the "sta" acquired by
ieee80211_find_sta(), which requires the caller to ensure that the "sta"
is valid while its being used; generally by entering an rcu read
section.

But the operations acting on the "sta" has to communicate with the
firmware and may therefor sleep, resulting in the following report:

[   31.418190] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:238
[   31.425919] in_atomic(): 0, irqs_disabled(): 0, pid: 34, name:
kworker/u8:1
[   31.434609] CPU: 0 PID: 34 Comm: kworker/u8:1 Tainted: GW
4.12.0-rc4-next-20170607+ #993
[   31.441002] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC
(DT)
[   31.450380] Workqueue: phy0 ieee80211_iface_work
[   31.457226] Call trace:
[   31.461830] [] dump_backtrace+0x0/0x260
[   31.464004] [] show_stack+0x14/0x20
[   31.469557] [] dump_stack+0x98/0xb8
[   31.474592] [] ___might_sleep+0xf0/0x118
[   31.479626] [] __might_sleep+0x50/0x88
[   31.485010] [] mutex_lock+0x24/0x60
[   31.490479] [] wcn36xx_smd_set_link_st+0x30/0x130
[   31.495428] [] wcn36xx_bss_info_changed+0x148/0x448
[   31.501504] []
ieee80211_bss_info_change_notify+0xbc/0x118
[   31.508102] [] ieee80211_assoc_success+0x664/0x7f8
[   31.515220] []
ieee80211_rx_mgmt_assoc_resp+0x144/0x2d8
[   31.521555] []
ieee80211_sta_rx_queued_mgmt+0x190/0x698
[   31.528239] [] ieee80211_iface_work+0x234/0x368
[   31.535011] [] process_one_work+0x1cc/0x340
[   31.541086] [] worker_thread+0x48/0x430
[   31.546814] [] kthread+0x108/0x138
[   31.552195] [] ret_from_fork+0x10/0x50

In order to ensure that the "sta" remains alive (and consistent) for the
duration of bss_info_changed() mutual exclusion has to be ensured with
sta_remove().

This is done by introducing a mutex to cover firmware configuration
changes, which is made to also ensure mutual exclusion between other
operations changing the state or configuration of the firmware. With
this we can drop the rcu read lock.

Cc: sta...@vger.kernel.org
Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/main.c| 52 --
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  3 ++
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index d5e993dc9b23..6b6fa8e01f0e 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -372,6 +372,8 @@ static int wcn36xx_config(struct ieee80211_hw *hw, u32 
changed)
 
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac config changed 0x%08x\n", changed);
 
+   mutex_lock(>conf_mutex);
+
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
int ch = WCN36XX_HW_CHANNEL(wcn);
wcn36xx_dbg(WCN36XX_DBG_MAC, "wcn36xx_config channel 
switch=%d\n",
@@ -382,6 +384,8 @@ static int wcn36xx_config(struct ieee80211_hw *hw, u32 
changed)
}
}
 
+   mutex_unlock(>conf_mutex);
+
return 0;
 }
 
@@ -396,6 +400,8 @@ static void wcn36xx_configure_filter(struct ieee80211_hw 
*hw,
 
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac configure filter\n");
 
+   mutex_lock(>conf_mutex);
+
*total &= FIF_ALLMULTI;
 
fp = (void *)(unsigned long)multicast;
@@ -408,6 +414,8 @@ static void wcn36xx_configure_filter(struct ieee80211_hw 
*hw,
else if (NL80211_IFTYPE_STATION == vif->type && tmp->sta_assoc)
wcn36xx_smd_set_mc_list(wcn, vif, fp);
}
+
+   mutex_unlock(>conf_mutex);
kfree(fp);
 }
 
@@ -471,6 +479,8 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
 key_conf->key,
 key_conf->keylen);
 
+   mutex_lock(>conf_mutex);
+
switch (key_conf->cipher) {
case WLAN_CIPHER_SUITE_WEP40:
vif_priv->encrypt_type = WCN36XX_HAL_ED_WEP40;
@@ -565,6 +575,8 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
}
 
 out:
+   mutex_unlock(>conf_mutex);
+
return ret;
 }
 
@@ -725,6 +737,8 @@ static void wcn36xx_bss_info_changed(struct ieee80211_hw 
*hw,
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac bss info changed vif %p changed 
0x%08x\n",
vif, changed);
 
+   mutex_lock(>conf_mutex);
+
if (changed & BSS_CHANGED_BEACON_INFO) {
wcn36xx_dbg(WCN36XX_DBG_MAC,
"mac bss changed dtim period %d\n",
@@ -787,7 +801,13 @@ static void wcn36xx_bss_info_changed(struct ieee80211_hw 
*hw,
 bss_conf->aid);
 
vif_priv->sta_assoc = true;
-   rcu_read_lock();
+
+   /*
+* Holding conf_mutex ensures mutal exclusion with
+* 

Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread Timur Tabi

On 8/2/17 6:15 PM, David Miller wrote:


So you don't want to run a proper watchdog on your systems?
You want them to just hang there and wait for someone to
notice instead?


This is for internal development.  We noticed the problem first during 
debugging, when we would halt a core for more than a couple minutes. 
Then the entire lab network would go down.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.


[PATCH v3 4/4] can: m_can: Add call to of_can_transceiver_fixed

2017-08-02 Thread Franklin S Cooper Jr
Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/net/can/m_can/m_can.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f4947a7..bd75df1 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1649,6 +1649,8 @@ static int m_can_plat_probe(struct platform_device *pdev)
 
devm_can_led_init(dev);
 
+   of_can_transceiver_fixed(dev);
+
dev_info(>dev, "%s device registered (irq=%d, version=%d)\n",
 KBUILD_MODNAME, dev->irq, priv->version);
 
-- 
2.9.4.dirty



[PATCH v3 1/4] can: dev: Add support for limiting configured bitrate

2017-08-02 Thread Franklin S Cooper Jr
Various CAN or CAN-FD IP may be able to run at a faster rate than
what the transceiver the CAN node is connected to. This can lead to
unexpected errors. However, CAN transceivers typically have fixed
limitations and provide no means to discover these limitations at
runtime. Therefore, add support for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/net/can/dev.c   | 50 +
 include/linux/can/dev.h |  5 +
 2 files changed, 55 insertions(+)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 365a8cc..db56914 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MOD_DESC "CAN device driver interface"
@@ -814,6 +815,39 @@ int open_candev(struct net_device *dev)
 }
 EXPORT_SYMBOL_GPL(open_candev);
 
+#ifdef CONFIG_OF
+/*
+ * Common function that can be used to understand the limitation of
+ * a transceiver when it provides no means to determine these limitations
+ * at runtime.
+ */
+void of_can_transceiver_fixed(struct net_device *dev)
+{
+   struct device_node *dn;
+   struct can_priv *priv = netdev_priv(dev);
+   struct device_node *np;
+   unsigned int max_bitrate;
+   int ret;
+
+   np = dev->dev.parent->of_node;
+
+   dn = of_get_child_by_name(np, "fixed-transceiver");
+   if (!dn)
+   return;
+
+   max_bitrate = 0;
+   ret = of_property_read_u32(dn, "max-bitrate", _bitrate);
+
+   if (max_bitrate > 0) {
+   priv->max_bitrate = max_bitrate;
+   priv->is_bitrate_limited = true;
+   } else if (ret != -EINVAL) {
+   netdev_warn(dev, "Invalid value for transceiver max bitrate\n");
+   }
+}
+EXPORT_SYMBOL(of_can_transceiver_fixed);
+#endif
+
 /*
  * Common close function for cleanup before the device gets closed.
  *
@@ -913,6 +947,14 @@ static int can_changelink(struct net_device *dev, struct 
nlattr *tb[],
priv->bitrate_const_cnt);
if (err)
return err;
+
+   if (priv->is_bitrate_limited &&
+   bt.bitrate > priv->max_bitrate) {
+   netdev_err(dev, "arbitration bitrate surpasses 
transceiver capabilities of %d bps\n",
+  priv->max_bitrate);
+   return -EINVAL;
+   }
+
memcpy(>bittiming, , sizeof(bt));
 
if (priv->do_set_bittiming) {
@@ -997,6 +1039,14 @@ static int can_changelink(struct net_device *dev, struct 
nlattr *tb[],
priv->data_bitrate_const_cnt);
if (err)
return err;
+
+   if (priv->is_bitrate_limited &&
+   dbt.bitrate > priv->max_bitrate) {
+   netdev_err(dev, "canfd data bitrate surpasses 
transceiver capabilities of %d bps\n",
+  priv->max_bitrate);
+   return -EINVAL;
+   }
+
memcpy(>data_bittiming, , sizeof(dbt));
 
if (priv->do_set_data_bittiming) {
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 141b05a..a6e62df 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -47,6 +47,9 @@ struct can_priv {
unsigned int data_bitrate_const_cnt;
struct can_clock clock;
 
+   unsigned int max_bitrate;
+   bool is_bitrate_limited;
+
enum can_state state;
 
/* CAN controller features - see include/uapi/linux/can/netlink.h */
@@ -165,6 +168,8 @@ void can_put_echo_skb(struct sk_buff *skb, struct 
net_device *dev,
 unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx);
 void can_free_echo_skb(struct net_device *dev, unsigned int idx);
 
+void of_can_transceiver_fixed(struct net_device *dev);
+
 struct sk_buff *alloc_can_skb(struct net_device *dev, struct can_frame **cf);
 struct sk_buff *alloc_canfd_skb(struct net_device *dev,
struct canfd_frame **cfd);
-- 
2.9.4.dirty



[PATCH v3 3/4] dt-bindings: can: m_can: Include reference to new fixed transceiver binding

2017-08-02 Thread Franklin S Cooper Jr
Add information regarding fixed transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.

Signed-off-by: Franklin S Cooper Jr 
---
 Documentation/devicetree/bindings/net/can/m_can.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt 
b/Documentation/devicetree/bindings/net/can/m_can.txt
index 9e33177..0b62f47 100644
--- a/Documentation/devicetree/bindings/net/can/m_can.txt
+++ b/Documentation/devicetree/bindings/net/can/m_can.txt
@@ -43,6 +43,11 @@ Required properties:
  Please refer to 2.4.1 Message RAM Configuration in
  Bosch M_CAN user manual for details.
 
+Optional properties:
+- fixed-transceiver: Fixed-transceiver subnode describing maximum speed
+ that can be used for CAN/CAN-FD modes. See
+ 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
+ for details.
 Example:
 SoC dtsi:
 m_can1: can@020e8000 {
@@ -64,4 +69,8 @@ Board dts:
pinctrl-names = "default";
pinctrl-0 = <_m_can1>;
status = "enabled";
+
+   fixed-transceiver@0 {
+   max-bitrate = <500>;
+   };
 };
-- 
2.9.4.dirty



[PATCH v3 0/4] can: Support transceiver based bit rate limit

2017-08-02 Thread Franklin S Cooper Jr
Add a new generic binding that CAN drivers can be used to specify the max
bit rate supported by a transceiver. This is useful since in some instances
since the maximum speeds may be limited by the transceiver used. However,
transceivers may not provide a means to determine this limitation at
runtime. Therefore, create a new binding that mimics "fixed-link" that
allows a user to hardcode the max speeds that can be used.

Also add support for this new binding in the MCAN driver.

Note this is an optional subnode so even if a driver adds support for
parsing fixed-transceiver the user does not have to define it in their
device tree.

Version 3 changes:
Switch from having two "max bitrates" to one universal bitrate.

Version 2 changes:
Rename function
Define proper variable default
Drop unit address
Move check to changelink function
Reword commit message
Reword documentation

Franklin S Cooper Jr (4):
  can: dev: Add support for limiting configured bitrate
  dt-bindings: can: fixed-transceiver: Add new CAN fixed transceiver
bindings
  dt-bindings: can: m_can: Include reference to new fixed transceiver
binding
  can: m_can: Add call to of_can_transceiver_fixed

 .../bindings/net/can/fixed-transceiver.txt | 24 +++
 .../devicetree/bindings/net/can/m_can.txt  |  9 
 drivers/net/can/dev.c  | 50 ++
 drivers/net/can/m_can/m_can.c  |  2 +
 include/linux/can/dev.h|  5 +++
 5 files changed, 90 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt

-- 
2.9.4.dirty



[PATCH v3 2/4] dt-bindings: can: fixed-transceiver: Add new CAN fixed transceiver bindings

2017-08-02 Thread Franklin S Cooper Jr
Add documentation to describe usage of the new fixed transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.

Signed-off-by: Franklin S Cooper Jr 
---
 .../bindings/net/can/fixed-transceiver.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt

diff --git a/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt 
b/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
new file mode 100644
index 000..2f58838b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
@@ -0,0 +1,24 @@
+Fixed transceiver Device Tree binding
+--
+
+CAN transceiver typically limits the max speed in standard CAN and CAN FD
+modes. Typically these limitations are static and the transceivers themselves
+provide no way to detect this limitation at runtime. For this situation,
+the "fixed-transceiver" node can be used.
+
+Required Properties:
+ max-bitrate:  a positive non 0 value that determines the max
+   speed that CAN/CAN-FD can run. Any other value
+   will be ignored.
+
+Examples:
+
+Based on Texas Instrument's TCAN1042HGV CAN Transceiver
+
+m_can0 {
+   
+   fixed-transceiver@0 {
+   max-bitrate = <500>;
+   };
+   ...
+};
-- 
2.9.4.dirty



Re: [patch net-next 0/6] ipv4: fib: Provide per-nexthop offload indication

2017-08-02 Thread David Miller
From: Jiri Pirko 
Date: Wed,  2 Aug 2017 09:56:00 +0200

> From: Jiri Pirko 
> 
> Ido says:
> 
> Offload indication for IPv4 routes is currently set in the FIB info's
> flags. When multipath routes are employed, this can lead to a route being
> marked as offloaded although only one of its nexthops is actually
> offloaded.
> 
> Instead, this patchset aims to proivde a higher resolution for the offload
> indication and report it on a per-nexthop basis.
> 
> Example output from patched iproute:
> 
> $ ip route show 192.168.200.0/24
> 192.168.200.0/24
> nexthop via 192.168.100.2 dev enp3s0np7 weight 1 offload
> nexthop via 192.168.101.3 dev enp3s0np8 weight 1
> 
> And once the second gateway is resolved:
> 
> $ ip route show 192.168.200.0/24
> 192.168.200.0/24
> nexthop via 192.168.100.2 dev enp3s0np7 weight 1 offload
> nexthop via 192.168.101.3 dev enp3s0np8 weight 1 offload
> 
> First patch teaches the kernel to look for the offload indication in the
> nexthop flags. Patches 2-5 adjust current capable drivers to provide
> offload indication on a per-nexthop basis. Last patch removes no longer
> used functions to set offload indication in the FIB info's flags.

Series applied, thanks Jiri.


Re: [patch net-next] mlxsw: core: Use correct EMAD transaction ID in debug message

2017-08-02 Thread David Miller
From: Jiri Pirko 
Date: Wed,  2 Aug 2017 09:52:10 +0200

> From: Ido Schimmel 
> 
> 'trans->tid' is only assigned later in the function, resulting in a zero
> transaction ID. Use 'tid' instead.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 

Applied, thanks Jiri.


Re: [PATCH net-next v3 0/3] netvsc: transparent VF support

2017-08-02 Thread David Miller
From: Stephen Hemminger 
Date: Tue,  1 Aug 2017 19:58:52 -0700

> This patch set changes how SR-IOV Virtual Function devices are managed
> in the Hyper-V network driver. This version is rebased onto current net-next.
 ...

Series applied, thanks Stephen.


Re: [PATCH 1/2] atm: adummy: constify attribute_group structure

2017-08-02 Thread David Miller
From: Amitoj Kaur Chawla 
Date: Tue, 1 Aug 2017 19:57:38 -0400

> Functions working with attribute_groups provided by 
> work with const attribute_group. These attribute_group structures do not
> change at runtime so mark them as const.
> 
> File size before:
>  text  data bss dec hex filename
>  2033  1448   03481 d99 drivers/atm/adummy.o
> 
> File size after:
>  text  data bss dec hex filename
>  2129  1352   03481 d99 drivers/atm/adummy.o
> 
> This change was made with the help of Coccinelle.
> 
> Signed-off-by: Amitoj Kaur Chawla 

Applied.


Re: [PATCH 2/2] atm: solos-pci: constify attribute_group structures

2017-08-02 Thread David Miller
From: Amitoj Kaur Chawla 
Date: Tue, 1 Aug 2017 19:57:47 -0400

> Functions working with attribute_groups provided by 
> work with const attribute_group. These attribute_group structures do not
> change at runtime so mark them as const.
> 
> File size before:
>  text  data bss dec hex filename
>  3574028424 832   64996fde4 drivers/atm/solos-pci.o
> 
> File size after:
>  text  data bss dec hex filename
>  3593228232 832   64996fde4 drivers/atm/solos-pci.o
> 
> This change was made with the help of Coccinelle.
> 
> Signed-off-by: Amitoj Kaur Chawla 

Applied.


Re: [PATCH net-next] liquidio: set sriov_totalvfs correctly

2017-08-02 Thread David Miller
From: Felix Manlunas 
Date: Tue, 1 Aug 2017 15:05:07 -0700

> From: Derek Chickles 
> 
> The file /sys/devices/pci000.../sriov_totalvfs is showing a wrong value.
> Fix it by calling pci_sriov_set_totalvfs() to set the total number of VFs
> available after calculations for the number of PF and VF queues are made.
> 
> Signed-off-by: Derek Chickles 
> Signed-off-by: Raghu Vatsavayi 
> Signed-off-by: Felix Manlunas 

Applied, thanks.


Re: [PATCH net-next] net: dsa: Add support for 64-bit statistics

2017-08-02 Thread David Miller
From: Florian Fainelli 
Date: Tue,  1 Aug 2017 15:00:36 -0700

> DSA slave network devices maintain a pair of bytes and packets counters
> for each directions, but these are not 64-bit capable. Re-use
> pcpu_sw_netstats which contains exactly what we need for that purpose
> and update the code path to report 64-bit capable statistics.
> 
> Signed-off-by: Florian Fainelli 

Applied, thanks.

I would run ethtool -S and ifconfig under perf to see where it is
spending so much time.


Re: [patch net-next 4/6] mlxsw: spectrum_router: Don't check state when refreshing offload indication

2017-08-02 Thread David Ahern
On 8/2/17 1:56 AM, Jiri Pirko wrote:
> From: Ido Schimmel 
> 
> Previous patch removed the reliance on the counter in the FIB info to
> set the offload indication, so we no longer need to keep an offload
> state on each FIB entry and can just set or unset the RTNH_F_OFFLOAD
> flag in each nexthop.
> 
> This is also necessary because we're going to need to refresh the
> offload indication whenever the nexthop group associated with the FIB
> entry is refreshed. Current check would prevent us from marking a newly
> resolved nexthop as offloaded if the FIB entry is already marked as
> offloaded.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 
> ---
>  drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)

Tested-by: David Ahern 


Re: [patch net-next 3/6] mlxsw: spectrum_router: Provide offload indication using nexthop flags

2017-08-02 Thread David Ahern
On 8/2/17 1:56 AM, Jiri Pirko wrote:
> From: Ido Schimmel 
> 
> In a similar fashion to previous patch, use the nexthop flags to provide
> offload indication instead of the FIB info's flags.
> 
> In case a nexthop in a multipath route can't be offloaded (gateway's MAC
> can't be resolved, for example), then its offload flag isn't set.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 
> ---
>  .../net/ethernet/mellanox/mlxsw/spectrum_router.c  | 38 
> --
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
>

Tested-by: David Ahern 


Re: [patch net-next 5/6] mlxsw: spectrum_router: Refresh offload indication upon group refresh

2017-08-02 Thread David Ahern
On 8/2/17 1:56 AM, Jiri Pirko wrote:
> From: Ido Schimmel 
> 
> Now that we provide offload indication using the nexthop's flags we must
> refresh the offload indication whenever the offload state within the
> group changes.
> 
> This didn't matter until now, as offload indication was provided using
> the FIB info flags and multipath routes were marked as offloaded as long
> as one of the nexthops was offloaded.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 
> ---
>  .../net/ethernet/mellanox/mlxsw/spectrum_router.c  | 22 
> ++
>  1 file changed, 22 insertions(+)
> 

Tested-by: David Ahern 


Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread David Miller
From: Timur Tabi 
Date: Wed, 2 Aug 2017 13:39:34 -0500

> On 08/02/2017 01:35 PM, David Miller wrote:
>> Again, any serious installation will have a system watchdog enabled
>> which will break the pause frame bomb.
> 
> Oh well.  I guess I'll have to carry this patch internally.

So you don't want to run a proper watchdog on your systems?
You want them to just hang there and wait for someone to
notice instead?

> What about patch #2?

No real objection.


Re: [patch net-next 6/6] ipv4: fib: Remove unused functions

2017-08-02 Thread David Ahern
On 8/2/17 1:56 AM, Jiri Pirko wrote:
> From: Ido Schimmel 
> 
> Previous patches converted users of these functions to provide offload
> indication using the nexthop's flags instead of the FIB info's.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 
> ---
>  include/net/ip_fib.h | 13 -
>  1 file changed, 13 deletions(-)
> 

Acked-by: David Ahern 


Re: [patch net-next 1/6] ipv4: fib: Set offload indication according to nexthop flags

2017-08-02 Thread David Ahern
On 8/2/17 1:56 AM, Jiri Pirko wrote:
> From: Ido Schimmel 
> 
> We're going to have capable drivers indicate route offload using the
> nexthop flags, but for non-multipath routes these flags aren't dumped to
> user space.
> 
> Instead, set the offload indication in the route message flags.
> 
> Signed-off-by: Ido Schimmel 
> Signed-off-by: Jiri Pirko 
> ---
>  net/ipv4/fib_semantics.c | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: David Ahern 


Re: sysctl, argument parsing, possible bug

2017-08-02 Thread Luis R. Rodriguez
On Tue, Aug 01, 2017 at 02:54:51PM -0700, Cong Wang wrote:
> On Tue, Aug 1, 2017 at 2:34 PM, Massimo Sala  
> wrote:
> > Do you confirm it is a sysctl parsing bug ?
> >
> > Bosybox handles these cases, so I think also standalone sysctl have to.
> >
> > Or at least someone must update sysctl docs / MAN about this.
> >
> 
> Maybe, sysctl seems (I never look into it) just to interpret dot as
> a separator, unless it reads from the /proc/sys/ directory, it can
> not know eth0.100 is actually a netdev name.

Using echo or sysctl -w works for me, try upgrading your procps,
I have procps-3.3.12. Busybox sysctl fails though, so it would
seems this is an issue with busybox, go fix that.

With procps-3.3.12.:

Setting:

ergon:~ # cat /proc/sys/net/ipv4/conf/eth0.100/forwarding 
1

ergon:~ # sysctl -w net.ipv4.conf.eth0/100.forwarding=0
net.ipv4.conf.eth0/100.forwarding = 0

ergon:~ # cat /proc/sys/net/ipv4/conf/eth0.100/forwarding 
0

Querying:

ergon:~ # sysctl net.ipv4.conf.eth0/100.forwarding
net.ipv4.conf.eth0/100.forwarding = 0

With busybox:

ergon:~ # busybox-static sysctl net.ipv4.conf.eth0/100.forwarding
sysctl: error: 'net.ipv4.conf.eth0.100.forwarding' is an unknown key

  Luis


[PATCH net-next 4/4] ibmvnic: Implement .get_channels

2017-08-02 Thread John Allen
Implement .get_channels (ethtool -l) functionality

Signed-off-by: John Allen 
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 1cc5db94e40f..130aee7b5c32 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1741,6 +1741,21 @@ static void ibmvnic_get_ringparam(struct net_device 
*netdev,
ring->rx_jumbo_pending = 0;
 }

+static void ibmvnic_get_channels(struct net_device *netdev,
+struct ethtool_channels *channels)
+{
+   struct ibmvnic_adapter *adapter = netdev_priv(netdev);
+
+   channels->max_rx = adapter->max_rx_queues;
+   channels->max_tx = adapter->max_tx_queues;
+   channels->max_other = 0;
+   channels->max_combined = 0;
+   channels->rx_count = adapter->req_rx_queues;
+   channels->tx_count = adapter->req_tx_queues;
+   channels->other_count = 0;
+   channels->combined_count = 0;
+}
+
 static void ibmvnic_get_strings(struct net_device *dev, u32 stringset, u8 
*data)
 {
struct ibmvnic_adapter *adapter = netdev_priv(dev);
@@ -1837,6 +1852,7 @@ static const struct ethtool_ops ibmvnic_ethtool_ops = {
.set_msglevel   = ibmvnic_set_msglevel,
.get_link   = ibmvnic_get_link,
.get_ringparam  = ibmvnic_get_ringparam,
+   .get_channels   = ibmvnic_get_channels,
.get_strings= ibmvnic_get_strings,
.get_sset_count = ibmvnic_get_sset_count,
.get_ethtool_stats  = ibmvnic_get_ethtool_stats,



[PATCH net-next 3/4] ibmvnic: Implement .get_ringparam

2017-08-02 Thread John Allen
Implement .get_ringparam (ethtool -g) functionality

Signed-off-by: John Allen 
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 285ea23bac6a..1cc5db94e40f 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1729,12 +1729,14 @@ static u32 ibmvnic_get_link(struct net_device *netdev)
 static void ibmvnic_get_ringparam(struct net_device *netdev,
  struct ethtool_ringparam *ring)
 {
-   ring->rx_max_pending = 0;
-   ring->tx_max_pending = 0;
+   struct ibmvnic_adapter *adapter = netdev_priv(netdev);
+
+   ring->rx_max_pending = adapter->max_rx_add_entries_per_subcrq;
+   ring->tx_max_pending = adapter->max_tx_entries_per_subcrq;
ring->rx_mini_max_pending = 0;
ring->rx_jumbo_max_pending = 0;
-   ring->rx_pending = 0;
-   ring->tx_pending = 0;
+   ring->rx_pending = adapter->req_rx_add_entries_per_subcrq;
+   ring->tx_pending = adapter->req_tx_entries_per_subcrq;
ring->rx_mini_pending = 0;
ring->rx_jumbo_pending = 0;
 }



[PATCH net-next 2/4] ibmvnic: Convert vnic server reported statistics to cpu endian

2017-08-02 Thread John Allen
The vnic server reports the statistics buffer in big endian format and must
be converted to cpu endian in order to be displayed correctly on little
endian lpars.

Signed-off-by: John Allen 
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index a264c6992328..285ea23bac6a 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1807,7 +1807,8 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
wait_for_completion(>stats_done);

for (i = 0; i < ARRAY_SIZE(ibmvnic_stats); i++)
-   data[i] = IBMVNIC_GET_STAT(adapter, ibmvnic_stats[i].offset);
+   data[i] = be64_to_cpu(IBMVNIC_GET_STAT(adapter,
+   ibmvnic_stats[i].offset));

for (j = 0; j < adapter->req_tx_queues; j++) {
data[i] = adapter->tx_stats_buffers[j].packets;



[PATCH net-next 1/4] ibmvnic: Implement per-queue statistics reporting

2017-08-02 Thread John Allen
Add counters to report number of packets, bytes, and dropped packets for
each transmit queue and number of packets, bytes, and interrupts for each
receive queue. Modify ethtool callbacks to report the new statistics.

Signed-off-by: John Allen 
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index a3e694679635..a264c6992328 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -346,6 +346,31 @@ static void replenish_pools(struct ibmvnic_adapter 
*adapter)
}
 }

+static void release_stats_buffers(struct ibmvnic_adapter *adapter)
+{
+   kfree(adapter->tx_stats_buffers);
+   kfree(adapter->rx_stats_buffers);
+}
+
+static int init_stats_buffers(struct ibmvnic_adapter *adapter)
+{
+   adapter->tx_stats_buffers =
+   kcalloc(adapter->req_tx_queues,
+   sizeof(struct ibmvnic_tx_queue_stats),
+   GFP_KERNEL);
+   if (!adapter->tx_stats_buffers)
+   return -ENOMEM;
+
+   adapter->rx_stats_buffers =
+   kcalloc(adapter->req_rx_queues,
+   sizeof(struct ibmvnic_rx_queue_stats),
+   GFP_KERNEL);
+   if (!adapter->rx_stats_buffers)
+   return -ENOMEM;
+
+   return 0;
+}
+
 static void release_stats_token(struct ibmvnic_adapter *adapter)
 {
struct device *dev = >vdev->dev;
@@ -686,6 +711,7 @@ static void release_resources(struct ibmvnic_adapter 
*adapter)
release_rx_pools(adapter);

release_stats_token(adapter);
+   release_stats_buffers(adapter);
release_error_buffers(adapter);

if (adapter->napi) {
@@ -763,6 +789,10 @@ static int init_resources(struct ibmvnic_adapter *adapter)
if (rc)
return rc;

+   rc = init_stats_buffers(adapter);
+   if (rc)
+   return rc;
+
rc = init_stats_token(adapter);
if (rc)
return rc;
@@ -1245,6 +1275,9 @@ static int ibmvnic_xmit(struct sk_buff *skb, struct 
net_device *netdev)
netdev->stats.tx_packets += tx_packets;
adapter->tx_send_failed += tx_send_failed;
adapter->tx_map_failed += tx_map_failed;
+   adapter->tx_stats_buffers[queue_num].packets += tx_packets;
+   adapter->tx_stats_buffers[queue_num].bytes += tx_bytes;
+   adapter->tx_stats_buffers[queue_num].dropped_packets += tx_dropped;

return ret;
 }
@@ -1585,6 +1618,8 @@ static int ibmvnic_poll(struct napi_struct *napi, int 
budget)
napi_gro_receive(napi, skb); /* send it up */
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += length;
+   adapter->rx_stats_buffers[scrq_num].packets++;
+   adapter->rx_stats_buffers[scrq_num].bytes += length;
frames_processed++;
}

@@ -1706,6 +1741,7 @@ static void ibmvnic_get_ringparam(struct net_device 
*netdev,

 static void ibmvnic_get_strings(struct net_device *dev, u32 stringset, u8 
*data)
 {
+   struct ibmvnic_adapter *adapter = netdev_priv(dev);
int i;

if (stringset != ETH_SS_STATS)
@@ -1713,13 +1749,39 @@ static void ibmvnic_get_strings(struct net_device *dev, 
u32 stringset, u8 *data)

for (i = 0; i < ARRAY_SIZE(ibmvnic_stats); i++, data += ETH_GSTRING_LEN)
memcpy(data, ibmvnic_stats[i].name, ETH_GSTRING_LEN);
+
+   for (i = 0; i < adapter->req_tx_queues; i++) {
+   snprintf(data, ETH_GSTRING_LEN, "tx%d_packets", i);
+   data += ETH_GSTRING_LEN;
+
+   snprintf(data, ETH_GSTRING_LEN, "tx%d_bytes", i);
+   data += ETH_GSTRING_LEN;
+
+   snprintf(data, ETH_GSTRING_LEN, "tx%d_dropped_packets", i);
+   data += ETH_GSTRING_LEN;
+   }
+
+   for (i = 0; i < adapter->req_rx_queues; i++) {
+   snprintf(data, ETH_GSTRING_LEN, "rx%d_packets", i);
+   data += ETH_GSTRING_LEN;
+
+   snprintf(data, ETH_GSTRING_LEN, "rx%d_bytes", i);
+   data += ETH_GSTRING_LEN;
+
+   snprintf(data, ETH_GSTRING_LEN, "rx%d_interrupts", i);
+   data += ETH_GSTRING_LEN;
+   }
 }

 static int ibmvnic_get_sset_count(struct net_device *dev, int sset)
 {
+   struct ibmvnic_adapter *adapter = netdev_priv(dev);
+
switch (sset) {
case ETH_SS_STATS:
-   return ARRAY_SIZE(ibmvnic_stats);
+   return ARRAY_SIZE(ibmvnic_stats) +
+  adapter->req_tx_queues * NUM_TX_STATS +
+  adapter->req_rx_queues * NUM_RX_STATS;
default:
return -EOPNOTSUPP;
}
@@ -1730,7 +1792,7 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
 {
struct ibmvnic_adapter *adapter = netdev_priv(dev);
union 

[PATCH net-next 0/4] ibmvnic: Improve ethtool functionality

2017-08-02 Thread John Allen
This patch series improves ibmvnic ethtool functionality by adding support
for ethtool -l and -g options, correcting existing statistics reporting,
and augmenting the existing statistics with counters for each tx and rx
queue.

John Allen (4):
  ibmvnic: Implement per-queue statistics reporting
  ibmvnic: Convert vnic server reported statistics to cpu endian
  ibmvnic: Implement .get_ringparam
  ibmvnic: Implement .get_channels

 drivers/net/ethernet/ibm/ibmvnic.c | 115 ++---
 drivers/net/ethernet/ibm/ibmvnic.h |  17 ++
 2 files changed, 125 insertions(+), 7 deletions(-)

-- 
2.12.3



Car Owners List

2017-08-02 Thread Rachel Haynes


Hi,

Would you be interested in acquiring an Email list of "Car Owners" from USA?

We also have data for Luxury Car Owners List, Luxury Brand Buyers List, 
Mercedes-Benz Owners, BMW Owners, Audi Owners, Hyundai Owners, Porsche Owners, 
Toyota Owners, Harley Davidson Owners List, Motor Cycle Owners, Car Owners, HNI 
list, RV Owners and many more...

Each record in the list contains Contact Name(First and Last Name), Direct 
Mailing Address, List Type, Source and Email Address.

Let me know if you'd be interested in hearing more about it.

Look forward to your response.

Thanks & Regards,
Rachel Haynes

We respect your privacy, if you do not wish to receive any further emails from 
our end, please reply with a subject “Leave Out”.



Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

2017-08-02 Thread Luis R. Rodriguez
On Mon, Jul 31, 2017 at 05:09:44PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreover this
> bool also controls user helper in an unclear way.

> Some drivers need more flexible helper providing more options. This
> includes control over uevent or warning for the missing firmware. Of
> course this list may grow up in the future.
> 
> To handle this easily this patch adds a generic request_firmware_async
> function. It takes struct with options as an argument which will allow
> extending it in the future without massive changes.
> 
> This is a really cheap change (no new independent API) which works
> nicely with the existing code. The old request_firmware_nowait is kept
> as a simple helper calling new helper.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Don't expose all FW_OPT_* flags.
> As Luis noted we want a struct so add struct firmware_opts for real
> flexibility.
> Thank you Luis for your review!
> V5: Rebase, update commit message, resend after drvdata discussion
> ---
>  drivers/base/firmware_class.c | 43 
> ++-
>  include/linux/firmware.h  | 15 ++-
>  2 files changed, 48 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index b9f907eedbf7..cde85b05e4cb 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -1375,7 +1375,7 @@ static void request_firmware_work_func(struct 
> work_struct *work)
>   _request_firmware(, fw_work->name, fw_work->device, NULL, 0,
> fw_work->opt_flags);
>   fw_work->cont(fw, fw_work->context);
> - put_device(fw_work->device); /* taken in request_firmware_nowait() */
> + put_device(fw_work->device); /* taken in __request_firmware_nowait() */
>  
>   module_put(fw_work->module);
>   kfree_const(fw_work->name);
> @@ -1383,10 +1383,9 @@ static void request_firmware_work_func(struct 
> work_struct *work)
>  }
>  
>  /**
> - * request_firmware_nowait - asynchronous version of request_firmware
> + * __request_firmware_nowait - asynchronous version of request_firmware
>   * @module: module requesting the firmware
> - * @uevent: sends uevent to copy the firmware image if this flag
> - *   is non-zero else the firmware copy must be done manually.
> + * @opt_flags: flags that control firmware loading process, see FW_OPT_*
>   * @name: name of firmware file
>   * @device: device for which firmware is being loaded
>   * @gfp: allocation flags
> @@ -1405,9 +1404,9 @@ static void request_firmware_work_func(struct 
> work_struct *work)
>   *
>   *   - can't sleep at all if @gfp is GFP_ATOMIC.
>   **/
> -int
> -request_firmware_nowait(
> - struct module *module, bool uevent,
> +static int
> +__request_firmware_nowait(
> + struct module *module, unsigned int opt_flags,
>   const char *name, struct device *device, gfp_t gfp, void *context,
>   void (*cont)(const struct firmware *fw, void *context))
>  {
> @@ -1426,8 +1425,7 @@ request_firmware_nowait(
>   fw_work->device = device;
>   fw_work->context = context;
>   fw_work->cont = cont;
> - fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
> - (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
> + fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;
>  
>   if (!try_module_get(module)) {
>   kfree_const(fw_work->name);
> @@ -1440,8 +1438,35 @@ request_firmware_nowait(
>   schedule_work(_work->work);
>   return 0;
>  }
> +
> +int request_firmware_nowait(struct module *module, bool uevent,
> + const char *name, struct device *device, gfp_t gfp,
> + void *context,
> + void (*cont)(const struct firmware *fw, void 
> *context))
> +{
> + unsigned int opt_flags = FW_OPT_FALLBACK |
> + (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
> +
> + return __request_firmware_nowait(module, opt_flags, name, device, gfp,
> +  context, cont);
> +}
>  EXPORT_SYMBOL(request_firmware_nowait);
>  
> +int __request_firmware_async(struct module *module, const char *name,
> +  struct firmware_opts *fw_opts, struct device *dev,
> +  void *context,
> +  void (*cont)(const struct firmware *fw, void 
> *context))
> +{
> + unsigned int opt_flags = FW_OPT_UEVENT;

This exposes a long issue. Think -- why do we want this enabled by default? Its
actually because even though the fallback stuff is optional and can be, the 
uevent
internal flag *also* provides caching support as a side consequence only. We
don't want to add a new API without first 

Re: [PATCH net-next] tcp: remove extra POLL_OUT added for finished active connect()

2017-08-02 Thread Eric Dumazet
On Wed, 2017-08-02 at 15:59 -0400, Neal Cardwell wrote:
> Commit 45f119bf936b ("tcp: remove header prediction") introduced a
> minor bug: the sk_state_change() and sk_wake_async() notifications for
> a completed active connection happen twice: once in this new spot
> inside tcp_finish_connect() and once in the existing code in
> tcp_rcv_synsent_state_process() immediately after it calls
> tcp_finish_connect(). This commit remoes the duplicate POLL_OUT
> notifications.
> 
> Fixes: 45f119bf936b ("tcp: remove header prediction")
> Signed-off-by: Neal Cardwell 
> Cc: Florian Westphal 
> Cc: Eric Dumazet 
> Cc: Yuchung Cheng 
> ---
>  net/ipv4/tcp_input.c | 5 -
>  1 file changed, 5 deletions(-)

Acked-by: Eric Dumazet 




[PATCH 3/3] ARM: configs: keystone: Enable D_CAN driver

2017-08-02 Thread Franklin S Cooper Jr
Enable C_CAN/D_CAN driver supported by 66AK2G

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/configs/keystone_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index d47ea43..47be99e 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -112,6 +112,9 @@ CONFIG_IP_NF_ARP_MANGLE=y
 CONFIG_IP6_NF_IPTABLES=m
 CONFIG_IP_SCTP=y
 CONFIG_VLAN_8021Q=y
+CONFIG_CAN=m
+CONFIG_CAN_C_CAN=m
+CONFIG_CAN_C_CAN_PLATFORM=m
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-- 
2.9.4.dirty



[PATCH 2/3] ARM: dts: k2g: Add DCAN nodes

2017-08-02 Thread Franklin S Cooper Jr
From: Lokesh Vutla 

Add nodes for the two DCAN instances included in 66AK2G

Signed-off-by: Lokesh Vutla 
[d-gerl...@ti.com: add power-domains and clock information]
Signed-off-by: Dave Gerlach 
[fcoo...@ti.com: update subject and commit message. Misc minor updates]
Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index bf4d1fa..bebc857 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -113,6 +113,24 @@
status = "disabled";
};
 
+   dcan0: can@0260B200 {
+   compatible = "ti,am4372-d_can", "ti,am3352-d_can";
+   reg = <0x0260B200 0x200>;
+   interrupts = ;
+   status = "disabled";
+   power-domains = <_pds 0x0008>;
+   clocks = <_clks 0x0008 1>;
+   };
+
+   dcan1: can@0260B400 {
+   compatible = "ti,am4372-d_can", "ti,am3352-d_can";
+   reg = <0x0260B400 0x200>;
+   interrupts = ;
+   status = "disabled";
+   power-domains = <_pds 0x0009>;
+   clocks = <_clks 0x0009 1>;
+   };
+
kirq0: keystone_irq@026202a0 {
compatible = "ti,keystone-irq";
interrupts = ;
-- 
2.9.4.dirty



[PATCH 0/3] ARM: dts: keystone-k2g: Add DCAN instances to 66AK2G

2017-08-02 Thread Franklin S Cooper Jr
Add D CAN nodes to 66AK2G based SoC dtsi.

Franklin S Cooper Jr (2):
  dt-bindings: net: c_can: Update binding for clock and power-domains
property
  ARM: configs: keystone: Enable D_CAN driver

Lokesh Vutla (1):
  ARM: dts: k2g: Add DCAN nodes

 Documentation/devicetree/bindings/net/can/c_can.txt | 13 -
 arch/arm/boot/dts/keystone-k2g.dtsi | 18 ++
 arch/arm/configs/keystone_defconfig |  3 +++
 3 files changed, 33 insertions(+), 1 deletion(-)

-- 
2.9.4.dirty



[PATCH 1/3] dt-bindings: net: c_can: Update binding for clock and power-domains property

2017-08-02 Thread Franklin S Cooper Jr
CAN driver uses the clk_get_rate call to determine the frequency of the
functional clock. OMAP based SoCs do not require the clock property since
hwmod already handles creating a "fck" clock thats accessible to drivers.
However, this isn't the case for 66AK2G which makes the clocks property
require for that SoC.

66AK2G requires a new property. Therefore, update the binding to also make
this property requirement clear. Also clarify that for OMAP based SoCs
ti,hwmod is a required property.

Signed-off-by: Franklin S Cooper Jr 
---
 Documentation/devicetree/bindings/net/can/c_can.txt | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt 
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 5a1d8b0..2d50425 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -11,9 +11,20 @@ Required properties:
 - interrupts   : property with a value describing the interrupt
  number
 
-Optional properties:
+The following are mandatory properties for DRA7x, AM33xx and AM43xx SoCs only:
 - ti,hwmods: Must be "d_can" or "c_can", n being the
  instance number
+
+The following are mandatory properties for Keystone 2 66AK2G SoCs only:
+- power-domains: Should contain a phandle to a PM domain 
provider node
+ and an args specifier containing the DCAN device id
+ value. This property is as per the binding,
+ 
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+- clocks   : CAN functional clock phandle. This property is as per 
the
+ binding,
+ Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+
+Optional properties:
 - syscon-raminit   : Handle to system control region that contains the
  RAMINIT register, register offset to the RAMINIT
  register and the CAN instance number (0 offset).
-- 
2.9.4.dirty



Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread Mason
On 02/08/2017 19:31, Mason wrote:

> # iperf3 -c 172.27.64.45 -u -b 950M
> Connecting to host 172.27.64.45, port 5201
> [  4] local 172.27.64.1 port 55533 connected to 172.27.64.45 port 5201
> [ ID] Interval   Transfer Bandwidth   Total Datagrams
> [  4]   0.00-1.00   sec   102 MBytes   858 Mbits/sec  13091  
> [  4]   1.00-2.00   sec   114 MBytes   953 Mbits/sec  14541  

114 MB in 14541 packets => 7840 bytes per packet
Is iperf3 sending jumbo frames??
In the nb8800 driver, RX_BUF_SIZE is only 1552,
how would it deal with jumbo frames... truncate?

> # iperf3 -c 172.27.64.45 -u -b 950M -l 800
> Connecting to host 172.27.64.45, port 5201
> [  4] local 172.27.64.1 port 35197 connected to 172.27.64.45 port 5201
> [ ID] Interval   Transfer Bandwidth   Total Datagrams
> [  4]   0.00-1.00   sec  90.6 MBytes   760 Mbits/sec  118724  
> [  4]   1.00-2.00   sec   107 MBytes   894 Mbits/sec  139718  

107 MB in 139718 packets => 766 bytes per packet
800 - 8 (UDP) - 20 (IPv4) = 772 bytes per packet
I suppose that's close enough...
772 * 139718 = 107.86 MB

I need to run the test slightly slower, to prevent
packet loss at the sender.

Perhaps -b 0 or -b 800M

Regards.


[PATCH net-next] tcp: remove extra POLL_OUT added for finished active connect()

2017-08-02 Thread Neal Cardwell
Commit 45f119bf936b ("tcp: remove header prediction") introduced a
minor bug: the sk_state_change() and sk_wake_async() notifications for
a completed active connection happen twice: once in this new spot
inside tcp_finish_connect() and once in the existing code in
tcp_rcv_synsent_state_process() immediately after it calls
tcp_finish_connect(). This commit remoes the duplicate POLL_OUT
notifications.

Fixes: 45f119bf936b ("tcp: remove header prediction")
Signed-off-by: Neal Cardwell 
Cc: Florian Westphal 
Cc: Eric Dumazet 
Cc: Yuchung Cheng 
---
 net/ipv4/tcp_input.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index df670d7ed98d..99cdf4ccabb8 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5342,11 +5342,6 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff 
*skb)
 
if (sock_flag(sk, SOCK_KEEPOPEN))
inet_csk_reset_keepalive_timer(sk, keepalive_time_when(tp));
-
-   if (!sock_flag(sk, SOCK_DEAD)) {
-   sk->sk_state_change(sk);
-   sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
-   }
 }
 
 static bool tcp_rcv_fastopen_synack(struct sock *sk, struct sk_buff *synack,
-- 
2.14.0.rc1.383.gd1ce394fe2-goog



Re: [PATCH v2 net-next 3/4] tcp: Adjust TCP ULP to defer to sockets ULP

2017-08-02 Thread Dave Watson
On 08/01/17 08:18 PM, Tom Herbert wrote:
>  
> -static int tls_init(struct sock *sk)
> +static int tls_init(struct sock *sk, char __user *optval, int len)
>  {
> - struct inet_connection_sock *icsk = inet_csk(sk);
>   struct tls_context *ctx;
>   int rc = 0;
>  
> @@ -450,7 +449,7 @@ static int tls_init(struct sock *sk)
>   rc = -ENOMEM;
>   goto out;
>   }
> - icsk->icsk_ulp_data = ctx;
> + sk->sk_ulp_data = ctx;
>   ctx->setsockopt = sk->sk_prot->setsockopt;
>   ctx->getsockopt = sk->sk_prot->getsockopt;
>   sk->sk_prot = _base_prot;
> @@ -458,7 +457,7 @@ static int tls_init(struct sock *sk)
>   return rc;
>  }

It looks like tls_init should be checking if this is a tcp socket now
also, and failing if not


Re: [PATCH net-next] net: dsa: bcm_sf2: dst in not an array

2017-08-02 Thread Florian Fainelli
On 08/02/2017 12:48 PM, Vivien Didelot wrote:
> It's been a while now since ds->dst is not an array anymore, but a
> simple pointer to a dsa_switch_tree.
> 
> Fortunately, SF2 does not support multi-chip and thus ds->index is
> always 0.
> 
> This patch substitutes 'ds->dst[ds->index].' with 'ds->dst->'.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 

Thanks!
-- 
Florian


[PATCH net-next] net: dsa: bcm_sf2: dst in not an array

2017-08-02 Thread Vivien Didelot
It's been a while now since ds->dst is not an array anymore, but a
simple pointer to a dsa_switch_tree.

Fortunately, SF2 does not support multi-chip and thus ds->index is
always 0.

This patch substitutes 'ds->dst[ds->index].' with 'ds->dst->'.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/bcm_sf2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 6bbfa6ea1efb..558667c814c9 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -788,7 +788,7 @@ static int bcm_sf2_sw_resume(struct dsa_switch *ds)
 static void bcm_sf2_sw_get_wol(struct dsa_switch *ds, int port,
   struct ethtool_wolinfo *wol)
 {
-   struct net_device *p = ds->dst[ds->index].cpu_dp->netdev;
+   struct net_device *p = ds->dst->cpu_dp->netdev;
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
struct ethtool_wolinfo pwol;
 
@@ -811,7 +811,7 @@ static void bcm_sf2_sw_get_wol(struct dsa_switch *ds, int 
port,
 static int bcm_sf2_sw_set_wol(struct dsa_switch *ds, int port,
  struct ethtool_wolinfo *wol)
 {
-   struct net_device *p = ds->dst[ds->index].cpu_dp->netdev;
+   struct net_device *p = ds->dst->cpu_dp->netdev;
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
s8 cpu_port = ds->dst->cpu_dp->index;
struct ethtool_wolinfo pwol;
-- 
2.13.3



Re: [iproute PATCH] bpf: Make bytecode-file reading a little more robust

2017-08-02 Thread Daniel Borkmann

On 08/02/2017 02:57 PM, Phil Sutter wrote:

bpf_parse_string() will now correctly handle:

- Extraneous whitespace,
- OPs on multiple lines and
- overlong file names.

The added feature of allowing to have OPs on multiple lines (like e.g.
tcpdump prints them) is rather a side effect of fixing detection of
malformed bytecode files having random content on a second line, like
e.g.:

| 4,40 0 0 12,21 0 1 2048,6 0 0 262144,6 0 0 0
| foobar

Cc: Daniel Borkmann 
Signed-off-by: Phil Sutter 


Acked-by: Daniel Borkmann 


Re: [PATCH v2 net-next 3/4] tcp: Adjust TCP ULP to defer to sockets ULP

2017-08-02 Thread Tom Herbert
On Wed, Aug 2, 2017 at 11:59 AM, Dave Watson  wrote:
> On 08/01/17 08:18 PM, Tom Herbert wrote:
>> Fix TCP and TLS to use the newer ULP infrastructure in sockets.
>>
>> Signed-off-by: Tom Herbert 
>> ---
>>  Documentation/networking/tls.txt   |   6 +-
>>  include/net/inet_connection_sock.h |   4 --
>>  include/net/tcp.h  |  25 ---
>>  include/net/tls.h  |   4 +-
>>  net/ipv4/sysctl_net_ipv4.c |   9 ++-
>>  net/ipv4/tcp.c |  40 ++-
>>  net/ipv4/tcp_ipv4.c|   2 -
>>  net/ipv4/tcp_ulp.c | 135 
>> -
>>  net/tls/Kconfig|   1 +
>>  net/tls/tls_main.c |  21 +++---
>>  10 files changed, 47 insertions(+), 200 deletions(-)
>>  delete mode 100644 net/ipv4/tcp_ulp.c
>
> It looks like net/ipv4/Makefile needs updating as well.
>
Right, I'll send out v3.

> I ran this through some ktls tests with no issues.  Thanks
>
> Tested-by: Dave Watson 

Thanks for testing!

Tom


Re: [PATCH v2 net-next 3/4] tcp: Adjust TCP ULP to defer to sockets ULP

2017-08-02 Thread Dave Watson
On 08/01/17 08:18 PM, Tom Herbert wrote:
> Fix TCP and TLS to use the newer ULP infrastructure in sockets.
> 
> Signed-off-by: Tom Herbert 
> ---
>  Documentation/networking/tls.txt   |   6 +-
>  include/net/inet_connection_sock.h |   4 --
>  include/net/tcp.h  |  25 ---
>  include/net/tls.h  |   4 +-
>  net/ipv4/sysctl_net_ipv4.c |   9 ++-
>  net/ipv4/tcp.c |  40 ++-
>  net/ipv4/tcp_ipv4.c|   2 -
>  net/ipv4/tcp_ulp.c | 135 
> -
>  net/tls/Kconfig|   1 +
>  net/tls/tls_main.c |  21 +++---
>  10 files changed, 47 insertions(+), 200 deletions(-)
>  delete mode 100644 net/ipv4/tcp_ulp.c

It looks like net/ipv4/Makefile needs updating as well.

I ran this through some ktls tests with no issues.  Thanks

Tested-by: Dave Watson 


Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter

2017-08-02 Thread Nambiar, Amritha
On 8/2/2017 11:41 AM, Roopa Prabhu wrote:
> On Mon, Jul 31, 2017 at 5:40 PM, Amritha Nambiar
>  wrote:
>> The Mirred/redirect action is extended to accept a traffic
>> class on the device in addition to the device's ifindex.
>>
>> Usage: mirred
>>
>> Example:
>> # tc qdisc add dev eth0 ingress
>>
>> # tc filter add dev eth0 protocol ip parent : prio 1 flower\
>>   dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
>>   indev eth0 action mirred ingress redirect dev eth0 tc 1
> 
> 
> Can we call the new parameter tclass or something else ?.
> with this 'tc' appears twice in the command :)
> 

Sounds right. I was already thinking of alternatives like 'tcqgroup',
'qgroup' and now we have 'tclass'.


Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter

2017-08-02 Thread Roopa Prabhu
On Mon, Jul 31, 2017 at 5:40 PM, Amritha Nambiar
 wrote:
> The Mirred/redirect action is extended to accept a traffic
> class on the device in addition to the device's ifindex.
>
> Usage: mirred
>
> Example:
> # tc qdisc add dev eth0 ingress
>
> # tc filter add dev eth0 protocol ip parent : prio 1 flower\
>   dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
>   indev eth0 action mirred ingress redirect dev eth0 tc 1


Can we call the new parameter tclass or something else ?.
with this 'tc' appears twice in the command :)


Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread Timur Tabi

On 08/02/2017 01:35 PM, David Miller wrote:

Again, any serious installation will have a system watchdog enabled
which will break the pause frame bomb.


Oh well.  I guess I'll have to carry this patch internally.

What about patch #2?

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.


Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread David Miller
From: Timur Tabi 
Date: Wed, 2 Aug 2017 13:23:18 -0500

> It's practically impossible to overload the chip such that it can't
> process the incoming packets fast enough.  I don't know of any
> real-world situation where the EMAC needs to transmit pause frames.

Slow cpus or very expensive stack operations can cause this, it's not
a property of the EMAC chip at all.


Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread David Miller
From: Timur Tabi 
Date: Wed, 2 Aug 2017 13:23:18 -0500

> On 08/02/2017 12:54 PM, David Miller wrote:
>> And if this kind of thing matters to the user, they will have a
>> software or hardware watchdog driver enabled to break out of this
>> situation.
> 
> The problem is that the user is not going to expect that the EMAC can
> disable the nearby switch(es) when the kernel is hung and not rebooted
> quickly enough.  Internally, this bug/feature has caused quite a bit
> of mayhem, so the problem is real.  No cares about enabling flow
> control -- it just happens to be enabled on some systems where the
> switch agrees to it.  So random individuals can't debug the hardware
> because suddenly the EMAC has gone haywire and disabled the local
> network.

Again, any serious installation will have a system watchdog enabled
which will break the pause frame bomb.


Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter

2017-08-02 Thread Nambiar, Amritha
On 8/1/2017 8:12 AM, David Laight wrote:
> From: Stephen Hemminger
>> Sent: 01 August 2017 04:52
>> On Mon, 31 Jul 2017 17:40:50 -0700
>> Amritha Nambiar  wrote:
>> The concept is fine, bu t the code looks different than the rest which
>> is never a good sign.
>>
>>
>>> +   if ((argc > 0) && (matches(*argv, "tc") == 0)) {
>>
>> Extra () are unnecessary in compound conditional.
>>
>>> +   tc = atoi(*argv);
>>
>> Prefer using strtoul since it has better error handling than atoi()
>>
>>> +   argc--;
>>> +   argv++;
>>> +   }
>>
>>
>> Use NEXT_ARG() construct like rest of the code.
> 
> Why bother faffing about with argc at all?
> The argument list terminates when *argv == NULL.
> 

I'll submit the next version with these fixes.

>   David
> 


Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread Timur Tabi

On 08/02/2017 12:54 PM, David Miller wrote:

And if this kind of thing matters to the user, they will have a
software or hardware watchdog driver enabled to break out of this
situation.


The problem is that the user is not going to expect that the EMAC can 
disable the nearby switch(es) when the kernel is hung and not rebooted 
quickly enough.  Internally, this bug/feature has caused quite a bit of 
mayhem, so the problem is real.  No cares about enabling flow control -- 
it just happens to be enabled on some systems where the switch agrees to 
it.  So random individuals can't debug the hardware because suddenly the 
EMAC has gone haywire and disabled the local network.



Turning off flow control by default has so many negative ramifications
and don't try to convince me that users will be "aware" of this and
turn it back on.


What are the negative ramifications?  It's practically impossible to 
overload the chip such that it can't process the incoming packets fast 
enough.  I don't know of any real-world situation where the EMAC needs 
to transmit pause frames.


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.


Re: [PATCH 6/6] [net-next]net: i40e: Enable cloud filters in i40e via tc/flower classifier

2017-08-02 Thread Nambiar, Amritha
On 8/2/2017 5:02 AM, Jamal Hadi Salim wrote:
> On 17-08-01 10:13 PM, Nambiar, Amritha wrote:
>>
>> On 8/1/2017 3:56 AM, Jamal Hadi Salim wrote:
>>> On 17-07-31 08:38 PM, Amritha Nambiar wrote:
 This patch enables tc-flower based hardware offloads. tc/flower
 filter provided by the kernel is configured as driver specific
 cloud filter. The patch implements functions and admin queue
 commands needed to support cloud filters in the driver and
 adds cloud filters to configure these tc-flower filters.

 The only action supported is to redirect packets to a traffic class
 on the same device.

 # tc qdisc add dev eth0 ingress
 # ethtool -K eth0 hw-tc-offload on

 # tc filter add dev eth0 protocol ip parent :\
 prio 1 flower dst_mac 3c:fd:fe:a0:d6:70 skip_sw indev eth0\
 action mirred ingress redirect dev eth0 tc 0

>>>
>>> Out of curiosity - did you need to say "indev eth0" there?
>>
>> It looks like I don't need to specify "indev eth0". I will need to look
>> up how this part is offloaded and probably validate in the driver when
>> this is specified.
>>
>>> Also: Is it possible to add an skbmark? Example something like
>>> these that directs two flows to the same queue but different
>>> skb marks:
>>>
>>> # tc filter add dev eth0 protocol ip parent : \
>>> prio 2 flower dst_ip 192.168.3.5/32 \
>>> ip_proto udp dst_port 2a skip_sw \
>>> action skbedit mark 11 \
>>> action mirred ingress redirect dev eth0 tcqueue 1
>>>
>>> # tc filter add dev eth0 protocol ip parent : \
>>>   prio 1 flower dst_mac 3c:fd:fe:a0:d6:70 skip_sw \
>>>   action skbedit mark 12 \
>>>   action mirred ingress redirect dev eth0 tcqueue 1
>>>
>>
>> It is possible to support the skbedit mark action for the first rule
>> here (L3 and L4) which I can take up in a subsequent patch, but this
>> cannot be supported on our device for L2 based match in the second rule.
>>
> 
> Ok, thanks. So the issue is one of hardware limitation?
> 

Right. Our hardware does not have this support now.

> cheers,
> jamal
> 


Re: [PATCH net-next RFC 0/6] Configure cloud filters in i40e via tc/flower classifier

2017-08-02 Thread Nambiar, Amritha

On 8/2/2017 5:01 AM, Jamal Hadi Salim wrote:
> On 17-08-01 08:57 PM, Nambiar, Amritha wrote:
>>
>> On 8/1/2017 3:15 AM, Jamal Hadi Salim wrote:
>>> On 17-07-31 08:36 PM, Amritha Nambiar wrote:
> 

 # tc filter add dev eth0 protocol ip parent : prio 1 flower\
 dst_ip 192.168.1.1/32 ip_proto udp dst_port 22\
 skip_sw indev eth0 action mirred ingress redirect dev eth0 tc 1

>>>
>>> I think "queue 1" sounds better than "tc 1".
>>> "tc" is  already a keyword in a few places (even within that declaration
>>> above).
>>
>> The idea is to redirect to a traffic class that has queues assigned to
>> it and not a single queue i.e. these are actually queue groups and not a
>> single queue. So may be "qgroup 1" or "tcqgroup 1" fits better.
>>
> 
> Can you describe how this works? So the specific memeber of a
> a tcgroups show up on a specific rx DMA ring? If you only have
> 16 and 512 RX DMA rings - how does that work?
>

The Rx rule here is to redirect packets a specific traffic class. It is
the traffic class index (queue group index) that is offloaded to the
device. Queues were already configured for the traffic class by mapping
the queue counts and offsets and offloading this layout using the mqprio
framework. I had submitted a patch series for this which uses a new
hardware offload mode in mqprio to offload the TCs, the queue
configurations and the bandwidth rates for the TCs. So the 512 rings can
be mapped into 16 TCs using the mqprio offload mechanism, something like
this:
TC0 : 0 – 15
TC1: 16 – 31
TC2: 32 – 33
TC3: 34 – 49
.
.
.
TC15: 500 - 511

Now, once the TC configuration is prepared, it is just a matter of
hooking up the Rx rules to route traffic to the traffic class/queue
group. Rx queue selection within the queue group happens based on RSS.

> cheers,
> jamal
> 


Re: [PATCH net] tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states

2017-08-02 Thread Yuchung Cheng
On Wed, Aug 2, 2017 at 10:51 AM, David Miller  wrote:
>
> From: Yuchung Cheng 
> Date: Tue,  1 Aug 2017 13:22:32 -0700
>
> > If the sender switches the congestion control during ECN-triggered
> > cwnd-reduction state (CA_CWR), upon exiting recovery cwnd is set to
> > the ssthresh value calculated by the previous congestion control. If
> > the previous congestion control is BBR that always keep ssthresh
> > to TCP_INIFINITE_SSTHRESH, cwnd ends up being infinite. The safe
> > step is to avoid assigning invalid ssthresh value when recovery ends.
> >
> > Signed-off-by: Yuchung Cheng 
> > Signed-off-by: Neal Cardwell 
>
> Applied, thanks.
>
> Is this a -stable candidate?

Yes it is. Thanks!


[PATCH 0/2] drivers/net: add const to bin_attribute structures

2017-08-02 Thread Bhumika Goyal
Declare bin_attribute structures as const.

Bhumika Goyal (2):
  wlcore: add const to bin_attribute structure
  qlcnic: add const to bin_attribute structure

 drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
 drivers/net/wireless/ti/wlcore/sysfs.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1



[PATCH 1/2] wlcore: add const to bin_attribute structure

2017-08-02 Thread Bhumika Goyal
Add const to bin_attribute structure as it is only passed to the
functions sysfs_{remove/create}_bin_file. The corresponding arguments
are of type const, so declare the structure to be const.

Signed-off-by: Bhumika Goyal 
---
 drivers/net/wireless/ti/wlcore/sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wlcore/sysfs.c 
b/drivers/net/wireless/ti/wlcore/sysfs.c
index a9218e5..b72e210 100644
--- a/drivers/net/wireless/ti/wlcore/sysfs.c
+++ b/drivers/net/wireless/ti/wlcore/sysfs.c
@@ -138,7 +138,7 @@ static ssize_t wl1271_sysfs_read_fwlog(struct file *filp, 
struct kobject *kobj,
return len;
 }
 
-static struct bin_attribute fwlog_attr = {
+static const struct bin_attribute fwlog_attr = {
.attr = {.name = "fwlog", .mode = S_IRUSR},
.read = wl1271_sysfs_read_fwlog,
 };
-- 
1.9.1



[PATCH 2/2] qlcnic: add const to bin_attribute structure

2017-08-02 Thread Bhumika Goyal
Add const to bin_attribute structure as it is only passed to the
functions sysfs_{remove/create}_bin_file. The corresponding
arguments are of type const, so declare the structure to be const.

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c 
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
index 73027a6..82fcb83 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
@@ -1248,7 +1248,7 @@ static ssize_t 
qlcnic_83xx_sysfs_flash_write_handler(struct file *filp,
.write = qlcnic_sysfs_write_pm_config,
 };
 
-static struct bin_attribute bin_attr_flash = {
+static const struct bin_attribute bin_attr_flash = {
.attr = {.name = "flash", .mode = (S_IRUGO | S_IWUSR)},
.size = 0,
.read = qlcnic_83xx_sysfs_flash_read_handler,
-- 
1.9.1



Re: [PATCH 1/2] [for 4.13] net: qcom/emac: disable flow control autonegotiation by default

2017-08-02 Thread David Miller
From: Timur Tabi 
Date: Tue,  1 Aug 2017 16:37:39 -0500

> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs.  With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames until the system is reset.  The EMAC does not
> have a built-in watchdog.
> 
> In various tests, the pause frame stream sometimes overloads nearby
> switches, effectively disabling the network.  Since the RX queue is
> large and the host processor is more than capable of handling incoming
> packets quickly, the only time the EMAC will send any pause frames is
> when the kernel is hung and unrecoverable.
> 
> To avoid all these problems, we disable flow control autonegotiation
> by default, and only enable receiving pause frames.
> 
> Cc: sta...@vger.kernel.org # 4.11.x
> Signed-off-by: Timur Tabi 

I've thought about this a lot and I don't like it for many reasons.

First of all, this hung kernel scenerio is completely bogus.

The ethernet chip may not have a proper watchdog for the pause frame
generation logic, but the whole kernel sure as hell does.

And if this kind of thing matters to the user, they will have a
software or hardware watchdog driver enabled to break out of this
situation.

Turning off flow control by default has so many negative ramifications
and don't try to convince me that users will be "aware" of this and
turn it back on.

They largely won't.


Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

2017-08-02 Thread Casey Leedom
  Okay, here you go.  As you can tell, it's almost a trivial copy of the
cxgb4 patch.
 
  By the way, I realized that we have yet another hole which is likely not
to be fixable.  If we're dealing with a problematic Root Complex, and we
instantiate Virtual Functions and attach them to a Virtual Machine along
with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver
in the VM will be able to tell that it shouldn't attempt to send RO TLPs to
the RC because it will see the state of its own PCIe Capability Device
Control[Relaxed Ordering Enable] (a copy of the setting in the VF's
corresponding PF), but it won't be able to change that and send non-RO TLPs
to the RC, and RO TLPs to the NVMe device.  Oh well.

  I sure wish that the Intel guys would pop up with a hidden register change
for these problematic Intel RCs that perform poorly with RO TLPs.  Their
silence has been frustrating.

Casey

--

cxgb4vf Ethernet driver now queries PCIe configuration space to determine if
it can send TLPs to it with the Relaxed Ordering Attribute set.

diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h 
b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
index 109bc63..08c6ddb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
@@ -408,6 +408,7 @@ enum { /* adapter flags */
USING_MSI  = (1UL << 1),
USING_MSIX = (1UL << 2),
QUEUES_BOUND   = (1UL << 3),
+   ROOT_NO_RELAXED_ORDERING = (1UL << 4),
 };
 
 /*
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index ac7a150..59e7639 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
 */
adapter->name = pci_name(pdev);
adapter->msg_enable = DFLT_MSG_ENABLE;
+
+   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+* Ingress Packet Data to Free List Buffers in order to allow for
+* chipset performance optimizations between the Root Complex and
+* Memory Controllers.  (Messages to the associated Ingress Queue
+* notifying new Packet Placement in the Free Lists Buffers will be
+* send without the Relaxed Ordering Attribute thus guaranteeing that
+* all preceding PCIe Transaction Layer Packets will be processed
+* first.)  But some Root Complexes have various issues with Upstream
+* Transaction Layer Packets with the Relaxed Ordering Attribute set.
+* The PCIe devices which under the Root Complexes will be cleared the
+* Relaxed Ordering bit in the configuration space, So we check our
+* PCIe configuration space to see if it's flagged with advice against
+* using Relaxed Ordering.
+*/
+   if (!pcie_relaxed_ordering_supported(pdev))
+   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
err = adap_init0(adapter);
if (err)
goto err_unmap_bar;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index e37dde2..05498e7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct 
sge_rspq *rspq,
struct port_info *pi = netdev_priv(dev);
struct fw_iq_cmd cmd, rpl;
int ret, iqandst, flsz = 0;
+   int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING);
 
/*
 * If we're using MSI interrupts and we're not initializing the
@@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct 
sge_rspq *rspq,
cpu_to_be32(
FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) |
FW_IQ_CMD_FL0PACKEN_F |
+   FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+   FW_IQ_CMD_FL0DATARO_V(relaxed) |
FW_IQ_CMD_FL0PADEN_F);
 
/* In T6, for egress queue type FL there is internal overhead


Re: [PATCH net] tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states

2017-08-02 Thread David Miller
From: Yuchung Cheng 
Date: Tue,  1 Aug 2017 13:22:32 -0700

> If the sender switches the congestion control during ECN-triggered
> cwnd-reduction state (CA_CWR), upon exiting recovery cwnd is set to
> the ssthresh value calculated by the previous congestion control. If
> the previous congestion control is BBR that always keep ssthresh
> to TCP_INIFINITE_SSTHRESH, cwnd ends up being infinite. The safe
> step is to avoid assigning invalid ssthresh value when recovery ends.
> 
> Signed-off-by: Yuchung Cheng 
> Signed-off-by: Neal Cardwell 

Applied, thanks.

Is this a -stable candidate?


[PATCH] xfrm: policy: check policy direction value

2017-08-02 Thread Vladis Dronov
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.

This fixes CVE-2017-11600.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint 
address(es)")
Cc:  # v2.6.21-rc1
Reported-by: "bo Zhang" 
Signed-off-by: Vladis Dronov 
---
 net/xfrm/xfrm_policy.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index ff61d85..6f5a0dad 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -3308,9 +3308,15 @@ int xfrm_migrate(const struct xfrm_selector *sel, u8 
dir, u8 type,
struct xfrm_state *x_new[XFRM_MAX_DEPTH];
struct xfrm_migrate *mp;
 
+   /* Stage 0 - sanity checks */
if ((err = xfrm_migrate_check(m, num_migrate)) < 0)
goto out;
 
+   if (dir >= XFRM_POLICY_MAX) {
+   err = -EINVAL;
+   goto out;
+   }
+
/* Stage 1 - find policy */
if ((pol = xfrm_migrate_policy_find(sel, dir, type, net)) == NULL) {
err = -ENOENT;
-- 
2.9.4



Re: [Patch net-next] flow_dissector: remove unused functions

2017-08-02 Thread David Miller
From: Cong Wang 
Date: Tue,  1 Aug 2017 13:18:09 -0700

> They are introduced by commit f70ea018da06
> ("net: Add functions to get skb->hash based on flow structures")
> but never gets used in tree.
> 
> Signed-off-by: Cong Wang 

Yeah these can be reintroduced if we really end up needing them.

Applied, thanks.


Re: [PATCH net] ibmvnic: Initialize SCRQ's during login renegotiation

2017-08-02 Thread David Miller
From: Thomas Falcon 
Date: Tue,  1 Aug 2017 15:04:36 -0500

> SCRQ resources are freed during renegotiation, but they are not
> re-allocated afterwards due to some changes in the initialization
> process. Fix that by re-allocating the memory after renegotation.
> 
> SCRQ's can also be freed if a server capabilities request fails.
> If this were encountered during a device reset for example,
> SCRQ's may not be re-allocated. This operation is not necessary
> anymore so remove it.
> 
> Signed-off-by: Thomas Falcon 

Applied, thank you.


Re: [PATCH 2/2] usb: qmi_wwan: add D-Link DWM-222 device ID

2017-08-02 Thread David Miller
From: Hector Martin 
Date: Wed,  2 Aug 2017 00:45:44 +0900

> Signed-off-by: Hector Martin 

Applied.


Re: [PATCH net-next] tcp: tcp_data_queue() cleanup

2017-08-02 Thread David Miller
From: Eric Dumazet 
Date: Tue, 01 Aug 2017 07:02:44 -0700

> From: Eric Dumazet 
> 
> Commit c13ee2a4f03f ("tcp: reindent two spots after prequeue removal")
> removed code in tcp_data_queue().
> 
> We can go a little farther, removing an always true test,
> and removing initializers for fragstolen and eaten variables.
> 
> Signed-off-by: Eric Dumazet 

Series applied, thanks!


Re: [PATCH net 0/4] mlx4 misc fixes

2017-08-02 Thread David Miller
From: Tariq Toukan 
Date: Tue,  1 Aug 2017 16:43:42 +0300

> This patchset contains misc bug fixes from the team
> to the mlx4 Core and Eth drivers.
> 
> Patch 1 by Inbar fixes a wrong ethtool indication for Wake-on-LAN.
> The other 3 patches by Jack add a missing capability description,
> and fixes the off-by-1 misalignment for the following capabilities
> descriptions.
> 
> Series generated against net commit:
> cc75f8514db6 samples/bpf: fix bpf tunnel cleanup

Series applied, thanks!


Re: [PATCH net-next] net: bcmgenet: drop COMPILE_TEST dependency

2017-08-02 Thread David Miller
From: Arnd Bergmann 
Date: Tue,  1 Aug 2017 13:50:56 +0200

> The last patch added the dependency on 'OF && HAS_IOMEM' but left
> COMPILE_TEST as an alternative, which kind of defeats the purpose
> of adding the dependency, we still get randconfig build warnings:
> 
> warning: (NET_DSA_BCM_SF2 && BCMGENET) selects MDIO_BCM_UNIMAC which has 
> unmet direct dependencies (NETDEVICES && MDIO_BUS && HAS_IOMEM && OF_MDIO)
> 
> For compile-testing purposes, we don't really need this anyway,
> as CONFIG_OF can be enabled on all architectures, and HAS_IOMEM
> is present on all architectures we do meaningful compile-testing on
> (the exception being arch/um).
> 
> This makes both OF and HAS_IOMEM hard dependencies.
> 
> Fixes: 5af74bb4fcf8 ("net: bcmgenet: Add dependency on HAS_IOMEM && OF")
> Signed-off-by: Arnd Bergmann 

Applied.


Re: [PATCH v3 10/11] ARM64: dts: rockchip: Add gmac2phy node support for rk3328

2017-08-02 Thread Florian Fainelli
On 08/01/2017 11:24 PM, David Wu wrote:
> The gmac2phy controller of rk3328 is connected to internal phy
> directly inside, add the node for the internal phy support.
> 
> Signed-off-by: David Wu 
> ---
>  arch/arm64/boot/dts/rockchip/rk3328.dtsi | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index 0be96ce..51c8c66 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -63,6 +63,8 @@
>   i2c1 = 
>   i2c2 = 
>   i2c3 = 
> + ethernet0 = 
> + ethernet1 = 
>   };
>  
>   cpus {
> @@ -424,6 +426,29 @@
>   status = "disabled";
>   };
>  
> + gmac2phy: eth@ff55 {
> + compatible = "rockchip,rk3328-gmac";
> + reg = <0x0 0xff55 0x0 0x1>;
> + rockchip,grf = <>;
> + interrupts = ;
> + interrupt-names = "macirq";
> + clocks = < SCLK_MAC2PHY_SRC>, < SCLK_MAC2PHY_RXTX>,
> +  < SCLK_MAC2PHY_RXTX>, < SCLK_MAC2PHY_REF>,
> +  < ACLK_MAC2PHY>, < PCLK_MAC2PHY>,
> +  < SCLK_MAC2PHY_OUT>;
> + clock-names = "stmmaceth", "mac_clk_rx",
> +   "mac_clk_tx", "clk_mac_ref",
> +   "aclk_mac", "pclk_mac",
> +   "clk_macphy";
> + resets = < SRST_GMAC2PHY_A>, < SRST_MACPHY>;
> + reset-names = "stmmaceth", "mac-phy";
> + phy-mode = "rmii";
> + phy-is-internal;
> + pinctrl-names = "default";
> + pinctrl-0 = <_rxm1 _linkm1>;
> + status = "disabled";

But where is the the phy-handle property that points to this internal
PHY? Even if it is internal, it should be described properly with a mdio
bus sub-node and a standard Ethernet PHY node as specified by both
Documentation/devicetree/bindings/net/mdio.txt and
Documentation/devicetree/bindings/net/phy.txt

That means we should at least see something like this (on top of what
you added already)
phy-handle = <>;

mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;

phy@0 {
compatible = "ethernet-phy-id1234.d400", 
"ethernet-phy-802.3-c22";
reg = <0>;
phy-is-internal;
};
};

> + };
> +
>   gic: interrupt-controller@ff811000 {
>   compatible = "arm,gic-400";
>   #interrupt-cells = <3>;
> 


-- 
Florian


Re: [PATCH net 0/2] lan78xx: Fixes to lan78xx driver

2017-08-02 Thread David Miller
From: 
Date: Tue, 1 Aug 2017 10:23:52 +

> From: Nisar Sayed 
> 
> This series of patches are for lan78xx driver.
> 
> These patches fixes potential issues associated with lan78xx driver

Series applied, thanks.


[PATCH net-next] rds: reduce memory footprint for RDS when transport is RDMA

2017-08-02 Thread Sowmini Varadhan
RDS over IB does not use multipath RDS, so the array
of additional rds_conn_path structures is always superfluous
in this case. Reduce the memory footprint of the rds module
by making this a dynamic allocation predicated on whether
the transport is mp_capable.

Signed-off-by: Sowmini Varadhan 
Acked-by: Santosh Shilimkar 
Tested-by: Efrain Galaviz 
---
 net/rds/connection.c |   34 +-
 net/rds/rds.h|2 +-
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/net/rds/connection.c b/net/rds/connection.c
index 005bca6..7ee2d5d 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -151,6 +151,7 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
struct rds_transport *loop_trans;
unsigned long flags;
int ret, i;
+   int npaths = (trans->t_mp_capable ? RDS_MPATH_WORKERS : 1);
 
rcu_read_lock();
conn = rds_conn_lookup(net, head, laddr, faddr, trans);
@@ -172,6 +173,12 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
conn = ERR_PTR(-ENOMEM);
goto out;
}
+   conn->c_path = kcalloc(npaths, sizeof(struct rds_conn_path), gfp);
+   if (!conn->c_path) {
+   kmem_cache_free(rds_conn_slab, conn);
+   conn = ERR_PTR(-ENOMEM);
+   goto out;
+   }
 
INIT_HLIST_NODE(>c_hash_node);
conn->c_laddr = laddr;
@@ -181,6 +188,7 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
 
ret = rds_cong_get_maps(conn);
if (ret) {
+   kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
conn = ERR_PTR(ret);
goto out;
@@ -207,13 +215,14 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
conn->c_trans = trans;
 
init_waitqueue_head(>c_hs_waitq);
-   for (i = 0; i < RDS_MPATH_WORKERS; i++) {
+   for (i = 0; i < npaths; i++) {
__rds_conn_path_init(conn, >c_path[i],
 is_outgoing);
conn->c_path[i].cp_index = i;
}
ret = trans->conn_alloc(conn, gfp);
if (ret) {
+   kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
conn = ERR_PTR(ret);
goto out;
@@ -236,6 +245,7 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
/* Creating passive conn */
if (parent->c_passive) {
trans->conn_free(conn->c_path[0].cp_transport_data);
+   kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
conn = parent->c_passive;
} else {
@@ -252,7 +262,7 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
struct rds_conn_path *cp;
int i;
 
-   for (i = 0; i < RDS_MPATH_WORKERS; i++) {
+   for (i = 0; i < npaths; i++) {
cp = >c_path[i];
/* The ->conn_alloc invocation may have
 * allocated resource for all paths, so all
@@ -261,6 +271,7 @@ static void __rds_conn_path_init(struct rds_connection 
*conn,
if (cp->cp_transport_data)
trans->conn_free(cp->cp_transport_data);
}
+   kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
conn = found;
} else {
@@ -407,6 +418,7 @@ void rds_conn_destroy(struct rds_connection *conn)
unsigned long flags;
int i;
struct rds_conn_path *cp;
+   int npaths = (conn->c_trans->t_mp_capable ? RDS_MPATH_WORKERS : 1);
 
rdsdebug("freeing conn %p for %pI4 -> "
 "%pI4\n", conn, >c_laddr,
@@ -420,7 +432,7 @@ void rds_conn_destroy(struct rds_connection *conn)
synchronize_rcu();
 
/* shut the connection down */
-   for (i = 0; i < RDS_MPATH_WORKERS; i++) {
+   for (i = 0; i < npaths; i++) {
cp = >c_path[i];
rds_conn_path_destroy(cp);
BUG_ON(!list_empty(>cp_retrans));
@@ -434,6 +446,7 @@ void rds_conn_destroy(struct rds_connection *conn)
rds_cong_remove_conn(conn);
 
put_net(conn->c_net);
+   kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
 
spin_lock_irqsave(_conn_lock, flags);
@@ -464,8 +477,12 @@ static void rds_conn_message_info(struct socket *sock, 
unsigned int len,
 i++, head++) {
hlist_for_each_entry_rcu(conn, head, c_hash_node) {
struct rds_conn_path *cp;
+   int npaths;

Re: [PATCH v3 05/11] net: stmmac: dwmac-rk: Add internal phy support

2017-08-02 Thread Florian Fainelli
On 08/01/2017 11:21 PM, David Wu wrote:
> To make internal phy work, need to configure the phy_clock,
> phy cru_reset and related registers.
> 
> Signed-off-by: David Wu 
> ---
>  .../devicetree/bindings/net/rockchip-dwmac.txt |  6 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 81 
> ++
>  2 files changed, 86 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt 
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> index 8f42755..ec39b31 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -25,7 +25,8 @@ Required properties:
>   - clock-names: One name for each entry in the clocks property.
>   - phy-mode: See ethernet.txt file in the same directory.
>   - pinctrl-names: Names corresponding to the numbered pinctrl states.
> - - pinctrl-0: pin-control mode. can be <_pins> or <_pins>.
> + - pinctrl-0: pin-control mode. can be <_pins>, <_pins> or led 
> pins
> +   for internal phy mode.
>   - clock_in_out: For RGMII, it must be "input", means main clock(125MHz)
> is not sourced from SoC's PLL, but input from PHY; For RMII, "input" means
> PHY provides the reference clock(50MHz), "output" means GMAC provides the
> @@ -40,6 +41,9 @@ Optional properties:
>   - tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as 
> default.
>   - rx_delay: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as 
> default.
>   - phy-supply: phandle to a regulator if the PHY needs one
> + - clocks: < MAC_PHY>: Clock selector for internal macphy
> + - phy-is-internal: A boolean property allows us to know that MAC will 
> connect to
> +   internal phy.

This is incorrect in two ways:

- this is a property of the PHY, so it should be documented as such in
Documentation/devicetree/bindings/net/phy.txt so other bindings can
re-use it

- if it was specific to your MAC you would expect a vendor prefix to
this property, which is not there

An alternative way to implement the external/internal logic selection
would be mandate that your Ethernet PHY node have a compatible string
like this:

phy@0 {
compatible = "ethernet-phy-id1234.d400", "ethernet-phy-802.3-c22";
};

Then you don't need this phy-is-internal property, because you can
locate the PHY node by the phy-handle (see more about that in a reply to
patch 10) and you can determine ahead of time whether this PHY is
internal or not based on its compatible string.

Thank you

>  
>  Example:
>  
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index a8e8fd5..7b80ab9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -41,6 +41,7 @@ struct rk_gmac_ops {
>   void (*set_to_rmii)(struct rk_priv_data *bsp_priv);
>   void (*set_rgmii_speed)(struct rk_priv_data *bsp_priv, int speed);
>   void (*set_rmii_speed)(struct rk_priv_data *bsp_priv, int speed);
> + void (*internal_phy_powerup)(struct rk_priv_data *bsp_priv);
>  };
>  
>  struct rk_priv_data {
> @@ -52,6 +53,7 @@ struct rk_priv_data {
>  
>   bool clk_enabled;
>   bool clock_input;
> + bool internal_phy;
>  
>   struct clk *clk_mac;
>   struct clk *gmac_clkin;
> @@ -61,6 +63,9 @@ struct rk_priv_data {
>   struct clk *clk_mac_refout;
>   struct clk *aclk_mac;
>   struct clk *pclk_mac;
> + struct clk *clk_macphy;
> +
> + struct reset_control *macphy_reset;
>  
>   int tx_delay;
>   int rx_delay;
> @@ -750,6 +755,50 @@ static void rk3399_set_rmii_speed(struct rk_priv_data 
> *bsp_priv, int speed)
>   .set_rmii_speed = rk3399_set_rmii_speed,
>  };
>  
> +#define RK_GRF_MACPHY_CON0   0xb00
> +#define RK_GRF_MACPHY_CON1   0xb04
> +#define RK_GRF_MACPHY_CON2   0xb08
> +#define RK_GRF_MACPHY_CON3   0xb0c
> +
> +#define RK_MACPHY_ENABLE GRF_BIT(0)
> +#define RK_MACPHY_DISABLEGRF_CLR_BIT(0)
> +#define RK_MACPHY_CFG_CLK_50MGRF_BIT(14)
> +#define RK_GMAC2PHY_RMII_MODE(GRF_BIT(6) | GRF_CLR_BIT(7))
> +#define RK_GRF_CON2_MACPHY_IDHIWORD_UPDATE(0x1234, 0x, 0)
> +#define RK_GRF_CON3_MACPHY_IDHIWORD_UPDATE(0x35, 0x3f, 0)
> +
> +static void rk_gmac_internal_phy_powerup(struct rk_priv_data *priv)
> +{
> + if (priv->ops->internal_phy_powerup)
> + priv->ops->internal_phy_powerup(priv);
> +
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_CFG_CLK_50M);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_GMAC2PHY_RMII_MODE);
> +
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON2, RK_GRF_CON2_MACPHY_ID);
> + regmap_write(priv->grf, RK_GRF_MACPHY_CON3, RK_GRF_CON3_MACPHY_ID);
> +
> + if (priv->macphy_reset) {
> + /* macphy needs to be disabled 

Re: [PATCH V2] hyperv: netvsc: Neaten netvsc_send_pkt by using a temporary

2017-08-02 Thread David Miller
From: Joe Perches 
Date: Mon, 31 Jul 2017 10:30:54 -0700

> Repeated dereference of nvmsg.msg.v1_msg.send_rndis_pkt can be
> shortened by using a temporary.  Do so.
> 
> No change in object code.
> 
> Miscellanea:
> 
> o Use * const for rpkt and nvchan
> 
> Signed-off-by: Joe Perches 

Applied to net-next.


Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread Mason
On 02/08/2017 18:10, Måns Rullgård wrote:

> ping -f is limited to 100 packets per second.
> Use something like iperf in UDP mode instead.

CLIENT: DESKTOP
# iperf3 -c 172.27.64.45 -u -b 950M
Connecting to host 172.27.64.45, port 5201
[  4] local 172.27.64.1 port 55533 connected to 172.27.64.45 port 5201
[ ID] Interval   Transfer Bandwidth   Total Datagrams
[  4]   0.00-1.00   sec   102 MBytes   858 Mbits/sec  13091  
[  4]   1.00-2.00   sec   114 MBytes   953 Mbits/sec  14541  
[  4]   2.00-3.00   sec   114 MBytes   953 Mbits/sec  14542  
[  4]   3.00-4.00   sec   114 MBytes   953 Mbits/sec  14541  
[  4]   4.00-5.00   sec   114 MBytes   953 Mbits/sec  14542  
[  4]   5.00-6.00   sec   114 MBytes   953 Mbits/sec  14541  
[  4]   6.00-7.00   sec   114 MBytes   953 Mbits/sec  14535  
[  4]   7.00-8.00   sec   114 MBytes   953 Mbits/sec  14536  
[  4]   8.00-9.00   sec   114 MBytes   953 Mbits/sec  14543  
[  4]   9.00-10.00  sec   114 MBytes   953 Mbits/sec  14541  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  4]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec  0.247 ms  132176/143788 
(92%)  
[  4] Sent 143788 datagrams

iperf Done.


SERVER: TANGO BOARD
# iperf3 -s
Accepted connection from 172.27.64.1, port 44995
[  5] local 172.27.64.45 port 5201 connected to 172.27.64.1 port 55533
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  5]   0.00-1.00   sec  7.90 MBytes  66.2 Mbits/sec  0.218 ms  11365/12376 
(92%)  
[  5]   1.00-2.00   sec  9.13 MBytes  76.6 Mbits/sec  0.230 ms  13381/14550 
(92%)  
[  5]   2.00-3.00   sec  9.12 MBytes  76.5 Mbits/sec  0.290 ms  13372/14540 
(92%)  
[  5]   3.00-4.00   sec  9.11 MBytes  76.4 Mbits/sec  0.292 ms  13369/14535 
(92%)  
[  5]   4.00-5.00   sec  9.18 MBytes  77.0 Mbits/sec  0.178 ms  13374/14549 
(92%)  
[  5]   5.00-6.00   sec  9.10 MBytes  76.3 Mbits/sec  0.228 ms  13367/14532 
(92%)  
[  5]   6.00-7.00   sec  9.26 MBytes  77.7 Mbits/sec  0.607 ms  13356/14541 
(92%)  
[  5]   7.00-8.00   sec  9.23 MBytes  77.4 Mbits/sec  0.507 ms  13364/14545 
(92%)  
[  5]   8.00-9.00   sec  9.20 MBytes  77.1 Mbits/sec  0.215 ms  13351/14528 
(92%)  
[  5]   9.00-10.00  sec  9.16 MBytes  76.9 Mbits/sec  0.188 ms  13356/14529 
(92%)  
[  5]  10.00-10.04  sec   336 KBytes  72.2 Mbits/sec  0.247 ms  521/563 (93%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec  0.247 ms  132176/143788 
(92%)  


There is some packet loss, but the board doesn't lose connectivity.

With smaller packets...

# iperf3 -c 172.27.64.45 -u -b 950M -l 800
Connecting to host 172.27.64.45, port 5201
[  4] local 172.27.64.1 port 35197 connected to 172.27.64.45 port 5201
[ ID] Interval   Transfer Bandwidth   Total Datagrams
[  4]   0.00-1.00   sec  90.6 MBytes   760 Mbits/sec  118724  
[  4]   1.00-2.00   sec   107 MBytes   894 Mbits/sec  139718  
[  4]   2.00-3.00   sec   106 MBytes   889 Mbits/sec  138918  
[  4]   3.00-4.00   sec   107 MBytes   895 Mbits/sec  139768  
[  4]   4.00-5.00   sec   106 MBytes   891 Mbits/sec  139275  
[  4]   5.00-6.00   sec   107 MBytes   895 Mbits/sec  139862  
[  4]   6.00-7.00   sec   107 MBytes   895 Mbits/sec  139825  
[  4]   7.00-8.00   sec   107 MBytes   895 Mbits/sec  139775  
[  4]   8.00-9.00   sec   107 MBytes   895 Mbits/sec  139849  
[  4]   9.00-10.00  sec   107 MBytes   895 Mbits/sec  139835  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  4]   0.00-10.00  sec  1.02 GBytes   880 Mbits/sec  0.009 ms  564117/1375520 
(41%)  
[  4] Sent 1375520 datagrams

iperf Done.


Accepted connection from 172.27.64.1, port 46151
[  5] local 172.27.64.45 port 5201 connected to 172.27.64.1 port 35197
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  5]   0.00-1.00   sec  60.8 MBytes   510 Mbits/sec  0.004 ms  33508/113252 
(30%)  
iperf3: OUT OF ORDER - incoming packet = 147146 and received packet = 0 AND SP 
= 147497
iperf3: OUT OF ORDER - incoming packet = 146128 and received packet = 0 AND SP 
= 147690
iperf3: OUT OF ORDER - incoming packet = 146067 and received packet = 0 AND SP 
= 147863
iperf3: OUT OF ORDER - incoming packet = 147242 and received packet = 0 AND SP 
= 148039
iperf3: OUT OF ORDER - incoming packet = 163837 and received packet = 0 AND SP 
= 164363
[  5]   1.00-2.00   sec  61.0 MBytes   511 Mbits/sec  0.198 ms  59635/139649 
(43%)  
iperf3: OUT OF ORDER - incoming packet = 286437 and received packet = 0 AND SP 
= 287226
iperf3: OUT OF ORDER - incoming packet = 302990 and received packet = 0 AND SP 
= 305710
[  5]   2.00-3.00   sec  61.5 MBytes   517 Mbits/sec  0.005 ms  58369/138944 
(42%)  
iperf3: OUT OF ORDER - incoming packet 

Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan

2017-08-02 Thread Cong Wang
Hi, Gao

On Tue, Aug 1, 2017 at 1:39 PM, Cong Wang  wrote:
> From my understanding, this RCU is supposed to protect the pppox_sock
> pointers in 'callid_sock' which could be NULL'ed in del_chan(). And the
> pppox_sock is freed when the last refcnt is gone, that is, when sock
> dctor is called. pptp_release() is ONLY called when the fd in user-space
> is gone, not necessarily the last refcnt.

Your commit is probably not the right fix. Can you try the following fix?

diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
index 6dde9a0cfe76..e75bb95c107f 100644
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -519,7 +519,6 @@ static int pptp_release(struct socket *sock)

po = pppox_sk(sk);
del_chan(po);
-   synchronize_rcu();

pppox_unbind_sock(sk);
sk->sk_state = PPPOX_DEAD;
@@ -564,6 +563,7 @@ static int pptp_create(struct net *net, struct
socket *sock, int kern)
sk->sk_family  = PF_PPPOX;
sk->sk_protocol= PX_PROTO_PPTP;
sk->sk_destruct= pptp_sock_destruct;
+   sock_set_flag(sk, SOCK_RCU_FREE);

po = pppox_sk(sk);
opt = >proto.pptp;


NetDev 2.2 Call for Papers Announced!

2017-08-02 Thread David Miller

Talk submissions are now open for netdev-2.2 in Seoul Korea.

http://www.netdevconf.org/2.2/submit-proposal.html

The dealine for submissions is September 20th, so please do not delay
so that we can put the schedule together in a timely fashion.

We are all looking forward to seeing everyone in Seoul in November!


net: thunderx: Buffer overwrite on bgx_probe

2017-08-02 Thread Anton Vasilyev

Hello.

While searching for memory errors in Linux kernel I've come across
drivers/net/ethernet/cavium/thunder/thunder_bgx.ko module.

I've found buffer overwrite at bgx_probe():
Consider device PCI_SUBSYS_DEVID_83XX_BGX.
max_bgx_per_node is set to 4 by set_max_bgx_per_node().
Then on branch:
pci_read_config_word(pdev, PCI_DEVICE_ID, );
if (sdevid != PCI_DEVICE_ID_THUNDER_RGX) {
bgx->bgx_id = (pci_resource_start(pdev,
PCI_CFG_REG_BAR_NUM) >> 24) & BGX_ID_MASK;
bgx->bgx_id += nic_get_node_id(pdev) * max_bgx_per_node;

bgx->bgx_id could achieve value 3 + 3 * 4 = 15,
which lead to buffer overwrite on
bgx_vnic[bgx->bgx_id] = bgx;

Question: is it enough for fix to change bgx_vnic's size?

Found by Linux Driver Verification project (linuxtesting.org).

--
Anton Vasilyev
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: vasil...@ispras.ru



Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread Måns Rullgård
Mason  writes:

> On 02/08/2017 18:10, Måns Rullgård wrote:
>
>> Mason writes:
>> 
>>> On 02/08/2017 17:56, Måns Rullgård wrote:
>>>
 What does the tango5 do if you flood it with packets faster than the
 kernel can keep up with?  That would make it hit the end of the rx
 chain, which is apparently what makes it miserable with the current dma
 stop code.
>>>
>>> The simplest way to test this would be sending tiny packets
>>> as fast as possible, right? So ping -f on a GigE link should
>>> fit the bill?
>> 
>> ping -f is limited to 100 packets per second.  Use something like iperf
>> in UDP mode instead.
>
> ping -f can go 100 times faster than 100 pps:
>
> # ping -f -q -c 15 -s 300 172.27.64.45
> PING 172.27.64.45 (172.27.64.45) 300(328) bytes of data.
>
> --- 172.27.64.45 ping statistics ---
> 15 packets transmitted, 15 received, 0% packet loss, time 15035ms
> rtt min/avg/max/mdev = 0.065/0.084/0.537/0.014 ms, ipg/ewma 0.100/0.087 ms
>
> 150,000 packets in 15 seconds = 10,000 pps
>
> (172.27.64.45 is the tango5 board)
>
> Ergo, dealing with 10,000 packets per second does not hose RX.

ping -f goes as fast as the other end replies or 100 per second,
whichever is higher, so says the man page.

-- 
Måns Rullgård


Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread Mason
On 02/08/2017 18:10, Måns Rullgård wrote:

> Mason writes:
> 
>> On 02/08/2017 17:56, Måns Rullgård wrote:
>>
>>> What does the tango5 do if you flood it with packets faster than the
>>> kernel can keep up with?  That would make it hit the end of the rx
>>> chain, which is apparently what makes it miserable with the current dma
>>> stop code.
>>
>> The simplest way to test this would be sending tiny packets
>> as fast as possible, right? So ping -f on a GigE link should
>> fit the bill?
> 
> ping -f is limited to 100 packets per second.  Use something like iperf
> in UDP mode instead.

ping -f can go 100 times faster than 100 pps:

# ping -f -q -c 15 -s 300 172.27.64.45
PING 172.27.64.45 (172.27.64.45) 300(328) bytes of data.

--- 172.27.64.45 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 15035ms
rtt min/avg/max/mdev = 0.065/0.084/0.537/0.014 ms, ipg/ewma 0.100/0.087 ms


150,000 packets in 15 seconds = 10,000 pps

(172.27.64.45 is the tango5 board)

Ergo, dealing with 10,000 packets per second does not hose RX.

Regards.


RE: [PATCH V4 net-next 1/8] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC

2017-08-02 Thread Salil Mehta
Hi Florian,

> -Original Message-
> From: Salil Mehta
> Sent: Thursday, July 27, 2017 9:45 PM
> To: 'Florian Fainelli'; da...@davemloft.net
> Cc: Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-r...@vger.kernel.org; Linuxarm
> Subject: RE: [PATCH V4 net-next 1/8] net: hns3: Add support of HNS3
> Ethernet Driver for hip08 SoC
> 
> Hi Florian,
> 
> > -Original Message-
> > From: Florian Fainelli [mailto:f.faine...@gmail.com]
> > Sent: Sunday, July 23, 2017 6:24 PM
> > To: Salil Mehta; da...@davemloft.net
> > Cc: Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> > mehta.salil@gmail.com; netdev@vger.kernel.org; linux-
> > ker...@vger.kernel.org; linux-r...@vger.kernel.org; Linuxarm
> > Subject: Re: [PATCH V4 net-next 1/8] net: hns3: Add support of HNS3
> > Ethernet Driver for hip08 SoC
> >
> >
> >
> > On 07/22/2017 03:09 PM, Salil Mehta wrote:
> > > This patch adds the support of Hisilicon Network Subsystem 3
> > > Ethernet driver to hip08 family of SoCs.
> > >
> > > This driver includes basic Rx/Tx functionality. It also includes
> > > the client registration code with the HNAE3(Hisilicon Network
> > > Acceleration Engine 3) framework.
> > >
> > > This work provides the initial support to the hip08 SoC and
> > > would incrementally add features or enhancements.
> > >
> > > Signed-off-by: Daode Huang 
> > > Signed-off-by: lipeng 
> > > Signed-off-by: Salil Mehta 
> > > Signed-off-by: Yisen Zhuang 

[...]

> 
> >
> > > + hns3_nic_reclaim_one_desc(ring, , );
> > > + /* Issue prefetch for next Tx descriptor */
> > > + prefetch(>desc_cb[ring->next_to_clean]);
> > > + budget--;
> > > + }
> > > +
> > > + ring->tqp_vector->tx_group.total_bytes += bytes;
> > > + ring->tqp_vector->tx_group.total_packets += pkts;
> > > +
> > > + dev_queue = netdev_get_tx_queue(netdev, ring->tqp->tqp_index);
> > > + netdev_tx_completed_queue(dev_queue, pkts, bytes);
> >
> > Where is flow control happening? Should not you wake the transmit
> queue
> > if you had to stop it somehow?
> Forgive me, I could not get this part. Flow control of what?
As discussed with you earlier, I have fixed the queue wakeup part
in Patch V6. Please have a look at it. Thanks!

Best regards 
Salil
> 
> 
> >
> > I kind of stopped reviewing here.
> > --
> > Florian


[PATCH] ipv4: Introduce ipip_offload_init helper function.

2017-08-02 Thread Tonghao Zhang
It's convenient to init ipip offload. We will check
the return value, and print KERN_CRIT info on failure.

Signed-off-by: Tonghao Zhang 
---
 net/ipv4/af_inet.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 5ce44fb..c888120 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1763,6 +1763,11 @@ static int __init init_inet_pernet_ops(void)
},
 };
 
+static int __init ipip_offload_init(void)
+{
+   return inet_add_offload(_offload, IPPROTO_IPIP);
+}
+
 static int __init ipv4_offload_init(void)
 {
/*
@@ -1772,9 +1777,10 @@ static int __init ipv4_offload_init(void)
pr_crit("%s: Cannot add UDP protocol offload\n", __func__);
if (tcpv4_offload_init() < 0)
pr_crit("%s: Cannot add TCP protocol offload\n", __func__);
+   if (ipip_offload_init() < 0)
+   pr_crit("%s: Cannot add IPIP protocol offload\n", __func__);
 
dev_add_offload(_packet_offload);
-   inet_add_offload(_offload, IPPROTO_IPIP);
return 0;
 }
 
-- 
1.8.3.1



RE: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread David Laight
From: Måns Rullgård
> Sent: 02 August 2017 17:10
...
> ping -f is limited to 100 packets per second.  Use something like iperf
> in UDP mode instead.

Or break a MAC driver so it just saturates the network.

You might actually need bursts of traffic - otherwise the receiver
will be continuously out of rx buffers and no dma will be active.

David



Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread Måns Rullgård
Mason  writes:

> On 02/08/2017 17:56, Måns Rullgård wrote:
>
>> Mason writes:
>> 
>>> From my perspective, the older method does not work on newer chips :-)
>> 
>> It does work on tango4.
>
> Agreed.
>
>> What does the tango5 do if you flood it with packets faster than the
>> kernel can keep up with?  That would make it hit the end of the rx
>> chain, which is apparently what makes it miserable with the current dma
>> stop code.
>
> The simplest way to test this would be sending tiny packets
> as fast as possible, right? So ping -f on a GigE link should
> fit the bill?

ping -f is limited to 100 packets per second.  Use something like iperf
in UDP mode instead.

-- 
Måns Rullgård


Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

2017-08-02 Thread Mason
On 02/08/2017 17:56, Måns Rullgård wrote:

> Mason writes:
> 
>> From my perspective, the older method does not work on newer chips :-)
> 
> It does work on tango4.

Agreed.

> What does the tango5 do if you flood it with packets faster than the
> kernel can keep up with?  That would make it hit the end of the rx
> chain, which is apparently what makes it miserable with the current dma
> stop code.

The simplest way to test this would be sending tiny packets
as fast as possible, right? So ping -f on a GigE link should
fit the bill?

Regards.


Re: [PATCH net-next] bpf: fix the printing of ifindex

2017-08-02 Thread John Fastabend
On 08/02/2017 08:43 AM, William Tu wrote:
> Save the ifindex before it gets zeroed so the invalid
> ifindex can be printed out.
> 
> Signed-off-by: William Tu 
> ---


Thanks!

Acked-by: John Fastabend 



[PATCH V6 net-next 0/8] Hisilicon Network Subsystem 3 Ethernet Driver

2017-08-02 Thread Salil Mehta
This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3)
Ethernet driver for hip08 family of SoCs and future upcoming SoCs.

Hisilicon's new hip08 SoCs have integrated ethernet based on PCI Express and
hence there was a need of new driver over the previous HNS driver which is 
already part of the Linux mainline. This new driver is NOT backward
compatible with HNS.

This current driver is meant to control the Physical Function and there would
soon be a support of a separate driver for Virtual Function once this base PF
driver has been accepted. Also, this driver is the ongoing development work and
HNS3 Ethernet driver would be incrementally enhanced with more new features.

High Level Architecture:

[ Ethtool ]
   ^  |
   |  | 
 [Ethernet Client]  [ODP/UIO Client] . . . [ RoCE Client ] 
 ||
   [ HNAE Device ]|
 ||
- |
 ||
 [ HNAE3 Framework (Register/unregister) ]|
 ||
- |
 ||
   [ HCLGE Layer] |
 |_   |
|| |  |
[ MDIO ][ Scheduler/Shaper ]  [ Debugfs* ]|
|| |  |
||_|  | 
 ||
 [ IMP command Interface ]|
- |
  HIP08  H A R D W A R E  *


Current patch-set broadly adds the support of the following PF functionality:
 1. Basic Rx and Tx functionality 
 2. TSO support
 3. Ethtool support
 4. * Debugfs support -> this patch for now has been taken off.
 5. HNAE framework and hardware compatability layer
 6. Scheduler and Shaper support in transmit function
 7. MDIO support

Change Log:
V5->V6: Addressed below comments:
* Andrew Lunn: Comments on MDIO and ethtool link mode
* Leon Romanvosky: Some comments on HNAE layer tidy-up
* Internal comments on redundant code removal, fixing error types etc.
V4->V5: Addressed below concerns:
* Florian Fanelli: Miscellaneous comments on ethtool & enet layer
* Stephen Hemminger: comment of Netdev stats in ethool layer
* Leon Romanvosky: Comments on Driver Version String, naming & Kconfig
* Rochard Cochran: Redundant function prototype 
V3->V4: Addressed below comments:
* Andrew Lunn: Various comments on MDIO, ethtool, ENET driver etc,
* Stephen Hemminger: change access and updation to 64 but statistics
* Bo You: some spelling mistakes and checkpatch.pl errors.
V2->V3: Addressed comments
* Yuval Mintz: Removal of redundant userprio-to-tc code
* Stephen Hemminger: Ethtool & interuupt enable
* Andrew Lunn: On C45/C22 PHy support, HNAE, ethtool
* Florian Fainelli: C45/C22 and phy_connect/attach
* Intel kbuild errors
V1->V2: Addressed some comments by kbuild, Yuval MIntz, Andrew Lunn &
Florian Fainelli in the following patches:
* Add support of HNS3 Ethernet Driver for hip08 SoC
* Add MDIO support to HNS3 Ethernet driver for hip08 SoC
* Add support of debugfs interface to HNS3 driver

Salil Mehta (8):
  net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC
  net: hns3: Add support of the HNAE3 framework
  net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support
  net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support
  net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver
  net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC
  net: hns3: Add Ethtool support to HNS3 driver
  net: hns3: Add HNS3 driver to kernel build framework & MAINTAINERS

 MAINTAINERS|8 +
 drivers/net/ethernet/hisilicon/Kconfig |   27 +
 drivers/net/ethernet/hisilicon/Makefile|1 +
 drivers/net/ethernet/hisilicon/hns3/Makefile   |7 +
 drivers/net/ethernet/hisilicon/hns3/hnae3.c|  300 ++
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  444 ++
 .../net/ethernet/hisilicon/hns3/hns3pf/Makefile|   11 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c |  356 ++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |  740 
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 4267 
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  519 +++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c|  213 +
 

[PATCH V6 net-next 2/8] net: hns3: Add support of the HNAE3 framework

2017-08-02 Thread Salil Mehta
This patch adds the support of the HNAE3 (Hisilicon Network
Acceleration Engine 3) framework support to the HNS3 driver.

Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE
and user-space Ethernet drivers (like ODP etc.) to register with HNAE3
devices and their associated operations.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
---
Patch V6: Addressed following comments
  1. Leon Romanovsky
 https://lkml.org/lkml/2017/7/30/87
Patch V5: Addressed following comments
  1. Leon Romanovsky
 https://lkml.org/lkml/2017/7/23/67
Patch V4: Addressed following comments
  1. Andrew Lunn
 https://lkml.org/lkml/2017/6/17/233
 https://lkml.org/lkml/2017/6/18/105
  2. Bo Yu
 https://lkml.org/lkml/2017/6/18/112
  3. Stephen Hamminger
 https://lkml.org/lkml/2017/6/19/778
Patch V3: Addressed below comments
  1. Andrew Lunn
 https://lkml.org/lkml/2017/6/13/1025
Patch V2: No change
Patch V1: Initial Submit
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.c | 300 +++
 drivers/net/ethernet/hisilicon/hns3/hnae3.h | 444 
 2 files changed, 744 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hnae3.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hnae3.h

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
new file mode 100644
index 000..59efbd6
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -0,0 +1,300 @@
+/*
+ * Copyright (c) 2016-2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include "hnae3.h"
+
+static LIST_HEAD(hnae3_ae_algo_list);
+static LIST_HEAD(hnae3_client_list);
+static LIST_HEAD(hnae3_ae_dev_list);
+
+/* we are keeping things simple and using single lock for all the
+ * list. This is a non-critical code so other updations, if happen
+ * in parallel, can wait.
+ */
+static DEFINE_MUTEX(hnae3_common_lock);
+
+static bool hnae3_client_match(enum hnae3_client_type client_type,
+  enum hnae3_dev_type dev_type)
+{
+   if ((dev_type == HNAE3_DEV_KNIC) && (client_type == HNAE3_CLIENT_KNIC ||
+client_type == HNAE3_CLIENT_ROCE))
+   return true;
+
+   if (dev_type == HNAE3_DEV_UNIC && client_type == HNAE3_CLIENT_UNIC)
+   return true;
+
+   return false;
+}
+
+static int hnae3_match_n_instantiate(struct hnae3_client *client,
+struct hnae3_ae_dev *ae_dev,
+bool is_reg, bool *matched)
+{
+   int ret;
+
+   *matched = false;
+
+   /* check if this client matches the type of ae_dev */
+   if (!(hnae3_client_match(client->type, ae_dev->dev_type) &&
+ hnae_get_bit(ae_dev->flag, HNAE3_DEV_INITED_B))) {
+   return 0;
+   }
+   /* there is a match of client and dev */
+   *matched = true;
+
+   /* now, (un-)instantiate client by calling lower layer */
+   if (is_reg) {
+   ret = ae_dev->ops->init_client_instance(client, ae_dev);
+   if (ret)
+   dev_err(_dev->pdev->dev,
+   "fail to instantiate client\n");
+   return ret;
+   }
+
+   ae_dev->ops->uninit_client_instance(client, ae_dev);
+   return 0;
+}
+
+int hnae3_register_client(struct hnae3_client *client)
+{
+   struct hnae3_client *client_tmp;
+   struct hnae3_ae_dev *ae_dev;
+   bool matched;
+   int ret = 0;
+
+   mutex_lock(_common_lock);
+   /* one system should only have one client for every type */
+   list_for_each_entry(client_tmp, _client_list, node) {
+   if (client_tmp->type == client->type)
+   goto exit;
+   }
+
+   list_add_tail(>node, _client_list);
+
+   /* initialize the client on every matched port */
+   list_for_each_entry(ae_dev, _ae_dev_list, node) {
+   /* if the client could not be initialized on current port, for
+* any error reasons, move on to next available port
+*/
+   ret = hnae3_match_n_instantiate(client, ae_dev, true, );
+   if (ret)
+   dev_err(_dev->pdev->dev,
+   "match and instantiation failed for port\n");
+   }
+
+exit:
+   mutex_unlock(_common_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL(hnae3_register_client);
+
+void hnae3_unregister_client(struct hnae3_client *client)
+{
+   struct 

[PATCH V6 net-next 3/8] net: hns3: Add HNS3 IMP(Integrated Mgmt Proc) Cmd Interface Support

2017-08-02 Thread Salil Mehta
This patch adds the support of IMP (Integrated Management Processor)
command interface to the HNS3 driver.

Each PF/VF has support of CQP(Command Queue Pair) ring interface.
Each CQP consis of send queue CSQ and receive queue CRQ.
There are various commands a PF/VF may support, like for Flow Table
manipulation, Device management, Packet buffer allocation, Forwarding,
VLANs config, Tunneling/Overlays etc.

This patch contains code to initialize the command queue, manage the
command queue descriptors and Rx/Tx protocol with the command processor
in the form of various commands/results and acknowledgements.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
---
Patch V6: Addressed some internal comments
  1. removed redundant function hclge_cmd_reuse_desc()
Patch V2,V5: No change over Patch V1
Patch V1: Initial Submit
---
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 356 ++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 740 +
 2 files changed, 1096 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
new file mode 100644
index 000..bc86984
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -0,0 +1,356 @@
+/*
+ * Copyright (c) 2016~2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "hclge_cmd.h"
+#include "hnae3.h"
+#include "hclge_main.h"
+
+#define hclge_is_csq(ring) ((ring)->flag & HCLGE_TYPE_CSQ)
+#define hclge_ring_to_dma_dir(ring) (hclge_is_csq(ring) ? \
+   DMA_TO_DEVICE : DMA_FROM_DEVICE)
+#define cmq_ring_to_dev(ring)   (&(ring)->dev->pdev->dev)
+
+static int hclge_ring_space(struct hclge_cmq_ring *ring)
+{
+   int ntu = ring->next_to_use;
+   int ntc = ring->next_to_clean;
+   int used = (ntu - ntc + ring->desc_num) % ring->desc_num;
+
+   return ring->desc_num - used - 1;
+}
+
+static int hclge_alloc_cmd_desc(struct hclge_cmq_ring *ring)
+{
+   int size  = ring->desc_num * sizeof(struct hclge_desc);
+
+   ring->desc = kzalloc(size, GFP_KERNEL);
+   if (!ring->desc)
+   return -ENOMEM;
+
+   ring->desc_dma_addr = dma_map_single(cmq_ring_to_dev(ring), ring->desc,
+size, DMA_BIDIRECTIONAL);
+   if (dma_mapping_error(cmq_ring_to_dev(ring), ring->desc_dma_addr)) {
+   ring->desc_dma_addr = 0;
+   kfree(ring->desc);
+   ring->desc = NULL;
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+static void hclge_free_cmd_desc(struct hclge_cmq_ring *ring)
+{
+   dma_unmap_single(cmq_ring_to_dev(ring), ring->desc_dma_addr,
+ring->desc_num * sizeof(ring->desc[0]),
+DMA_BIDIRECTIONAL);
+
+   ring->desc_dma_addr = 0;
+   kfree(ring->desc);
+   ring->desc = NULL;
+}
+
+static int hclge_init_cmd_queue(struct hclge_dev *hdev, int ring_type)
+{
+   struct hclge_hw *hw = >hw;
+   struct hclge_cmq_ring *ring =
+   (ring_type == HCLGE_TYPE_CSQ) ? >cmq.csq : >cmq.crq;
+   int ret;
+
+   ring->flag = ring_type;
+   ring->dev = hdev;
+
+   ret = hclge_alloc_cmd_desc(ring);
+   if (ret) {
+   dev_err(>pdev->dev, "descriptor %s alloc error %d\n",
+   (ring_type == HCLGE_TYPE_CSQ) ? "CSQ" : "CRQ", ret);
+   return ret;
+   }
+
+   ring->next_to_clean = 0;
+   ring->next_to_use = 0;
+
+   return 0;
+}
+
+void hclge_cmd_setup_basic_desc(struct hclge_desc *desc,
+   enum hclge_opcode_type opcode, bool is_read)
+{
+   memset((void *)desc, 0, sizeof(struct hclge_desc));
+   desc->opcode = cpu_to_le16(opcode);
+   desc->flag = cpu_to_le16(HCLGE_CMD_FLAG_NO_INTR | HCLGE_CMD_FLAG_IN);
+
+   if (is_read)
+   desc->flag |= cpu_to_le16(HCLGE_CMD_FLAG_WR);
+   else
+   desc->flag &= cpu_to_le16(~HCLGE_CMD_FLAG_WR);
+}
+
+static void hclge_cmd_config_regs(struct hclge_cmq_ring *ring)
+{
+   dma_addr_t dma = ring->desc_dma_addr;
+   struct hclge_dev *hdev = ring->dev;
+   struct hclge_hw *hw = >hw;
+
+   if (ring->flag == HCLGE_TYPE_CSQ) {
+   hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_L_REG,
+   (u32)dma);
+   

[PATCH V6 net-next 1/8] net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC

2017-08-02 Thread Salil Mehta
This patch adds the support of Hisilicon Network Subsystem 3
Ethernet driver to hip08 family of SoCs.

This driver includes basic Rx/Tx functionality. It also includes
the client registration code with the HNAE3(Hisilicon Network
Acceleration Engine 3) framework.

This work provides the initial support to the hip08 SoC and
would incrementally add features or enhancements.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
Signed-off-by: Wei Hu (Xavier) 
---
Patch V6: addressed comments by:
  1. Florian Fainelli
 https://lkml.org/lkml/2017/7/23/100
 (Tx Queue wakeup logic)
  2. Internal comments
Patch V5: addressed comments by:
  1. Florian Fainelli
 https://lkml.org/lkml/2017/7/23/100
Patch V4: addressed comments by:
  1. Andrew Lunn
 https://lkml.org/lkml/2017/6/17/222
 https://lkml.org/lkml/2017/6/17/232
  2. Bo Yu:
 https://lkml.org/lkml/2017/6/18/110
 https://lkml.org/lkml/2017/6/18/115
Patch V3: Addresed below comments:
  1. Stephen Hemminger
 https://lkml.org/lkml/2017/6/13/972
  2. Yuval Mintz
 https://lkml.org/lkml/2017/6/14/151
Patch V2: Addressed below comments:
  1. Kbuild
 https://lkml.org/lkml/2017/6/11/73
  2. Yuval Mintz
 https://lkml.org/lkml/2017/6/10/78
Patch V1: Initial Submit
---
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2848 
 .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h |  592 
 2 files changed, 3440 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.h

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
new file mode 100644
index 000..ad9481c
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -0,0 +1,2848 @@
+/*
+ * Copyright (c) 2016~2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hnae3.h"
+#include "hns3_enet.h"
+
+const char hns3_driver_name[] = "hns3";
+const char hns3_driver_version[] = VERMAGIC_STRING;
+static const char hns3_driver_string[] =
+   "Hisilicon Ethernet Network Driver for Hip08 Family";
+static const char hns3_copyright[] = "Copyright (c) 2017 Huawei Corporation.";
+static struct hnae3_client client;
+
+/* hns3_pci_tbl - PCI Device ID Table
+ *
+ * Last entry must be all 0s
+ *
+ * { Vendor ID, Device ID, SubVendor ID, SubDevice ID,
+ *   Class, Class Mask, private data (not used) }
+ */
+static const struct pci_device_id hns3_pci_tbl[] = {
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_GE), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA_MACSEC), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_50GE_RDMA), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_50GE_RDMA_MACSEC), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_100G_RDMA_MACSEC), 0},
+   /* required last entry */
+   {0, }
+};
+MODULE_DEVICE_TABLE(pci, hns3_pci_tbl);
+
+static irqreturn_t hns3_irq_handle(int irq, void *dev)
+{
+   struct hns3_enet_tqp_vector *tqp_vector = dev;
+
+   napi_schedule(_vector->napi);
+
+   return IRQ_HANDLED;
+}
+
+static void hns3_nic_uninit_irq(struct hns3_nic_priv *priv)
+{
+   struct hns3_enet_tqp_vector *tqp_vectors;
+   unsigned int i;
+
+   for (i = 0; i < priv->vector_num; i++) {
+   tqp_vectors = >tqp_vector[i];
+
+   if (tqp_vectors->irq_init_flag != HNS3_VECTOR_INITED)
+   continue;
+
+   /* release the irq resource */
+   free_irq(tqp_vectors->vector_irq, tqp_vectors);
+   tqp_vectors->irq_init_flag = HNS3_VECTOR_NOT_INITED;
+   }
+}
+
+static int hns3_nic_init_irq(struct hns3_nic_priv *priv)
+{
+   struct hns3_enet_tqp_vector *tqp_vectors;
+   int txrx_int_idx = 0;
+   int rx_int_idx = 0;
+   int tx_int_idx = 0;
+   unsigned int i;
+   int ret;
+
+   for (i = 0; i < priv->vector_num; i++) {
+   tqp_vectors = >tqp_vector[i];
+
+   if (tqp_vectors->irq_init_flag == HNS3_VECTOR_INITED)
+   continue;
+
+   if (tqp_vectors->tx_group.ring && tqp_vectors->rx_group.ring) {
+   snprintf(tqp_vectors->name, HNAE3_INT_NAME_LEN - 1,
+

[PATCH V6 net-next 5/8] net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver

2017-08-02 Thread Salil Mehta
THis patch adds the support of the Scheduling and Shaping
functionalities during the transmit leg. This also adds the
support of Pause at MAC level. (Pause at per-priority level
shall be added later along with the DCB feature).

Hardware as such consists of two types of cofiguration of 6 level
schedulers. Algorithms varies according to the level and type
of scheduler being used. Current patch is used to initialize
the mapping, algorithms(like SP, DWRR etc) and shaper(CIR, PIR etc)
being used.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
Signed-off-by: Wei Hu (Xavier) 
---
Patch V6: Addressed some internal comments
   1. Fixed the return values from ENOMEM -> EINVAL
   2. renamed to __HCLGE_TM_H macro in header file
Patch V5: Addressed comments by
   1. Richard Cochran
  https://lkml.org/lkml/2017/7/23/13
Patch V2,V4: No Change
Patch V1: Initial Submit
---
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c  | 1015 
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h  |  106 ++
 2 files changed, 1121 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
new file mode 100644
index 000..1c577d2
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -0,0 +1,1015 @@
+/*
+ * Copyright (c) 2016~2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+
+#include "hclge_cmd.h"
+#include "hclge_main.h"
+#include "hclge_tm.h"
+
+enum hclge_shaper_level {
+   HCLGE_SHAPER_LVL_PRI= 0,
+   HCLGE_SHAPER_LVL_PG = 1,
+   HCLGE_SHAPER_LVL_PORT   = 2,
+   HCLGE_SHAPER_LVL_QSET   = 3,
+   HCLGE_SHAPER_LVL_CNT= 4,
+   HCLGE_SHAPER_LVL_VF = 0,
+   HCLGE_SHAPER_LVL_PF = 1,
+};
+
+#define HCLGE_SHAPER_BS_U_DEF  1
+#define HCLGE_SHAPER_BS_S_DEF  4
+
+#define HCLGE_ETHER_MAX_RATE   10
+
+/* hclge_shaper_para_calc: calculate ir parameter for the shaper
+ * @ir: Rate to be config, its unit is Mbps
+ * @shaper_level: the shaper level. eg: port, pg, priority, queueset
+ * @ir_b: IR_B parameter of IR shaper
+ * @ir_u: IR_U parameter of IR shaper
+ * @ir_s: IR_S parameter of IR shaper
+ *
+ * the formula:
+ *
+ * IR_b * (2 ^ IR_u) * 8
+ * IR(Mbps) = -  *  CLOCK(1000Mbps)
+ * Tick * (2 ^ IR_s)
+ *
+ * @return: 0: calculate sucessful, negative: fail
+ */
+static int hclge_shaper_para_calc(u32 ir, u8 shaper_level,
+ u8 *ir_b, u8 *ir_u, u8 *ir_s)
+{
+   const u16 tick_array[HCLGE_SHAPER_LVL_CNT] = {
+   6 * 256,/* Prioriy level */
+   6 * 32, /* Prioriy group level */
+   6 * 8,  /* Port level */
+   6 * 256 /* Qset level */
+   };
+   u8 ir_u_calc = 0, ir_s_calc = 0;
+   u32 ir_calc;
+   u32 tick;
+
+   /* Calc tick */
+   if (shaper_level >= HCLGE_SHAPER_LVL_CNT)
+   return -EINVAL;
+
+   tick = tick_array[shaper_level];
+
+   /**
+* Calc the speed if ir_b = 126, ir_u = 0 and ir_s = 0
+* the formula is changed to:
+*  126 * 1 * 8
+* ir_calc =  * 1000
+*  tick * 1
+*/
+   ir_calc = (1008000 + (tick >> 1) - 1) / tick;
+
+   if (ir_calc == ir) {
+   *ir_b = 126;
+   *ir_u = 0;
+   *ir_s = 0;
+
+   return 0;
+   } else if (ir_calc > ir) {
+   /* Increasing the denominator to select ir_s value */
+   while (ir_calc > ir) {
+   ir_s_calc++;
+   ir_calc = 1008000 / (tick * (1 << ir_s_calc));
+   }
+
+   if (ir_calc == ir)
+   *ir_b = 126;
+   else
+   *ir_b = (ir * tick * (1 << ir_s_calc) + 4000) / 8000;
+   } else {
+   /* Increasing the numerator to select ir_u value */
+   u32 numerator;
+
+   while (ir_calc < ir) {
+   ir_u_calc++;
+   numerator = 1008000 * (1 << ir_u_calc);
+   ir_calc = (numerator + (tick >> 1)) / tick;
+   }
+
+   if (ir_calc == ir) {
+   *ir_b = 126;
+   } else {
+   u32 denominator = (8000 * (1 << 

[PATCH V6 net-next 4/8] net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support

2017-08-02 Thread Salil Mehta
This patch adds the support of Hisilicon Network Subsystem Accceleration
Engine and common operations to access it. This layer provides access to the
hardware configuration, hardware statistics. This layer is also
responsible for triggering the initialization of the PHY layer through
the below MDIO layer.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
Signed-off-by: Wei Hu (Xavier) 
---
Patch V6: Adressed below comments
  1. Andrew Lunn
 https://lkml.org/lkml/2017/7/28/742
 (moved prototypes from hclge_main.h -> hns3_mdio.h)
Patch V5:
  1. Fixes due to internal reviews
Patch V4:
  1. removed register_client/unregister_client wrapper functions
  2. name inconsistencies, changed variable name from phy_dev->phydev
 at some places
Patch V2,V3: No Change
Patch V1: Initial Submit
---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 4267 
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  519 +++
 2 files changed, 4786 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
new file mode 100644
index 000..3611991
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -0,0 +1,4267 @@
+/*
+ * Copyright (c) 2016-2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hclge_cmd.h"
+#include "hclge_main.h"
+#include "hclge_mdio.h"
+#include "hclge_tm.h"
+#include "hnae3.h"
+
+#define HCLGE_NAME "hclge"
+#define HCLGE_STATS_READ(p, offset) (*((u64 *)((u8 *)(p) + (offset
+#define HCLGE_MAC_STATS_FIELD_OFF(f) (offsetof(struct hclge_mac_stats, f))
+#define HCLGE_64BIT_STATS_FIELD_OFF(f) (offsetof(struct hclge_64_bit_stats, f))
+#define HCLGE_32BIT_STATS_FIELD_OFF(f) (offsetof(struct hclge_32_bit_stats, f))
+
+static int hclge_rss_init_hw(struct hclge_dev *hdev);
+static int hclge_set_mta_filter_mode(struct hclge_dev *hdev,
+enum hclge_mta_dmac_sel_type mta_mac_sel,
+bool enable);
+static int hclge_init_vlan_config(struct hclge_dev *hdev);
+
+static struct hnae3_ae_algo ae_algo;
+
+static const struct pci_device_id ae_algo_pci_tbl[] = {
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_GE), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA_MACSEC), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_50GE_RDMA), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_50GE_RDMA_MACSEC), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_100G_RDMA_MACSEC), 0},
+   /* Required last entry */
+   {0, }
+};
+
+static const struct pci_device_id roce_pci_tbl[] = {
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_25GE_RDMA_MACSEC), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_50GE_RDMA), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_50GE_RDMA_MACSEC), 0},
+   {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_100G_RDMA_MACSEC), 0},
+   /* Required last entry */
+   {0, }
+};
+
+static const char hns3_nic_test_strs[][ETH_GSTRING_LEN] = {
+   "MacLoopback test",
+   "Serdes Loopback test",
+   "PhyLoopback test"
+};
+
+static const struct hclge_comm_stats_str g_all_64bit_stats_string[] = {
+   {"igu_rx_oversize_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(igu_rx_oversize_pkt)},
+   {"igu_rx_undersize_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(igu_rx_undersize_pkt)},
+   {"igu_rx_out_all_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(igu_rx_out_all_pkt)},
+   {"igu_rx_uni_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(igu_rx_uni_pkt)},
+   {"igu_rx_multi_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(igu_rx_multi_pkt)},
+   {"igu_rx_broad_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(igu_rx_broad_pkt)},
+   {"egu_tx_out_all_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(egu_tx_out_all_pkt)},
+   {"egu_tx_uni_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(egu_tx_uni_pkt)},
+   {"egu_tx_multi_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(egu_tx_multi_pkt)},
+   {"egu_tx_broad_pkt",
+   HCLGE_64BIT_STATS_FIELD_OFF(egu_tx_broad_pkt)},
+   {"ssu_ppp_mac_key_num",

[PATCH V6 net-next 8/8] net: hns3: Add HNS3 driver to kernel build framework & MAINTAINERS

2017-08-02 Thread Salil Mehta
This patch updates the MAINTAINERS file with HNS3 Ethernet driver
maintainers names and other details. This also introduces the new
Makefiles required to build the HNS3 Ethernet driver and updates
the existing Kconfig file in the hisilicon folder.

Signed-off-by: Salil Mehta 
---
 MAINTAINERS|  8 +++
 drivers/net/ethernet/hisilicon/Kconfig | 27 ++
 drivers/net/ethernet/hisilicon/Makefile|  1 +
 drivers/net/ethernet/hisilicon/hns3/Makefile   |  7 ++
 .../net/ethernet/hisilicon/hns3/hns3pf/Makefile| 11 +
 5 files changed, 54 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/Makefile
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile

diff --git a/MAINTAINERS b/MAINTAINERS
index 207e453..6b990da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6148,6 +6148,14 @@ S:   Maintained
 F: drivers/net/ethernet/hisilicon/
 F: Documentation/devicetree/bindings/net/hisilicon*.txt
 
+HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3)
+M: Yisen Zhuang 
+M: Salil Mehta 
+L: netdev@vger.kernel.org
+W: http://www.hisilicon.com
+S: Maintained
+F: drivers/net/ethernet/hisilicon/hns3/
+
 HISILICON ROCE DRIVER
 M: Lijun Ou 
 M: Wei Hu(Xavier) 
diff --git a/drivers/net/ethernet/hisilicon/Kconfig 
b/drivers/net/ethernet/hisilicon/Kconfig
index d11287e..91c7bdb 100644
--- a/drivers/net/ethernet/hisilicon/Kconfig
+++ b/drivers/net/ethernet/hisilicon/Kconfig
@@ -76,4 +76,31 @@ config HNS_ENET
  This selects the general ethernet driver for HNS.  This module make
  use of any HNS AE driver, such as HNS_DSAF
 
+config HNS3
+   tristate "Hisilicon Network Subsystem Support HNS3 (Framework)"
+depends on PCI
+   ---help---
+ This selects the framework support for Hisilicon Network Subsystem 3.
+ This layer facilitates clients like ENET, RoCE and user-space ethernet
+ drivers(like ODP)to register with HNAE devices and their associated
+ operations.
+
+config HNS3_HCLGE
+   tristate "Hisilicon HNS3 HCLGE Acceleration Engine & Compatibility 
Layer Support"
+depends on PCI_MSI
+   depends on HNS3
+   ---help---
+ This selects the HNS3_HCLGE network acceleration engine & its hardware
+ compatibility layer. The engine would be used in Hisilicon hip08 
family of
+ SoCs and further upcoming SoCs.
+
+config HNS3_ENET
+   tristate "Hisilicon HNS3 Ethernet Device Support"
+depends on 64BIT && PCI
+   depends on HNS3 && HNS3_HCLGE
+   ---help---
+ This selects the Ethernet Driver for Hisilicon Network Subsystem 3 
for hip08
+ family of SoCs. This module depends upon HNAE3 driver to access the 
HNAE3
+ devices and their associated operations.
+
 endif # NET_VENDOR_HISILICON
diff --git a/drivers/net/ethernet/hisilicon/Makefile 
b/drivers/net/ethernet/hisilicon/Makefile
index 8661695..3828c43 100644
--- a/drivers/net/ethernet/hisilicon/Makefile
+++ b/drivers/net/ethernet/hisilicon/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_HIX5HD2_GMAC) += hix5hd2_gmac.o
 obj-$(CONFIG_HIP04_ETH) += hip04_eth.o
 obj-$(CONFIG_HNS_MDIO) += hns_mdio.o
 obj-$(CONFIG_HNS) += hns/
+obj-$(CONFIG_HNS3) += hns3/
 obj-$(CONFIG_HISI_FEMAC) += hisi_femac.o
diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile 
b/drivers/net/ethernet/hisilicon/hns3/Makefile
new file mode 100644
index 000..a9349e1
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the HISILICON network device drivers.
+#
+
+obj-$(CONFIG_HNS3) += hns3pf/
+
+obj-$(CONFIG_HNS3) += hnae3.o
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
new file mode 100644
index 000..162e8a42
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
@@ -0,0 +1,11 @@
+#
+# Makefile for the HISILICON network device drivers.
+#
+
+ccflags-y := -Idrivers/net/ethernet/hisilicon/hns3
+
+obj-$(CONFIG_HNS3_HCLGE) += hclge.o
+hclge-objs = hclge_main.o hclge_cmd.o hclge_mdio.o hclge_tm.o
+
+obj-$(CONFIG_HNS3_ENET) += hns3.o
+hns3-objs = hns3_enet.o hns3_ethtool.o
-- 
2.7.4




[PATCH V6 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

2017-08-02 Thread Salil Mehta
This patch adds the support of the Ethtool interface to
the HNS3 Ethernet driver. Various commands to read the
statistics, configure the offloading, loopback selftest etc.
are supported.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
---
Patch V6: addressed below comments
 1. Andrew Lunn
https://lkml.org/lkml/2017/7/28/745
Patch V5: addressed below comments
 1. Florian Fainelli
https://lkml.org/lkml/2017/7/23/94
 2. Stephen Hemminger
https://lkml.org/lkml/2017/7/23/101
Patch V4: addressed below comments
 1. Andrew Lunn
Removed the support of loop PHY back for now
Patch V3: Address below comments
 1. Stephen Hemminger
https://lkml.org/lkml/2017/6/13/974
 2. Andrew Lunn
https://lkml.org/lkml/2017/6/13/1037
Patch V2: No change
Patch V1: Initial Submit
---
 .../ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c  | 482 +
 1 file changed, 482 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
new file mode 100644
index 000..0ad65e4
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c
@@ -0,0 +1,482 @@
+/*
+ * Copyright (c) 2016~2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include "hns3_enet.h"
+
+struct hns3_stats {
+   char stats_string[ETH_GSTRING_LEN];
+   int stats_size;
+   int stats_offset;
+};
+
+/* tqp related stats */
+#define HNS3_TQP_STAT(_string, _member){   \
+   .stats_string = _string,\
+   .stats_size = FIELD_SIZEOF(struct ring_stats, _member), \
+   .stats_offset = offsetof(struct hns3_enet_ring, stats), \
+}  \
+
+static const struct hns3_stats hns3_txq_stats[] = {
+   /* Tx per-queue statistics */
+   HNS3_TQP_STAT("tx_io_err_cnt", io_err_cnt),
+   HNS3_TQP_STAT("tx_sw_err_cnt", sw_err_cnt),
+   HNS3_TQP_STAT("tx_seg_pkt_cnt", seg_pkt_cnt),
+   HNS3_TQP_STAT("tx_pkts", tx_pkts),
+   HNS3_TQP_STAT("tx_bytes", tx_bytes),
+   HNS3_TQP_STAT("tx_err_cnt", tx_err_cnt),
+   HNS3_TQP_STAT("tx_restart_queue", restart_queue),
+   HNS3_TQP_STAT("tx_busy", tx_busy),
+};
+
+#define HNS3_TXQ_STATS_COUNT ARRAY_SIZE(hns3_txq_stats)
+
+static const struct hns3_stats hns3_rxq_stats[] = {
+   /* Rx per-queue statistics */
+   HNS3_TQP_STAT("rx_io_err_cnt", io_err_cnt),
+   HNS3_TQP_STAT("rx_sw_err_cnt", sw_err_cnt),
+   HNS3_TQP_STAT("rx_seg_pkt_cnt", seg_pkt_cnt),
+   HNS3_TQP_STAT("rx_pkts", rx_pkts),
+   HNS3_TQP_STAT("rx_bytes", rx_bytes),
+   HNS3_TQP_STAT("rx_err_cnt", rx_err_cnt),
+   HNS3_TQP_STAT("rx_reuse_pg_cnt", reuse_pg_cnt),
+   HNS3_TQP_STAT("rx_err_pkt_len", err_pkt_len),
+   HNS3_TQP_STAT("rx_non_vld_descs", non_vld_descs),
+   HNS3_TQP_STAT("rx_err_bd_num", err_bd_num),
+   HNS3_TQP_STAT("rx_l2_err", l2_err),
+   HNS3_TQP_STAT("rx_l3l4_csum_err", l3l4_csum_err),
+};
+
+#define HNS3_RXQ_STATS_COUNT ARRAY_SIZE(hns3_rxq_stats)
+
+#define HNS3_TQP_STATS_COUNT (HNS3_TXQ_STATS_COUNT + HNS3_RXQ_STATS_COUNT)
+
+struct hns3_link_mode_mapping {
+   u32 hns3_link_mode;
+   u32 ethtool_link_mode;
+};
+
+static const struct hns3_link_mode_mapping hns3_lm_map[] = {
+   {HNS3_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT},
+   {HNS3_LM_AUTONEG_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT},
+   {HNS3_LM_TP_BIT, ETHTOOL_LINK_MODE_TP_BIT},
+   {HNS3_LM_PAUSE_BIT, ETHTOOL_LINK_MODE_Pause_BIT},
+   {HNS3_LM_BACKPLANE_BIT, ETHTOOL_LINK_MODE_Backplane_BIT},
+   {HNS3_LM_10BASET_HALF_BIT, ETHTOOL_LINK_MODE_10baseT_Half_BIT},
+   {HNS3_LM_10BASET_FULL_BIT, ETHTOOL_LINK_MODE_10baseT_Full_BIT},
+   {HNS3_LM_100BASET_HALF_BIT, ETHTOOL_LINK_MODE_100baseT_Half_BIT},
+   {HNS3_LM_100BASET_FULL_BIT, ETHTOOL_LINK_MODE_100baseT_Full_BIT},
+   {HNS3_LM_1000BASET_FULL_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
+};
+
+static void hns3_driv_to_eth_caps(u32 caps, struct ethtool_link_ksettings *cmd,
+ bool is_advertised)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(hns3_lm_map); i++) {
+   if (!(caps & hns3_lm_map[i].hns3_link_mode))
+   continue;
+
+   if (is_advertised) {
+   ethtool_link_ksettings_zero_link_mode(cmd,
+ advertising);
+   

[PATCH V6 net-next 6/8] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

2017-08-02 Thread Salil Mehta
This patch adds the support of MDIO bus interface for HNS3 driver.
Code provides various interfaces to start and stop the PHY layer
and to read and write the MDIO bus or PHY.

Signed-off-by: Daode Huang 
Signed-off-by: lipeng 
Signed-off-by: Salil Mehta 
Signed-off-by: Yisen Zhuang 
---
Patch V6: Addressed following comments:
 1. Andrew Lunn
https://lkml.org/lkml/2017/7/28/741
https://lkml.org/lkml/2017/7/28/742
Patch V5: Addressed following comments:
 1. Florian Fainelli
https://lkml.org/lkml/2017/7/23/91
Patch V4: Addressed following comments:
 1. Andrew Lunn
https://lkml.org/lkml/2017/6/17/208
Patch V3: Addressed Below comments:
 1. Florian Fainelli
https://lkml.org/lkml/2017/6/13/963
 2. Andrew Lunn
https://lkml.org/lkml/2017/6/13/1039
Patch V2: Addressed below comments:
 1. Florian Fainelli
https://lkml.org/lkml/2017/6/10/130
 2. Andrew Lunn
https://lkml.org/lkml/2017/6/10/168
Patch V1: Initial Submit
---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c| 213 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h|  17 ++
 2 files changed, 230 insertions(+)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
new file mode 100644
index 000..a2add8b
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (c) 2016~2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include "hclge_cmd.h"
+#include "hclge_main.h"
+#include "hclge_mdio.h"
+
+enum hclge_mdio_c22_op_seq {
+   HCLGE_MDIO_C22_WRITE = 1,
+   HCLGE_MDIO_C22_READ = 2
+};
+
+#define HCLGE_MDIO_CTRL_START_B0
+#define HCLGE_MDIO_CTRL_ST_S   1
+#define HCLGE_MDIO_CTRL_ST_M   (0x3 << HCLGE_MDIO_CTRL_ST_S)
+#define HCLGE_MDIO_CTRL_OP_S   3
+#define HCLGE_MDIO_CTRL_OP_M   (0x3 << HCLGE_MDIO_CTRL_OP_S)
+
+#define HCLGE_MDIO_PHYID_S 0
+#define HCLGE_MDIO_PHYID_M (0x1f << HCLGE_MDIO_PHYID_S)
+
+#define HCLGE_MDIO_PHYREG_S0
+#define HCLGE_MDIO_PHYREG_M(0x1f << HCLGE_MDIO_PHYREG_S)
+
+#define HCLGE_MDIO_STA_B   0
+
+struct hclge_mdio_cfg_cmd {
+   u8 ctrl_bit;
+   u8 phyid;
+   u8 phyad;
+   u8 rsvd;
+   __le16 reserve;
+   __le16 data_wr;
+   __le16 data_rd;
+   __le16 sta;
+};
+
+static int hclge_mdio_write(struct mii_bus *bus, int phyid, int regnum,
+   u16 data)
+{
+   struct hclge_mdio_cfg_cmd *mdio_cmd;
+   struct hclge_dev *hdev = bus->priv;
+   struct hclge_desc desc;
+   int ret;
+
+   hclge_cmd_setup_basic_desc(, HCLGE_OPC_MDIO_CONFIG, false);
+
+   mdio_cmd = (struct hclge_mdio_cfg_cmd *)desc.data;
+
+   hnae_set_field(mdio_cmd->phyid, HCLGE_MDIO_PHYID_M,
+  HCLGE_MDIO_PHYID_S, phyid);
+   hnae_set_field(mdio_cmd->phyad, HCLGE_MDIO_PHYREG_M,
+  HCLGE_MDIO_PHYREG_S, regnum);
+
+   hnae_set_bit(mdio_cmd->ctrl_bit, HCLGE_MDIO_CTRL_START_B, 1);
+   hnae_set_field(mdio_cmd->ctrl_bit, HCLGE_MDIO_CTRL_ST_M,
+  HCLGE_MDIO_CTRL_ST_S, 1);
+   hnae_set_field(mdio_cmd->ctrl_bit, HCLGE_MDIO_CTRL_OP_M,
+  HCLGE_MDIO_CTRL_OP_S, HCLGE_MDIO_C22_WRITE);
+
+   mdio_cmd->data_wr = cpu_to_le16(data);
+
+   ret = hclge_cmd_send(>hw, , 1);
+   if (ret) {
+   dev_err(>pdev->dev,
+   "mdio write fail when sending cmd, status is %d.\n",
+   ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int hclge_mdio_read(struct mii_bus *bus, int phyid, int regnum)
+{
+   struct hclge_mdio_cfg_cmd *mdio_cmd;
+   struct hclge_dev *hdev = bus->priv;
+   struct hclge_desc desc;
+   int ret;
+
+   hclge_cmd_setup_basic_desc(, HCLGE_OPC_MDIO_CONFIG, true);
+
+   mdio_cmd = (struct hclge_mdio_cfg_cmd *)desc.data;
+
+   hnae_set_field(mdio_cmd->phyid, HCLGE_MDIO_PHYID_M,
+  HCLGE_MDIO_PHYID_S, phyid);
+   hnae_set_field(mdio_cmd->phyad, HCLGE_MDIO_PHYREG_M,
+  HCLGE_MDIO_PHYREG_S, regnum);
+
+   hnae_set_bit(mdio_cmd->ctrl_bit, HCLGE_MDIO_CTRL_START_B, 1);
+   hnae_set_field(mdio_cmd->ctrl_bit, HCLGE_MDIO_CTRL_ST_M,
+  HCLGE_MDIO_CTRL_ST_S, 1);
+   hnae_set_field(mdio_cmd->ctrl_bit, HCLGE_MDIO_CTRL_OP_M,
+   

  1   2   >