Re: [PATCH] dwc_eth_qos: Remove deprecated create_singlethread_workqueue

[David Miller]

From: Bhaktipriya Shridhar 
Date: Sat, 16 Jul 2016 13:53:28 +0530

> alloc_workqueue replaces deprecated create_singlethread_workqueue().
> 
> A dedicated workqueue has been used since the workitem viz
> lp->txtimeout_reinit is involved in reinitialization if a TX timeout
> occurs, which is necessary to guarantee forward progress in packet
> processing. As a network device can be used during memory reclaim, the
> workqueue needs forward progress guarantee under memory pressure.
> WQ_MEM_RECLAIM has been set to ensure this.
> 
> Since there is only a single work item, explicit concurrency limit is
> unnecessary here.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Applied.

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

[Simon Horman]

[CC Jiri Benc for portion regarding GRE]

Hi Pravin,

On Fri, Jul 15, 2016 at 02:07:37PM -0700, pravin shelar wrote:
> On Wed, Jul 13, 2016 at 12:31 AM, Simon Horman
>  wrote:
> > Hi Pravin,
> >
> > On Thu, Jul 07, 2016 at 01:54:15PM -0700, pravin shelar wrote:
> >> On Wed, Jul 6, 2016 at 10:59 AM, Simon Horman
> >>  wrote:
> >
> > ...
> 
> >
> >> > diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
> >> > index 0ea128eeeab2..86f2cfb19de3 100644
> >> > --- a/net/openvswitch/flow.c
> >> > +++ b/net/openvswitch/flow.c
> >> ...
> >>
> >> > @@ -723,9 +729,17 @@ int ovs_flow_key_extract(const struct 
> >> > ip_tunnel_info *tun_info,
> >> > key->phy.skb_mark = skb->mark;
> >> > ovs_ct_fill_key(skb, key);
> >> > key->ovs_flow_hash = 0;
> >> > +   key->phy.is_layer3 = skb->mac_len == 0;
> >>
> >> I do not think mac_len can be used. mac_header needs to be checked.
> >> ...
> >
> > Yes, indeed. The update to use skb_mac_header_was_set() here accidently
> > slipped into the following patch, sorry about that.
> >
> > With that change in place I believe that this patch is internally
> > consistent because mac_header and mac_len are set correctly by the
> > call to key_extract() which is called by ovs_flow_key_extract() just
> > after where the excerpt above ends.
> >
> > That said, I do think that it is possible to rely on skb_mac_header_was_set
> > throughout the datapath, including action processing etc... I have provided
> > an incremental patch - which I created on top of this entire series - at
> > the end of this email. If you prefer that approach I am happy to take it,
> > though I do feel that using mac_len leads to slightly cleaner code. Let me
> > know what you think.
> >
> 
> 
> I am not sure if you can use only mac_len to detect L3 packet. This
> does not work with MPLS packets, mac_len is used to account MPLS
> headers pushed on skb. Therefore in case of a MPLS header on L3
> packet, mac_len would be non zero and we have to look at either
> mac_header or some other metadata like is_layer3 flag from key to
> check for L3 packet.

At least within OvS mac_len does not include the length of the MPLS label
stack. Rather, the MPLS label stack length is the difference between the
end of (mac_header + mac_len) and network_header.

So I think that the scheme does work as mac_len is 0 if there is no L2
header regardless of if an MPLS label stack is present or not.

> >> > diff --git a/net/openvswitch/vport-netdev.c 
> >> > b/net/openvswitch/vport-netdev.c
> >> > index 4e3972344aa6..733e7914f6bd 100644
> >> > --- a/net/openvswitch/vport-netdev.c
> >> > +++ b/net/openvswitch/vport-netdev.c
> >> > @@ -57,8 +57,10 @@ static void netdev_port_receive(struct sk_buff *skb)
> >> > if (unlikely(!skb))
> >> > return;
> >> >
> >> > -   skb_push(skb, ETH_HLEN);
> >> > -   skb_postpush_rcsum(skb, skb->data, ETH_HLEN);
> >> > +   if (vport->dev->type == ARPHRD_ETHER) {
> >> > +   skb_push(skb, ETH_HLEN);
> >> > +   skb_postpush_rcsum(skb, skb->data, ETH_HLEN);
> >> > +   }
> >> This is still required for tunnel device of ARPHRD_NONE which can
> >> handle l2 packets.
> >
> > That is not necessary given the current implementation (of ipgre) as it
> > supplies an skb with the mac header in place if the inner packet was an
> > Ethernet packet. This scheme could of course be adjusted.
> >
> > ...
> >
> 
> I think we should send L2 header with l2 header pushed on skb. This is
> what OVS expect. The skb-push should be done for all l2 packets rather
> than for particular type of device.

The following seems to achieve that.
Jiri, what do you think?

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index a20248355da0..edbc10690b60 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -281,10 +281,9 @@ static int __ipgre_rcv(struct sk_buff *skb, const struct 
tnl_ptk_info *tpi,
   raw_proto, false) < 0)
goto drop;
 
-   if (tunnel->dev->type != ARPHRD_NONE)
+   if (tunnel->dev->type != ARPHRD_NONE ||
+   tpi->proto == htons(ETH_P_TEB))
skb_pop_mac_header(skb);
-   else if (tpi->proto != htons(ETH_P_TEB))
-   skb_unset_mac_header(skb);
else
skb_reset_mac_header(skb);
if (tunnel->collect_md) {
@@ -326,7 +325,7 @@ static int ipgre_rcv(struct sk_buff *skb, const struct 
tnl_ptk_info *tpi,
 * also ETH_P_TEB traffic.
 */
itn = net_generic(net, ipgre_net_id);
-   res = __ipgre_rcv(skb, tpi, itn, hdr_len, true);
+   res = __ipgre_rcv(skb, tpi, itn, hdr_len, false);
}
return res;
 }
diff --git a/net/openvswitch/vport-netdev.c b/net/openvswitch/vport-netdev.c
index 

Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action

[Alexei Starovoitov]

On Sun, Jul 17, 2016 at 04:41:24AM -0400, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim 
> 
> This action is intended to be an upgrade from a usability perspective
> from pedit (as well as operational debugability).
> Compare this:
> 
> sudo tc filter add dev $ETH parent 1: protocol ip prio 10 \
> u32 match ip protocol 1 0xff flowid 1:2 \
> action pedit munge offset -14 u8 set 0x02 \
> munge offset -13 u8 set 0x15 \
> munge offset -12 u8 set 0x15 \
> munge offset -11 u8 set 0x15 \
> munge offset -10 u16 set 0x1515 \
> pipe
> 
> to:
> 
> sudo tc filter add dev $ETH parent 1: protocol ip prio 10 \
> u32 match ip protocol 1 0xff flowid 1:2 \
> action skbmod dmac 02:15:15:15:15:15
> 
> Or worse, try to debug a policy with destination mac, source mac and
> etherype. Then make that a hundred rules and you'll get my point.
> 
> In the future common use cases on pedit can be migrated to this action
> (as an example different fields in ip v4/6, transports like tcp/udp/sctp
> etc). For this first cut, this allows modifying basic ethernet header.
> 
> Signed-off-by: Jamal Hadi Salim 
> ---
>  include/net/tc_act/tc_skbmod.h|  35 +
>  include/uapi/linux/tc_act/tc_skbmod.h |  47 +++
>  net/sched/Kconfig |  11 ++
>  net/sched/Makefile|   1 +
>  net/sched/act_skbmod.c| 245 
> ++
>  5 files changed, 339 insertions(+)
>  create mode 100644 include/net/tc_act/tc_skbmod.h
>  create mode 100644 include/uapi/linux/tc_act/tc_skbmod.h
>  create mode 100644 net/sched/act_skbmod.c

I agree with Cong's point that this new action adds 339 lines of kernel
code without adding any new functionality.
It is suppose to solve debugging issues, but it's hard to understand
from commit log.
I can imagine new tc command 'action skbmod dmac 02:15:15:15:15:15' that
uses kernel pedit action undercover, so from user space point of view
the same effect can be achieved by extending iproute2.
What is the reason to add this action to the kernel?
By debug you mean to dump kernel action list and multiple pedits
are hard to decipher? Anything else I'm missing?

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

[Alexei Starovoitov]

On Sun, Jul 17, 2016 at 03:19:13AM -0700, Sargun Dhillon wrote:
> 
> +static u64 bpf_copy_to_user(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +{
> + void *to = (void *) (long) r1;
> + void *from = (void *) (long) r2;
> + int  size = (int) r3;
> +
> + /* check if we're in a user context */
> + if (unlikely(in_interrupt()))
> + return -EINVAL;
> + if (unlikely(!current->pid))
> + return -EINVAL;
> +
> + return copy_to_user(to, from, size);
> +}

thanks for the patch, unfortunately it's not that straightforward.
copy_to_user might fault. Try enabling CONFIG_DEBUG_ATOMIC_SLEEP and
you'll see the splat since bpf programs are protected by rcu.
Also 'current' can be null and I'm not sure what current->pid does.
So the writing to user memory either has to be verified to avoid
sleeping and faults or we need to use something like task_work_add
mechanism. Ideas are certainly welcome.

Re: [PATCH v8 04/11] net/mlx4_en: add support for fast rx drop bpf program

[Alexei Starovoitov]

On Fri, Jul 15, 2016 at 09:09:52PM +0200, Jesper Dangaard Brouer wrote:
> 
> On Fri, 15 Jul 2016 09:47:46 -0700 Alexei Starovoitov 
>  wrote:
> > On Fri, Jul 15, 2016 at 09:18:13AM -0700, Tom Herbert wrote:
> [..]
> > > > We don't need extra comlexity of figuring out number of rings and
> > > > struggling with lack of atomicity.  
> > > 
> > > We already have this problem with other per ring configuration.  
> > 
> > not really. without atomicity of the program change, the user space
> > daemon that controls it will struggle to adjust. Consider the case
> > where we're pushing new update for loadbalancer. In such case we
> > want to reuse the established bpf map, since we cannot atomically
> > move it from old to new, but we want to swap the program that uses
> > in one go, otherwise two different programs will be accessing
> > the same map. Technically it's valid, but difference in the programs
> > may cause issues. Lack of atomicity is not intractable problem,
> > it just makes user space quite a bit more complex for no reason.
> 
> I don't think you have a problem with updating the program per queue
> basis, as they will be updated atomically per RX queue (thus a CPU can
> only see one program).
>  Today, you already have to handle that multiple CPUs running the same
> program, need to access the same map.
> 
> You mention that, there might be a problem, if the program differs too
> much to share the map.  But that is the same problem as today.  If you
> need to load a program that e.g. change the map layout, then you
> obviously cannot allow it inherit the old map, but must feed the new
> program a new map (with the new layout).
> 
> 
> There is actually a performance advantage of knowing that a program is
> only attached to a single RX queue. As only a single CPU can process a
> RX ring. Thus, when e.g. accessing a map (or other lookup table) you can
> avoid any locking.

rx queue is not always == cpu. We have different nics with different
number of queues. We'll try to keep dataplane and control plane as generic
as possible otherwise it's operational headache. That's why 'attach to all'
default makes the most sense.
I've been thinking more about atomicity and think we'll be able to
add 'prog per rx queue' while preserving atomicity.
We can do it by extra indirection 'struct bpf_prog **prog'. The xchg
will be swapping the single pointer while all rings will be pointing to it.
Anyway I think we need to table this discussion, since Jesper's email
is already bouncing with happy vacation message :) and Tom is traveling.
I'm pretty sure we'll be able to add support for 'prog per rx ring'
while preserving atomicity of prog swap that this patch does.

[PATCH 1/1] netfilter: Add helper array register/unregister functions

[fgao]

From: Gao Feng 

Add nf_ct_helper_init, nf_conntrack_helpers_register/unregister
functions to enhance the conntrack helper codes.

Signed-off-by: Gao Feng 
---
 include/net/netfilter/nf_conntrack_helper.h | 16 ++
 net/netfilter/nf_conntrack_ftp.c| 58 +++---
 net/netfilter/nf_conntrack_helper.c | 58 ++
 net/netfilter/nf_conntrack_irc.c| 36 +-
 net/netfilter/nf_conntrack_sane.c   | 55 +++--
 net/netfilter/nf_conntrack_sip.c| 75 +++--
 net/netfilter/nf_conntrack_tftp.c   | 48 ++
 7 files changed, 165 insertions(+), 181 deletions(-)

diff --git a/include/net/netfilter/nf_conntrack_helper.h 
b/include/net/netfilter/nf_conntrack_helper.h
index 6cf614bc..8c0c08f 100644
--- a/include/net/netfilter/nf_conntrack_helper.h
+++ b/include/net/netfilter/nf_conntrack_helper.h
@@ -58,10 +58,26 @@ struct nf_conntrack_helper 
*__nf_conntrack_helper_find(const char *name,
 struct nf_conntrack_helper *nf_conntrack_helper_try_module_get(const char 
*name,
   u16 l3num,
   u8 protonum);
+void nf_ct_helper_init(struct nf_conntrack_helper *helper,
+  u16 l3num, u16 protonum, const char *name,
+  u16 default_port, u16 spec_port,
+  const struct nf_conntrack_expect_policy *exp_pol,
+  u32 expect_class_max, u32 data_len,
+  int (*help)(struct sk_buff *skb, unsigned int protoff,
+  struct nf_conn *ct,
+  enum ip_conntrack_info ctinfo),
+  int (*from_nlattr)(struct nlattr *attr,
+ struct nf_conn *ct),
+  struct module *module);
 
 int nf_conntrack_helper_register(struct nf_conntrack_helper *);
 void nf_conntrack_helper_unregister(struct nf_conntrack_helper *);
 
+int nf_conntrack_helpers_register(struct nf_conntrack_helper *,
+   unsigned int);
+void nf_conntrack_helpers_unregister(struct nf_conntrack_helper *,
+   unsigned int);
+
 struct nf_conn_help *nf_ct_helper_ext_add(struct nf_conn *ct,
  struct nf_conntrack_helper *helper,
  gfp_t gfp);
diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c
index 19efeba..e15640d 100644
--- a/net/netfilter/nf_conntrack_ftp.c
+++ b/net/netfilter/nf_conntrack_ftp.c
@@ -572,7 +572,7 @@ static int nf_ct_ftp_from_nlattr(struct nlattr *attr, 
struct nf_conn *ct)
return 0;
 }
 
-static struct nf_conntrack_helper ftp[MAX_PORTS][2] __read_mostly;
+static struct nf_conntrack_helper ftp[MAX_PORTS * 2] __read_mostly;
 
 static const struct nf_conntrack_expect_policy ftp_exp_policy = {
.max_expected   = 1,
@@ -582,24 +582,13 @@ static const struct nf_conntrack_expect_policy 
ftp_exp_policy = {
 /* don't make this __exit, since it's called from __init ! */
 static void nf_conntrack_ftp_fini(void)
 {
-   int i, j;
-   for (i = 0; i < ports_c; i++) {
-   for (j = 0; j < 2; j++) {
-   if (ftp[i][j].me == NULL)
-   continue;
-
-   pr_debug("unregistering helper for pf: %d port: %d\n",
-ftp[i][j].tuple.src.l3num, ports[i]);
-   nf_conntrack_helper_unregister([i][j]);
-   }
-   }
-
+   nf_conntrack_helpers_unregister(ftp, ports_c * 2);
kfree(ftp_buffer);
 }
 
 static int __init nf_conntrack_ftp_init(void)
 {
-   int i, j = -1, ret = 0;
+   int i, ret = 0;
 
ftp_buffer = kmalloc(65536, GFP_KERNEL);
if (!ftp_buffer)
@@ -611,32 +600,21 @@ static int __init nf_conntrack_ftp_init(void)
/* FIXME should be configurable whether IPv4 and IPv6 FTP connections
 are tracked or not - YK */
for (i = 0; i < ports_c; i++) {
-   ftp[i][0].tuple.src.l3num = PF_INET;
-   ftp[i][1].tuple.src.l3num = PF_INET6;
-   for (j = 0; j < 2; j++) {
-   ftp[i][j].data_len = sizeof(struct nf_ct_ftp_master);
-   ftp[i][j].tuple.src.u.tcp.port = htons(ports[i]);
-   ftp[i][j].tuple.dst.protonum = IPPROTO_TCP;
-   ftp[i][j].expect_policy = _exp_policy;
-   ftp[i][j].me = THIS_MODULE;
-   ftp[i][j].help = help;
-   ftp[i][j].from_nlattr = nf_ct_ftp_from_nlattr;
-   if (ports[i] == FTP_PORT)
-   sprintf(ftp[i][j].name, "ftp");
-   else
- 

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

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/intel/i40e/i40e_main.c

between commit:

  f6bd09625ba6 ("i40e: enable VSI broadcast promiscuous mode instead of adding 
broadcast filter")

from the net tree and commit:

  3e25a8f31af1 ("i40e: add hw struct local variable")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/intel/i40e/i40e_main.c
index eb09f60b4984,2b1140563a64..
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@@ -2152,12 -2165,27 +2172,15 @@@ int i40e_sync_vsi_filters(struct i40e_v
if (aq_ret) {
retval =
i40e_aq_rc_to_posix(aq_ret,
-   pf->hw.aq.asq_last_status);
+   hw->aq.asq_last_status);
dev_info(>pdev->dev,
-"set multicast promisc failed, err %d, 
aq_err %d\n",
-aq_ret, pf->hw.aq.asq_last_status);
+"set multicast promisc failed on %s, 
err %s, aq_err %s\n",
+vsi_name,
+i40e_stat_str(hw, aq_ret),
+i40e_aq_str(hw,
+hw->aq.asq_last_status));
}
}
 -  aq_ret = i40e_aq_set_vsi_broadcast(>back->hw,
 - vsi->seid,
 - cur_promisc, NULL);
 -  if (aq_ret) {
 -  retval = i40e_aq_rc_to_posix(aq_ret,
 -   pf->hw.aq.asq_last_status);
 -  dev_info(>pdev->dev,
 -   "set brdcast promisc failed, err %s, aq_err 
%s\n",
 -   i40e_stat_str(hw, aq_ret),
 -   i40e_aq_str(hw,
 -   hw->aq.asq_last_status));
 -  }
}
  out:
/* if something went wrong then set the changed flag so we try again */

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

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/cavium/liquidio/lio_main.c

between commit:

  8e6ce7ebeb34 ("net: cavium: liquidio: Avoid dma_unmap_single on uninitialized 
ndata")

from the net tree and commit:

  6a885b60dad2 ("liquidio: Introduce new octeon2/3 header")

from the net-next tree.

I am not sure how to fix this up, so I effectively reverted the net
tree commit.  Please let me know if something else should be done.

I fixed it up (see above) 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

Re: [PATCH net-next v2 04/10] net/ncsi: Package and channel management

[Gavin Shan]

On Fri, Jul 15, 2016 at 10:30:00PM +0800, kbuild test robot wrote:
>[auto build test ERROR on net-next/master]
>
>url:
>https://github.com/0day-ci/linux/commits/Gavin-Shan/NCSI-Support/20160715-190549
>config: i386-allmodconfig (attached as .config)
>compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>reproduce:
># save the attached .config to linux build tree
>make ARCH=i386 
>
>All error/warnings (new ones prefixed by >>):
>
>   In file included from include/linux/swab.h:4:0,
>from include/uapi/linux/byteorder/little_endian.h:12,
>from include/linux/byteorder/little_endian.h:4,
>from arch/x86/include/uapi/asm/byteorder.h:4,
>from include/asm-generic/bitops/le.h:5,
>from arch/x86/include/asm/bitops.h:504,
>from include/linux/bitops.h:36,
>from include/linux/kernel.h:10,
>from include/linux/list.h:8,
>from include/linux/module.h:9,
>from net/ncsi/ncsi-manage.c:10:
>   net/ncsi/ncsi-manage.c: In function 'ncsi_register_dev':
>>> net/ncsi/ncsi-manage.c:1134:32: error: 'ETH_P_NCSI' undeclared (first use 
>>> in this function)
> ndp->ptype.type = cpu_to_be16(ETH_P_NCSI);
>   ^

Same to breakage caused by PATCH[02/10]. The ETH_P_NCSI definition in
include/uapi/linux/if_ether.h was missed from this series. I will fix
it in next respin to address comments received for this series.

Thanks,
Gavin

Re: [PATCH net-next v2 02/10] net/ncsi: NCSI command packet handler

[Gavin Shan]

On Fri, Jul 15, 2016 at 10:08:23PM +0800, kbuild test robot wrote:
>[auto build test ERROR on net-next/master]
>
>url:
>https://github.com/0day-ci/linux/commits/Gavin-Shan/NCSI-Support/20160715-190549
>config: i386-allmodconfig (attached as .config)
>compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>reproduce:
># save the attached .config to linux build tree
>make ARCH=i386 
>
>All error/warnings (new ones prefixed by >>):
>
>   In file included from include/linux/swab.h:4:0,
>from include/uapi/linux/byteorder/little_endian.h:12,
>from include/linux/byteorder/little_endian.h:4,
>from arch/x86/include/uapi/asm/byteorder.h:4,
>from include/asm-generic/bitops/le.h:5,
>from arch/x86/include/asm/bitops.h:504,
>from include/linux/bitops.h:36,
>from include/linux/kernel.h:10,
>from include/linux/list.h:8,
>from include/linux/module.h:9,
>from net/ncsi/ncsi-cmd.c:10:
>   net/ncsi/ncsi-cmd.c: In function 'ncsi_alloc_command':
>>> net/ncsi/ncsi-cmd.c:301:24: error: 'ETH_P_NCSI' undeclared (first use in 
>>> this function)
> skb->protocol = htons(ETH_P_NCSI);
>   ^

The ETH_P_NCSI definition in include/uapi/linux/if_ether.h was missed from this 
series. I
will fix it in next respin to address comments received from this series.

Thanks,
Gavin

[PATCH 1/2] net: ethernet: marvell: pxa168_eth: use phydev from struct net_device

[Philippe Reynes]

The private structure contain a pointer to phydev, but the structure
net_device already contain such pointer. So we can remove the pointer
phydev in the private structure, and update the driver to use the
one contained in struct net_device.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/marvell/pxa168_eth.c |   36 +
 1 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c 
b/drivers/net/ethernet/marvell/pxa168_eth.c
index 54d5154..d466326 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -247,7 +247,6 @@ struct pxa168_eth_private {
 */
struct timer_list timeout;
struct mii_bus *smi_bus;
-   struct phy_device *phy;
 
/* clock */
struct clk *clk;
@@ -644,7 +643,7 @@ static void eth_port_start(struct net_device *dev)
struct pxa168_eth_private *pep = netdev_priv(dev);
int tx_curr_desc, rx_curr_desc;
 
-   phy_start(pep->phy);
+   phy_start(dev->phydev);
 
/* Assignment of Tx CTRP of given queue */
tx_curr_desc = pep->tx_curr_desc_q;
@@ -700,7 +699,7 @@ static void eth_port_reset(struct net_device *dev)
val &= ~PCR_EN;
wrl(pep, PORT_CONFIG, val);
 
-   phy_stop(pep->phy);
+   phy_stop(dev->phydev);
 }
 
 /*
@@ -943,7 +942,7 @@ static int set_port_config_ext(struct pxa168_eth_private 
*pep)
 static void pxa168_eth_adjust_link(struct net_device *dev)
 {
struct pxa168_eth_private *pep = netdev_priv(dev);
-   struct phy_device *phy = pep->phy;
+   struct phy_device *phy = dev->phydev;
u32 cfg, cfg_o = rdl(pep, PORT_CONFIG);
u32 cfgext, cfgext_o = rdl(pep, PORT_CONFIG_EXT);
 
@@ -973,16 +972,17 @@ static int pxa168_init_phy(struct net_device *dev)
 {
struct pxa168_eth_private *pep = netdev_priv(dev);
struct ethtool_cmd cmd;
+   struct phy_device *phy = NULL;
int err;
 
-   if (pep->phy)
+   if (dev->phydev)
return 0;
 
-   pep->phy = mdiobus_scan(pep->smi_bus, pep->phy_addr);
-   if (IS_ERR(pep->phy))
-   return PTR_ERR(pep->phy);
+   phy = mdiobus_scan(pep->smi_bus, pep->phy_addr);
+   if (IS_ERR(phy))
+   return PTR_ERR(phy);
 
-   err = phy_connect_direct(dev, pep->phy, pxa168_eth_adjust_link,
+   err = phy_connect_direct(dev, phy, pxa168_eth_adjust_link,
 pep->phy_intf);
if (err)
return err;
@@ -1366,30 +1366,26 @@ static int pxa168_smi_write(struct mii_bus *bus, int 
phy_addr, int regnum,
 static int pxa168_eth_do_ioctl(struct net_device *dev, struct ifreq *ifr,
   int cmd)
 {
-   struct pxa168_eth_private *pep = netdev_priv(dev);
-   if (pep->phy != NULL)
-   return phy_mii_ioctl(pep->phy, ifr, cmd);
+   if (dev->phydev != NULL)
+   return phy_mii_ioctl(dev->phydev, ifr, cmd);
 
return -EOPNOTSUPP;
 }
 
 static int pxa168_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct pxa168_eth_private *pep = netdev_priv(dev);
int err;
 
-   err = phy_read_status(pep->phy);
+   err = phy_read_status(dev->phydev);
if (err == 0)
-   err = phy_ethtool_gset(pep->phy, cmd);
+   err = phy_ethtool_gset(dev->phydev, cmd);
 
return err;
 }
 
 static int pxa168_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
-   struct pxa168_eth_private *pep = netdev_priv(dev);
-
-   return phy_ethtool_sset(pep->phy, cmd);
+   return phy_ethtool_sset(dev->phydev, cmd);
 }
 
 static void pxa168_get_drvinfo(struct net_device *dev,
@@ -1569,8 +1565,8 @@ static int pxa168_eth_remove(struct platform_device *pdev)
  pep->htpr, pep->htpr_dma);
pep->htpr = NULL;
}
-   if (pep->phy)
-   phy_disconnect(pep->phy);
+   if (dev->phydev)
+   phy_disconnect(dev->phydev);
if (pep->clk) {
clk_disable_unprepare(pep->clk);
}
-- 
1.7.4.4

[PATCH 2/2] net: ethernet: marvell: pxa168_eth: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/marvell/pxa168_eth.c |   39 +---
 1 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c 
b/drivers/net/ethernet/marvell/pxa168_eth.c
index d466326..aeeb2e7 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -274,8 +274,8 @@ enum hash_table_entry {
HASH_ENTRY_RECEIVE_DISCARD_BIT = 2
 };
 
-static int pxa168_get_settings(struct net_device *dev, struct ethtool_cmd 
*cmd);
-static int pxa168_set_settings(struct net_device *dev, struct ethtool_cmd 
*cmd);
+static int pxa168_get_link_ksettings(struct net_device *dev,
+struct ethtool_link_ksettings *cmd);
 static int pxa168_init_hw(struct pxa168_eth_private *pep);
 static int pxa168_init_phy(struct net_device *dev);
 static void eth_port_reset(struct net_device *dev);
@@ -971,7 +971,7 @@ static void pxa168_eth_adjust_link(struct net_device *dev)
 static int pxa168_init_phy(struct net_device *dev)
 {
struct pxa168_eth_private *pep = netdev_priv(dev);
-   struct ethtool_cmd cmd;
+   struct ethtool_link_ksettings cmd;
struct phy_device *phy = NULL;
int err;
 
@@ -987,20 +987,21 @@ static int pxa168_init_phy(struct net_device *dev)
if (err)
return err;
 
-   err = pxa168_get_settings(dev, );
+   err = pxa168_get_link_ksettings(dev, );
if (err)
return err;
 
-   cmd.phy_address = pep->phy_addr;
-   cmd.speed = pep->phy_speed;
-   cmd.duplex = pep->phy_duplex;
-   cmd.advertising = PHY_BASIC_FEATURES;
-   cmd.autoneg = AUTONEG_ENABLE;
+   cmd.base.phy_address = pep->phy_addr;
+   cmd.base.speed = pep->phy_speed;
+   cmd.base.duplex = pep->phy_duplex;
+   ethtool_convert_legacy_u32_to_link_mode(cmd.link_modes.advertising,
+   PHY_BASIC_FEATURES);
+   cmd.base.autoneg = AUTONEG_ENABLE;
 
-   if (cmd.speed != 0)
-   cmd.autoneg = AUTONEG_DISABLE;
+   if (cmd.base.speed != 0)
+   cmd.base.autoneg = AUTONEG_DISABLE;
 
-   return pxa168_set_settings(dev, );
+   return phy_ethtool_set_link_ksettings(dev, );
 }
 
 static int pxa168_init_hw(struct pxa168_eth_private *pep)
@@ -1372,22 +1373,18 @@ static int pxa168_eth_do_ioctl(struct net_device *dev, 
struct ifreq *ifr,
return -EOPNOTSUPP;
 }
 
-static int pxa168_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int pxa168_get_link_ksettings(struct net_device *dev,
+struct ethtool_link_ksettings *cmd)
 {
int err;
 
err = phy_read_status(dev->phydev);
if (err == 0)
-   err = phy_ethtool_gset(dev->phydev, cmd);
+   err = phy_ethtool_ksettings_get(dev->phydev, cmd);
 
return err;
 }
 
-static int pxa168_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
-   return phy_ethtool_sset(dev->phydev, cmd);
-}
-
 static void pxa168_get_drvinfo(struct net_device *dev,
   struct ethtool_drvinfo *info)
 {
@@ -1398,11 +1395,11 @@ static void pxa168_get_drvinfo(struct net_device *dev,
 }
 
 static const struct ethtool_ops pxa168_ethtool_ops = {
-   .get_settings   = pxa168_get_settings,
-   .set_settings   = pxa168_set_settings,
.get_drvinfo= pxa168_get_drvinfo,
.get_link   = ethtool_op_get_link,
.get_ts_info= ethtool_op_get_ts_info,
+   .get_link_ksettings = pxa168_get_link_ksettings,
+   .set_link_ksettings = phy_ethtool_set_link_ksettings,
 };
 
 static const struct net_device_ops pxa168_eth_netdev_ops = {
-- 
1.7.4.4

Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

[Rob Herring]

On Sat, Jul 16, 2016 at 03:29:04PM +0100, Jamie Lentin wrote:
> This is a router based on the mv88f5181 chipset.
> 
> http://www.netgear.com/support/product/WNR854T.aspx
> http://wiki.openwrt.org/toh/netgear/wnr854t
> 
> Signed-off-by: Jamie Lentin 
> ---
>  .../bindings/arm/marvell/marvell,orion5x.txt   |   1 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/orion5x-netgear-wnr854t.dts  | 200 
> +
>  arch/arm/mach-orion5x/Kconfig  |   6 +
>  arch/arm/mach-orion5x/Makefile |   1 +
>  arch/arm/mach-orion5x/board-wnr854t.c  |  78 
>  6 files changed, 287 insertions(+)
>  create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
>  create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt 
> b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
> index ff3c120..748a8f2 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
> @@ -22,3 +22,4 @@ board. Currently known boards are:
>  "lacie,d2-network"
>  "marvell,rd-88f5182-nas"
>  "maxtor,shared-storage-2"
> +"netgear,wnr854t"
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 95c1923..63b9202 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -535,6 +535,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
>   orion5x-linkstation-lswtgl.dtb \
>   orion5x-lswsgl.dtb \
>   orion5x-maxtor-shared-storage-2.dtb \
> + orion5x-netgear-wnr854t.dtb \
>   orion5x-rd88f5182-nas.dtb
>  dtb-$(CONFIG_ARCH_PRIMA2) += \
>   prima2-evb.dtb
> diff --git a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts 
> b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
> new file mode 100644
> index 000..a8e89d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
> @@ -0,0 +1,200 @@
> +/*
> + * Copyright (C) 2014 Jamie Lentin 

It's 2016 now.

> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "orion5x-mv88f5181.dtsi"
> +
> +/ {
> + model = "Netgear WNR854-t";
> + compatible = "netgear,wnr854t", "marvell,orion5x-88f5181",
> + "marvell,orion5x";
> +
> + memory {
> + reg = <0x 0x200>; /* 32 MB */
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
> + linux,stdout-path = 

As kind of mentioned, drop the linux prefix here.

> + };
> +
> + soc {
> + ranges = ,
> + ,
> + ;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-0 = <_reset_switch>;
> + pinctrl-names = "default";
> +
> + reset {
> + label = "Reset Button";
> + linux,code = ;
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-0 = <_power_led _power_led_blink _wan_led>;
> + pinctrl-names = "default";
> +
> + led@0 {
> + label = "power:green";
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + led@1 {
> + label = "power:blink";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + led@2 {
> + label = "wan:green";
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + dsa@0 {
> + compatible = "marvell,dsa";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dsa,ethernet = <>;
> + dsa,mii-bus = <>;
> +
> + switch@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0>;/* MDIO address 0, switch 0 in tree */
> +
> + port@0 {
> + reg = <0>;
> + label = "lan3";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan4";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "wan";
> + };
> +
> + port@3 {
> +

Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

[Arnd Bergmann]

On Sunday, July 17, 2016 10:39:01 AM CEST Jamie Lentin wrote:
> On Sat, 16 Jul 2016, Arnd Bergmann wrote:

> > The other patches all appear good to me, but I find this one suspicious.
> >
> > Why are you not using the device tree for probing PCI? Is there anything
> > missing in drivers/pci/host/pci-mvebu.c, or do you just need help
> > describing it in DT?
> 
> Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port 
> as well as a PCIe port. Given no other orion5x boards seem to use 
> pci-mvebu, I'm assuming there's work to be done before the PCI port can be 
> used via. pci-mvebu.c
> 
> This is something I can look into if there aren't patches out there, but 
> wanted to get the rest into a reasonable state first.

Ok, I see your point. However, we also don't have any other Orion5x machines
using DT that rely on old probe method, and I this is something that
is particularly hard to retrofit later.

I would assume that the PCIe port should work out of the box with the driver
we have, but the PCI controller does not, and it will require some work.
Looking at https://wiki.openwrt.org/toh/netgear/wnr854t, I assume that
you want only PCI but not PCIe, correct?

The good news is that we can completely separate the two, we just have two
different PCI domains if both are enabled, so we just need to add a new
driver for the PCI port to drivers/pci/host. The pci_ops can be copied
from the existing driver, although a couple of minor cleanups would be
possible. The special handling of bus numbers and the rc_pci_fixup()
can probably just go away, and the latter part is particularly
important, because building a kernel with the fixup included might
break any system with a Marvell host bridge.

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

Arnd

Re: [PATCH v0 05/10] arm: orion5x: Add DT include for mv88f5181

[Rob Herring]

On Sat, Jul 16, 2016 at 03:29:03PM +0100, Jamie Lentin wrote:
> Signed-off-by: Jamie Lentin 
> ---
>  .../bindings/arm/marvell/marvell,orion5x.txt   |  1 +
>  arch/arm/boot/dts/orion5x-mv88f5181.dtsi   | 35 
> ++
>  2 files changed, 36 insertions(+)
>  create mode 100644 arch/arm/boot/dts/orion5x-mv88f5181.dtsi

Acked-by: Rob Herring 

Re: [PATCH v0 04/10] arm: orion5x: Generalise mv88f5181l pinctrl support for 88f5181

[Rob Herring]

On Sat, Jul 16, 2016 at 03:29:02PM +0100, Jamie Lentin wrote:
> As far as I'm aware the mv88f5181-b1 and mv88f5181l are the same at the
> pinctrl level, so re-use the definitions for both.
> 
> Signed-off-by: Jamie Lentin 
> ---
>  .../bindings/pinctrl/marvell,orion-pinctrl.txt |  4 ++--
>  drivers/pinctrl/mvebu/pinctrl-orion.c  | 23 
> +++---
>  2 files changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
> index 27570a3..5a79bad 100644
> --- a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
> @@ -4,8 +4,8 @@ Please refer to marvell,mvebu-pinctrl.txt in this directory 
> for common binding
>  part and usage.
>  
>  Required properties:
> -- compatible: "marvell,88f5181l-pinctrl", "marvell,88f5182-pinctrl",
> -  "marvell,88f5281-pinctrl"
> +- compatible: "marvell,88f5181-pinctrl", "marvell,88f5181l-pinctrl",
> +  "marvell,88f5182-pinctrl", "marvell,88f5281-pinctrl"

Please reformat to one per line. Otherwise,

Acked-by: Rob Herring 


>  
>  - reg: two register areas, the first one describing the first two
>contiguous MPP registers, and the second one describing the single

Re: [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181

[Rob Herring]

On Sat, Jul 16, 2016 at 03:29:01PM +0100, Jamie Lentin wrote:
> Referring to values in the u-boot port, add support for the mv88f5181
> 
> Signed-off-by: Jamie Lentin 
> ---
>  .../devicetree/bindings/clock/mvebu-core-clock.txt |  1 +

Acked-by: Rob Herring 

>  drivers/clk/mvebu/orion.c  | 70 
> ++
>  2 files changed, 71 insertions(+)

Re: [PATCH v0 02/10] arm: orion5x: Add documentation for SoC and board bindings

[Rob Herring]

On Sat, Jul 16, 2016 at 03:29:00PM +0100, Jamie Lentin wrote:
> Copy the format for kirkwood/dove to orion5x
> 
> Signed-off-by: Jamie Lentin 
> ---
>  .../bindings/arm/marvell/marvell,orion5x.txt   | 23 
> ++
>  1 file changed, 23 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

Acked-by: Rob Herring 

[PATCH] cfg80211: fix missing break in NL8211_CHAN_WIDTH_80P80 case

[Colin King]

From: Colin Ian King 

The switch on chandef->width is missing a break on the
NL8211_CHAN_WIDTH_80P80 case; currently we get a WARN_ON when
center_freq2 is non-zero because of the missing break.

Signed-off-by: Colin Ian King 
---
 net/wireless/chan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index b0e11b6..0f50622 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -513,6 +513,7 @@ static bool cfg80211_chandef_dfs_available(struct wiphy 
*wiphy,
r = cfg80211_get_chans_dfs_available(wiphy,
 chandef->center_freq2,
 width);
+   break;
default:
WARN_ON(chandef->center_freq2);
break;
-- 
2.8.1

Re: [RFC PATCH net-next 1/1] Introduce skbmod action

[Cong Wang]

On Sat, Jul 16, 2016 at 7:28 AM, Jamal Hadi Salim  wrote:
> On 16-07-12 01:10 PM, Cong Wang wrote:
>>
>> On Mon, Jul 11, 2016 at 5:12 AM, Jamal Hadi Salim 
>> wrote:
>>>
>>> From: Jamal Hadi Salim 
>>>
>>> This action is intended to be an upgrade from a usability perspective
>>> from pedit. Compare this:
>>>
>>
>> Definitely agree we need a more user-friendly interface.
>>
>>>
>>> pedit is a good starting point - but once you start going to a large
>>> number of policies then from a programmability, ops and usability point
>>> of view you need something with more succint params.
>>>
>>
>> But it is still unclear why we can't just build something on top of
>> pedit? Since pedit accepts keys like u32, user-space is free to
>> introduce any wrapper on top of it.
>>
>
>
> That hasnt served us well so far for reasons i described earlier
> especially in the dump case.
> It hasnt served u32 as a classifier well either (yes, those dump
> wrappers exist on the tc user code); i am almost willing to bet
> you didnt even know such a feature existed ;->

But this still sounds like it is solvable, just not yet solved, right?
And we don't have to change kernel space unless we can't
fix user-space.

Re: [PATCH v0 00/10] Convert Netgear WNR854T to devicetree

[Andrew Lunn]

> Firstly I've tried to to rebase against net-next[0], but after
> adding 6131 to mv88e6xxx_of_match, >ppu_work seems to be
> causing a NULL pointer ooops. I'll assume it's not done yet and
> ignore net-next for now.

You don't need to modify mv88e6xxx_of_match, the 6131 is compatible
with the mv88e6085. Just use the compatible string of
"marvell,mv88e6085". So far, ever Marvell chip we support is
compatible with the mv88e6085, in terms of probing. Once the driver
has probed, and read the device ID from a register, it knows enough to
decide for itself what features the chip has.

In order to get the LEDs working as you want, you are going to have to
use the new binding. So i would suggest sticking with that.

> >I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
> >configuration. Try swapping to EDSA. I even removed support for
> >TAG_DSA in one of the recent patches.
> 
> Okay, back to my original wnr854t-support-v0a branch based on 4.6,
> switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to
> add support, but there's no traffic in/out of any port. tcpdump on
> the underlying ethernet port shows encapsulated broadcast traffic,
> e.g. this ARP request from enp0:10.100.4.41:
> 
> 00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast,
> ethertype Unknown (0xc008), length 64:
> 0x:   0806 0001 0800 0604 0001 1aff 0ffe  
> 0x0010:  1022 0a64 0429    0a64 0437  .".d.)...d.7
> 0x0020:           
> 0x0030:   ..
> 
> ...but no unicast traffic.

Uh, that does not look like EDSA tagging. Expect an ethertype of
0xdada. Also, if you get the latest tcpdump sources, it knows how to
decode the additional EDSA header which is added.

> 
> >Please also can you get https://github.com/vivien/linux.git commit
> >323321875671dfe95b6b91ce051a74d415c7158c which will give you some
> >extra debug files /sys/kernel/debug/mv88e6xxx.
> >
> >The reg, stats, and atu would be interesting.
> 
> Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the
> LEDs, cherry-picked the above commit. Pushed the result if it's
> useful[1]. The debugfs code wouldn't patch cleanly onto 4.6 or
> net-next.

Yes, the debug code is a real pain. Something i'm working on in the
background, get something generic which is acceptable for mainline.
 
> On boot up I get:
> 
> mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
> mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 
> switch
> libphy: dsa slave smi: probed
> Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R]  
> (mii_bus:phy_addr=dsa-0:00:00, irq=-1)
> Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] 
> (mii_bus:phy_addr=dsa-0:00:01, irq=-1)
> Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] 
> (mii_bus:phy_addr=dsa-0:00:02, irq=-1)
> Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] 
> (mii_bus:phy_addr=dsa-0:00:05, irq=-1)
> Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] 
> (mii_bus:phy_addr=dsa-0:00:07, irq=-1)

That looks good, it found the PHYs etc.

> Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no
> traffic visible with tcpdump on lan1/4 (broadcast or unicast), only
> broadcast traffic on the backing port, eth0.
> 
> # cat /sys/kernel/debug/mv88e6xxx.0/regs
> GLOBAL GLOBAL2 SERDES 01234567
>  0:  c800   0   0  7080 7d80 7080 6e88 6086 7e86 6086 7086
>  1:1b   0   0 333   3e  403  403  403  403
>  2:  2fd5   0   0 00000000
>  3:  9df4   0  1066 1066 1066 1066 1066 1066 1066 1066
>  4:  4000 191   0   433  433  433 3533  433  433  433  433
>  5:  1000  ff   0 00000000
>  6:  c0001f0f   0   708  708  708  7f7  708  708  708  708
>  7: 070ff   0 00000000
>  8: 07800   083   83   83   c3   83   83   83   83
>  9: 0   0   0 11111111
>  a:  f148   0   0 00000000
>  b:  400f   0   0 1240   10   20   40   80
>  c: 0   0   0 00000000
>  d:     0   0 00000000
>  e:     0   0 00000000
>  f:    77   0 00000000
> 10: 0   0   0 00000000
> 11: 0   0   0 00000000
> 12:     0   0 000   120000
> 13:     0   0 00000000
> 14:     0   0   403  403  403 8403  403  403  

Re: [PATCH] net/mlx5_core/health: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

Sure. Will make the changes in v2.

Thanks,
Bhaktipriya


On Sun, Jul 17, 2016 at 10:43 AM, Leon Romanovsky  wrote:
> On Sat, Jul 16, 2016 at 01:29:20PM +0530, Bhaktipriya Shridhar wrote:
>> The workqueue health->wq was used as per device private health thread.
>> This was done so that system error handling could be processed
>> concurrently.
>
> Not exactly, AFAIK it was intended to perform delayed work and not
> relevant to concurrency.
>
>> The workqueue has a single workitem(>work) and
>> hence doesn't require ordering. It is involved in handling the health of
>> the deviceand is not being used on a memory reclaim path.
>> Hence, the singlethreaded workqueue has been replaced with the use of
>> system_wq.
>
> Yes
>
>>
>> System workqueues have been able to handle high level of concurrency
>> for a long time now and hence it's not required to have a singlethreaded
>> workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
>> created with create_singlethread_workqueue(), system_wq allows multiple
>> work items to overlap executions even on the same CPU; however, a
>> per-cpu workqueue doesn't have any CPU locality or global ordering
>> guarantee unless the target CPU is explicitly specified and thus the
>> increase of local concurrency shouldn't make any difference.
>
> Not relevant.
>
>>
>> Work item has been flushed in mlx5_health_cleanup() to ensure that
>> there are no pending tasks while disconnecting the driver.
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>> ---
>>  drivers/net/ethernet/mellanox/mlx5/core/health.c | 7 ++-
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c 
>> b/drivers/net/ethernet/mellanox/mlx5/core/health.c
>> index 42d16b9..9acbccf 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
>> @@ -267,7 +267,7 @@ static void poll_health(unsigned long data)
>>   if (in_fatal(dev) && !health->sick) {
>>   health->sick = true;
>>   print_health_info(dev);
>> - queue_work(health->wq, >work);
>> + schedule_work(>work);
>>   }
>>  }
>>
>> @@ -296,7 +296,7 @@ void mlx5_health_cleanup(struct mlx5_core_dev *dev)
>>  {
>>   struct mlx5_core_health *health = >priv.health;
>>
>> - destroy_workqueue(health->wq);
>> + flush_work(>work);
>>  }
>>
>>  int mlx5_health_init(struct mlx5_core_dev *dev)
>> @@ -311,10 +311,7 @@ int mlx5_health_init(struct mlx5_core_dev *dev)
>>
>>   strcpy(name, "mlx5_health");
>>   strcat(name, dev_name(>pdev->dev));
>> - health->wq = create_singlethread_workqueue(name);
>>   kfree(name);
>
> You need to remove "name" initialization/usage too.
> It is not needed.
>
>> - if (!health->wq)
>> - return -ENOMEM;
>>
>>   INIT_WORK(>work, health_care);
>>
>> --
>> 2.1.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] sh_eth: fix DMA channel misreporting

[Sergei Shtylyov]

Currently 'ifconfig' for the Ethernet devices handled by this driver  shows
"DMA chan: ff" while the driver doesn't use any DMA channels. Not assigning
a value to 'net_device::dma' causes 'ifconfig'  to  correctly not report  a
DMA channel.

Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |1 -
 1 file changed, 1 deletion(-)

Index: net/drivers/net/ethernet/renesas/sh_eth.c
===
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -2996,7 +2996,6 @@ static int sh_eth_drv_probe(struct platf
if (devno < 0)
devno = 0;
 
-   ndev->dma = -1;
ret = platform_get_irq(pdev, 0);
if (ret < 0)
goto out_release;

[PATCH 1/2] ravb: fix DMA channel misreporting

[Sergei Shtylyov]

Currently 'ifconfig' for the Ethernet devices handled by this driver  shows
"DMA chan: ff" while the driver doesn't use any DMA channels. Not assigning
a value to 'net_device::dma' causes 'ifconfig'  to  correctly not report  a
DMA channel.

Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/ravb_main.c |1 -
 1 file changed, 1 deletion(-)

Index: net/drivers/net/ethernet/renesas/ravb_main.c
===
--- net.orig/drivers/net/ethernet/renesas/ravb_main.c
+++ net/drivers/net/ethernet/renesas/ravb_main.c
@@ -1909,7 +1909,6 @@ static int ravb_probe(struct platform_de
 
/* The Ether-specific entries in the device structure. */
ndev->base_addr = res->start;
-   ndev->dma = -1;
 
chip_id = (enum ravb_chip_id)of_device_get_match_data(>dev);
 

[PATCH 0/2] Fix DMA channel misreporting for the Renesas Ethernet drivers

[Sergei Shtylyov]

Hello.

   Here's a set of 2 patches against DaveM's 'net.git' repo fixing up the DMA
channel reporting by 'ifconfig'...

[1/2] ravb: fix DMA channel misreporting
[2/2] sh_eth: fix DMA channel misreporting

MBR, Sergei

Re: [PATCH v0 00/10] Convert Netgear WNR854T to devicetree

[Jamie Lentin]

On Sat, 16 Jul 2016, Andrew Lunn wrote:


There's one major flaw; unicast traffic is never received on any port.
Broadcast traffic is received however, and on the correct port. Thus
an external machine can make an ARP request and get a response, for
example. With a manually-entered ARP entry, the router can send pings
out to a remote machine which responds, and the response is lost in the
DSA switch. "ethtool -S" reports pings received on "in_unicast" but
nothing makes it through the switch. This thread[0] seems very similar.
I've run out of ideas here and can't find any switch datasheets to give
me pointers so any suggestions greatly appreciated.


Hi Jamie

So it is 6131? So part of the 6185 family.


Yes, that's what's detected and the OpenWRT page says 88E6131-LAR1. And my 
test setup looks like:


88e6131
  |- lan1:10.100.1.55 <-- switch --> eth0:10.100.1.41 -|
  |- lan4:10.100.4.55 <-- cable  --> enp0:10.100.4.41 -|
laptop
enp0 is a 100M USB network card, the switch is gigabit and on the rest of 
my network here, so there's assorted background broadcast chatter. If the 
noise is confusing matters then can disconnect it.


Firstly I've tried to to rebase against net-next[0], but after adding 6131 
to mv88e6xxx_of_match, >ppu_work seems to be causing a NULL pointer 
ooops. I'll assume it's not done yet and ignore net-next for now.



I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
configuration. Try swapping to EDSA. I even removed support for
TAG_DSA in one of the recent patches.


Okay, back to my original wnr854t-support-v0a branch based on 4.6, 
switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to 
add support, but there's no traffic in/out of any port. tcpdump on the 
underlying ethernet port shows encapsulated broadcast traffic, e.g. this 
ARP request from enp0:10.100.4.41:


00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast, ethertype 
Unknown (0xc008), length 64:

0x:   0806 0001 0800 0604 0001 1aff 0ffe  
0x0010:  1022 0a64 0429    0a64 0437  .".d.)...d.7
0x0020:           
0x0030:   ..

...but no unicast traffic.


Please also can you get https://github.com/vivien/linux.git commit
323321875671dfe95b6b91ce051a74d415c7158c which will give you some
extra debug files /sys/kernel/debug/mv88e6xxx.

The reg, stats, and atu would be interesting.


Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the LEDs, 
cherry-picked the above commit. Pushed the result if it's useful[1]. The 
debugfs code wouldn't patch cleanly onto 4.6 or net-next.


On boot up I get:

mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 switch
libphy: dsa slave smi: probed
Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R]  
(mii_bus:phy_addr=dsa-0:00:00, irq=-1)
Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] 
(mii_bus:phy_addr=dsa-0:00:01, irq=-1)
Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] 
(mii_bus:phy_addr=dsa-0:00:02, irq=-1)
Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] 
(mii_bus:phy_addr=dsa-0:00:05, irq=-1)
Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] 
(mii_bus:phy_addr=dsa-0:00:07, irq=-1)

Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no 
traffic visible with tcpdump on lan1/4 (broadcast or unicast), only 
broadcast traffic on the backing port, eth0.


# cat /sys/kernel/debug/mv88e6xxx.0/regs
GLOBAL GLOBAL2 SERDES 01234567
 0:  c800   0   0  7080 7d80 7080 6e88 6086 7e86 6086 7086
 1:1b   0   0 333   3e  403  403  403  403
 2:  2fd5   0   0 00000000
 3:  9df4   0  1066 1066 1066 1066 1066 1066 1066 1066
 4:  4000 191   0   433  433  433 3533  433  433  433  433
 5:  1000  ff   0 00000000
 6:  c0001f0f   0   708  708  708  7f7  708  708  708  708
 7: 070ff   0 00000000
 8: 07800   083   83   83   c3   83   83   83   83
 9: 0   0   0 11111111
 a:  f148   0   0 00000000
 b:  400f   0   0 1240   10   20   40   80
 c: 0   0   0 00000000
 d:     0   0 00000000
 e:     0   0 00000000
 f:    77   0 00000000
10: 0   0   0 00000000
11: 0   0   0 00000000

Re: [PATCH 1/1] tracing, bpf: Implement function bpf_probe_write

[Sargun Dhillon]

On Fri, 15 Jul 2016, Alexei Starovoitov wrote:


On Fri, Jul 15, 2016 at 07:16:01PM -0700, Sargun Dhillon wrote:



On Thu, 14 Jul 2016, Alexei Starovoitov wrote:


On Wed, Jul 13, 2016 at 01:31:57PM -0700, Sargun Dhillon wrote:



On Wed, 13 Jul 2016, Alexei Starovoitov wrote:


On Wed, Jul 13, 2016 at 03:36:11AM -0700, Sargun Dhillon wrote:

Provides BPF programs, attached to kprobes a safe way to write to
memory referenced by probes. This is done by making probe_kernel_write
accessible to bpf functions via the bpf_probe_write helper.


not quite :)


Signed-off-by: Sargun Dhillon 
---
include/uapi/linux/bpf.h  |  3 +++
kernel/trace/bpf_trace.c  | 20 
samples/bpf/bpf_helpers.h |  2 ++
3 files changed, 25 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 406459b..355b565 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -313,6 +313,9 @@ enum bpf_func_id {
 */
 BPF_FUNC_skb_get_tunnel_opt,
 BPF_FUNC_skb_set_tunnel_opt,
+
+ BPF_FUNC_probe_write, /* int bpf_probe_write(void *dst, void *src,
int size) */
+


the patch is against some old kernel.
Please always make the patch against net-next tree and cc netdev list.


Sorry, I did this against Linus's tree, not net-next. Will fix.


+static u64 bpf_probe_write(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ void *dst = (void *) (long) r1;
+ void *unsafe_ptr = (void *) (long) r2;
+ int  size = (int) r3;
+
+ return probe_kernel_write(dst, unsafe_ptr, size);
+}


the patch is whitepsace mangled. Please see 
Documentation/networking/netdev-FAQ.txt

Also will fix.



the main issue though that we cannot simply allow bpf to do probe_write,
since it may crash the kernel.
What might be ok is to allow writing into memory of current
user space process only. This way bpf prog will keep kernel safety guarantees,
yet it will be able to modify user process memory when necessary.
Since bpf+tracing is root only, it doesn't pose security risk.




Doesn't probe_write prevent you from writing to protected memory and
generate an EFAULT? Or are you worried about the situation where a bpf
program writes to some other chunk of kernel memory, or writes bad data
to said kernel memory?

I guess when I meant "safe" -- it's safer than allowing arbitrary memcpy.
I don't see a good way to ensure safety otherwise as we don't know
which registers point to memory that it's reasonable for probes to
manipulate. It's not like skb_store_bytes where we can check the pointer
going in is the same pointer that's referenced, and with a super
restricted datatype.


exactly. probe_write can write anywhere in the kernel and that
will cause crashes. If we allow that bpf becomes no different than
kernel module.


Perhaps, it would be a good idea to describe an example where I used this:
#include 
#include 
#include 


int trace_inet_stream_connect(struct pt_regs *ctx)
{
if (!PT_REGS_PARM2(ctx)) {
return 0;
}
struct sockaddr uaddr = {};
struct sockaddr_in *addr_in;
bpf_probe_read(, sizeof(struct sockaddr), (void 
*)PT_REGS_PARM2(ctx));
if (uaddr.sa_family == AF_INET) {
// Simple cast causes LLVM weirdness
addr_in = 
char fmt[] = "Connecting on port: %d\n";
bpf_trace_printk(fmt, sizeof(fmt), ntohs(addr_in->sin_port));
if (ntohs(addr_in->sin_port) == 80) {
addr_in->sin_port = htons(443);
bpf_probe_write((void *)PT_REGS_PARM2(ctx), , 
sizeof(uaddr));
}
}
   return 0;
};

There are two reasons I want to do this:
1) Debugging - sometimes, it makes sense to divert a program's syscalls in
order to allow for better debugging
2) Network Functions - I wrote a load balancer which intercepts
inet_stream_connect & tcp_set_state. We can manipulate the destination
address as neccessary at connect time. This also has the nice side effect
that getpeername() returns the real IP that a server is connected to, and
the performance is far better than doing "network load balancing"

(I realize this is a total hack, better approaches would be appreciated)


nice. interesting idea.
Have you considered ld_preload hack to do port rewrite?


We've thought about it. It wont really work for us, because we're doing this
to manipulate 3rd party runtimes, many of which are written in languages
that don't play nice with LD_PRELOAD. Go is the primary problem child in
this case. We also looked at using SECCOMP + ptrace, but again, not all
runtimes play nice with ptrace.


interesting!
I was about to suggest to hack write support into seccomp, since few
folks were interested in it as well. Why seccomp won't work?
You cannot have a centralized daemon that launches all the processes?


If we allowed manipulation of the current task's user memory by exposing
copy_to_user, that could also work if I attach the probe to sys_connect,
I 

Re: [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T

[Jamie Lentin]

On Sat, 16 Jul 2016, Arnd Bergmann wrote:


On Saturday, July 16, 2016 3:29:04 PM CEST Jamie Lentin wrote:

+
+#define WNR854T_PCI_SLOT0_OFFS 7
+#define WNR854T_PCI_SLOT0_IRQ_PIN  4
+
+static void __init wnr854t_pci_preinit(void)
+{
+   int pin;
+
+   /*
+* Configure PCI GPIO IRQ pins
+*/
+   pin = WNR854T_PCI_SLOT0_IRQ_PIN;
+   if (gpio_request(pin, "PCI Int") == 0) {
+   if (gpio_direction_input(pin) == 0) {
+   irq_set_irq_type(gpio_to_irq(pin), IRQ_TYPE_LEVEL_LOW);
+   } else {
+   pr_err("wnr854t_pci_preinit failed to set_irq_type pin 
%d\n",
+   pin);
+   gpio_free(pin);
+   }
+   } else {
+   pr_err("wnr854t_pci_preinit failed to request gpio %d\n", pin);
+   }
+}
+
+static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
+   u8 pin)
+{
+   int irq;
+
+   /*
+* Check for devices with hard-wired IRQs.
+*/
+   irq = orion5x_pci_map_irq(dev, slot, pin);
+   if (irq != -1)
+   return irq;
+
+   /*
+* PCI IRQs are connected via GPIOs
+*/
+   switch (slot - WNR854T_PCI_SLOT0_OFFS) {
+   case 0:
+   return gpio_to_irq(WNR854T_PCI_SLOT0_IRQ_PIN);
+   default:
+   return -1;
+   }
+}


The other patches all appear good to me, but I find this one suspicious.

Why are you not using the device tree for probing PCI? Is there anything
missing in drivers/pci/host/pci-mvebu.c, or do you just need help
describing it in DT?


Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port 
as well as a PCIe port. Given no other orion5x boards seem to use 
pci-mvebu, I'm assuming there's work to be done before the PCI port can be 
used via. pci-mvebu.c


This is something I can look into if there aren't patches out there, but 
wanted to get the rest into a reasonable state first.




Arnd



--
Jamie Lentin

[PATCH net-next 1/1] net_sched: Introduce skbmod action

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

This action is intended to be an upgrade from a usability perspective
from pedit (as well as operational debugability).
Compare this:

sudo tc filter add dev $ETH parent 1: protocol ip prio 10 \
u32 match ip protocol 1 0xff flowid 1:2 \
action pedit munge offset -14 u8 set 0x02 \
munge offset -13 u8 set 0x15 \
munge offset -12 u8 set 0x15 \
munge offset -11 u8 set 0x15 \
munge offset -10 u16 set 0x1515 \
pipe

to:

sudo tc filter add dev $ETH parent 1: protocol ip prio 10 \
u32 match ip protocol 1 0xff flowid 1:2 \
action skbmod dmac 02:15:15:15:15:15

Or worse, try to debug a policy with destination mac, source mac and
etherype. Then make that a hundred rules and you'll get my point.

In the future common use cases on pedit can be migrated to this action
(as an example different fields in ip v4/6, transports like tcp/udp/sctp
etc). For this first cut, this allows modifying basic ethernet header.

Signed-off-by: Jamal Hadi Salim 
---
 include/net/tc_act/tc_skbmod.h|  35 +
 include/uapi/linux/tc_act/tc_skbmod.h |  47 +++
 net/sched/Kconfig |  11 ++
 net/sched/Makefile|   1 +
 net/sched/act_skbmod.c| 245 ++
 5 files changed, 339 insertions(+)
 create mode 100644 include/net/tc_act/tc_skbmod.h
 create mode 100644 include/uapi/linux/tc_act/tc_skbmod.h
 create mode 100644 net/sched/act_skbmod.c

diff --git a/include/net/tc_act/tc_skbmod.h b/include/net/tc_act/tc_skbmod.h
new file mode 100644
index 000..661a107
--- /dev/null
+++ b/include/net/tc_act/tc_skbmod.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2016, Jamal Hadi Salim
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, see .
+ *
+ * Author: Jamal Hadi Salim 
+ */
+
+#ifndef __NET_TC_SKBMOD_H
+#define __NET_TC_SKBMOD_H
+
+#include 
+#include 
+
+struct tcf_skbmod {
+   struct tcf_common   common;
+   u32 flags;
+   u8  eth_dst[ETH_ALEN];
+   u16 eth_type;
+   u8  eth_src[ETH_ALEN];
+};
+#define to_skbmod(a) \
+   container_of(a->priv, struct tcf_skbmod, common)
+
+#endif /* __NET_TC_SKBMOD_H */
diff --git a/include/uapi/linux/tc_act/tc_skbmod.h 
b/include/uapi/linux/tc_act/tc_skbmod.h
new file mode 100644
index 000..c268b94
--- /dev/null
+++ b/include/uapi/linux/tc_act/tc_skbmod.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright (c) 2016, Jamal Hadi Salim
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Author: Jamal Hadi Salim
+ */
+
+#ifndef __LINUX_TC_SKBMOD_H
+#define __LINUX_TC_SKBMOD_H
+
+#include 
+
+#define TCA_ACT_SKBMOD 15
+
+#define SKBMOD_F_DMAC  0x1
+#define SKBMOD_F_SMAC  0x2
+#define SKBMOD_F_ETYPE 0x4
+
+struct tc_skbmod {
+   tc_gen;
+};
+
+enum {
+   TCA_SKBMOD_UNSPEC,
+   TCA_SKBMOD_TM,
+   TCA_SKBMOD_PARMS,
+   TCA_SKBMOD_DMAC,
+   TCA_SKBMOD_SMAC,
+   TCA_SKBMOD_ETYPE,
+   TCA_SKBMOD_PAD,
+   __TCA_SKBMOD_MAX
+};
+#define TCA_SKBMOD_MAX (__TCA_SKBMOD_MAX - 1)
+
+#endif
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index b148302..ca0386c 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -739,6 +739,17 @@ config NET_ACT_CONNMARK
  To compile this code as a module, choose M here: the
  module will be called act_connmark.
 
+config NET_ACT_SKBMOD
+tristate "skb data modification action"
+depends on NET_CLS_ACT
+---help---
+ Say Y here to allow modification of skb data
+
+ If unsure, say N.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_skbmod.
+
 config NET_ACT_IFE
 tristate "Inter-FE action based on IETF ForCES InterFE LFB"
 depends on NET_CLS_ACT
diff --git 

RE: [PATCH v3 6/8] thunderbolt: Networking state machine

[Levy, Amir (Jer)]

On Fri, Jul 15 2016, 03:25 AM, Paul Gortmaker wrote:
> > diff --git a/drivers/thunderbolt/icm/net.c
> > b/drivers/thunderbolt/icm/net.c new file mode 100644 index
> > 000..e983dfb
> > --- /dev/null
> > +++ b/drivers/thunderbolt/icm/net.c
> > @@ -0,0 +1,802 @@
> >
> +/*
> ***
> > +***
> > + *
> > + * Intel Thunderbolt(TM) driver
> > + * Copyright(c) 2014 - 2016 Intel Corporation.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify it
> > + * under the terms and conditions of the GNU General Public License,
> > + * version 2, as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope it will be useful, but
> > +WITHOUT
> > + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY
> > +or
> > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> > +License for
> > + * more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > +along
> > + * with this program.  If not, see .
> > + *
> > + * The full GNU General Public License is included in this
> > +distribution in
> > + * the file called "COPYING".
> > + *
> > + * Contact Information:
> > + * Intel Thunderbolt Mailing List 
> > + * Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR
> > +97124-6497
> > + *
> > +
> >
> +*
> 
> > +*/
> > +
> > +#include 
> 
> I did not see anything like module_init in this driver;  I think it seems 
> like you
> want linux/moduleparam.h here.
> 

Hi Paul,
It looks like leftover from the early development stages.
I'll remove it.
The module_init is in icm_nhi.c.

Thanks,
Amir

[PATCH] drivers: atm: nicstar: Use the correct function to free some resources

[Christophe JAILLET]

In 'get_scq', 'dma_alloc_coherent' has been used to allocate some
resources, so we need to free them using 'dma_free_coherent' instead
of 'kfree'.

Signed-off-by: Christophe JAILLET 
---
 drivers/atm/nicstar.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c
index ddc4ceb..700ed15 100644
--- a/drivers/atm/nicstar.c
+++ b/drivers/atm/nicstar.c
@@ -874,7 +874,8 @@ static scq_info *get_scq(ns_dev *card, int size, u32 scd)
scq->skb = kmalloc(sizeof(struct sk_buff *) *
   (size / NS_SCQE_SIZE), GFP_KERNEL);
if (!scq->skb) {
-   kfree(scq->org);
+   dma_free_coherent(>pcidev->dev,
+ 2 * size, scq->org, scq->dma);
kfree(scq);
return NULL;
}
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

[PATCH v5] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage.

Signed-off-by: Eyal Reizer 
Acked-by: Rob Herring 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select 
instead for sending the extra init cycle which, achieves the same hardware 
purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip 
select number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next

 .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--
 drivers/net/wireless/ti/wlcore/spi.c   | 123 ++---
 2 files changed, 137 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller

-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.

 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip

 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for 
+wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL

 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:

 Examples:

+For wl12xx family:
  {
-   wl1271@1 {
+   wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
-   clock-xtal;
-   ref-clock-frequency = <3840>;
interrupt-parent = <>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <_fixed>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   };
+};
+
+For wl18xx family:
+ {
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   vwlan-supply = <_fixed>;
};
 };
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092

 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared 
+ to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for 
+ wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)

 /* Maximum number of SPI write chunks */  #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)


+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+   

[PATCH] net: ti: cpmac: Use the correct function to free some resources.

[Christophe JAILLET]

In 'cpmac_open', 'dma_alloc_coherent' has been used to allocate some
resources, so we need to free them using 'dma_free_coherent' instead
of 'kfree'.

Also, we don't need to free these resources if the allocation has failed.
So I have slighly modified the goto label in this case.

Signed-off-by: Christophe JAILLET 

---
Un-compiled (I don't have the configuration for that) and un-tested
---
 drivers/net/ethernet/ti/cpmac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c
index 7eef45e..56c8920 100644
--- a/drivers/net/ethernet/ti/cpmac.c
+++ b/drivers/net/ethernet/ti/cpmac.c
@@ -1032,8 +1032,10 @@ fail_desc:
kfree_skb(priv->rx_head[i].skb);
}
}
+   dma_free_coherent(>dev, sizeof(struct cpmac_desc) * size,
+ priv->desc_ring, priv->dma_ring);
+
 fail_alloc:
-   kfree(priv->desc_ring);
iounmap(priv->regs);
 
 fail_remap:
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

[Grumbach, Emmanuel]

> On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote:
> > On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote:
> >>> If I understad correctly this error happen 100% of the time, not
> >>> only during init. Hence seems there is an issue here, i.e. cur_ucode
> >>> is not marked correctly as IWL_UCODE_REGULAR or
> iwl_mvm_get_temp()
> >>> fail 100% of the time (iwl_mvm_is_tt_in_fw() incorrecly return true on
> Prarit device ? ).
> >>
> >> Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware
> >> which will happen upon ifup.
> >
> > Then creating thermal_device on ifup looks more reasonable to me.
> > Otherwise we can create device that can be non-functional virtually
> > forever, i.e. when soft RFKILL is enabled. However I admit that
> > creating thermal_device when HW is detected has some advantages too.
> 
> That's my plan right now.  Unfortunately something else in the kernel seems
> recently broken and is preventing me from testing.  I will get back to this
> early next week.
> 

But we already said that this won't work since you may have the device enabled 
upon boot and then disabled. So unless you unregister the thermal zone 
subsystem upon wifi disable, you won't solve the problem. Kalle and Luca 
already refused that solution.

I glanced (again) at the thermal zone API and since it allows to return an int, 
the subsystem itself should handle the failures and / or the userspace 
problems. The API itself is awful, it has no documentation whatsoever, even not 
variable names, but only types... You can't really blame the subsystem users to 
assume that a method that can return an int can't fail where the out values is 
passed by a pointer. Of course, you have to guess that this is the expected 
behavior, since you don't have any hint about the meaning of the parameters.
I think that the right place to "fix" this problem is to fix the subsystem. 
This way, you will fix it for iwlwifi and for any (future) other users that may 
fall into the trap opened by the API itself.