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

2017-12-04 Thread Stephen Rothwell 
Hi all,

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

  drivers/net/can/flexcan.c

between commit:

  29c64b17a0bc ("can: flexcan: fix VF610 state transition issue")

from Linus' tree and commit:

  99b7668c04b2 ("can: flexcan: adding platform specific details for LS1021A")

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/can/flexcan.c
index 0626dcfd1f3d,3a370d8437b0..
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -184,12 -184,13 +184,13 @@@
   * Below is some version info we got:
   *SOC   Version   IP-Version  Glitch- [TR]WRN_INT IRQ Err Memory err RTR 
re-
   *Filter? connected?  Passive detection  
ception in MB
 - *   MX25  FlexCAN2  03.00.00.00 nono ?   nono
 + *   MX25  FlexCAN2  03.00.00.00 nonono   nono
   *   MX28  FlexCAN2  03.00.04.00yes   yesno   nono
 - *   MX35  FlexCAN2  03.00.00.00 nono ?   nono
 + *   MX35  FlexCAN2  03.00.00.00 nonono   nono
   *   MX53  FlexCAN2  03.00.00.00yesnono   nono
   *   MX6s  FlexCAN3  10.00.12.00yes   yesno   no   yes
 - *   VF610 FlexCAN3  ?   no   yes ?  yes   
yes?
 + *   VF610 FlexCAN3  ?   no   yesno  yes   
yes?
+  * LS1021A FlexCAN2  03.00.04.00 no   yesno   no   yes
   *
   * Some SOCs do not have the RX_WARN & TX_WARN interrupt line connected.
   */
@@@ -297,10 -302,15 +302,16 @@@ static const struct flexcan_devtype_dat
  
  static const struct flexcan_devtype_data fsl_vf610_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
 -  FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
 +  FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
 +  FLEXCAN_QUIRK_BROKEN_PERR_STATE,
  };
  
+ static const struct flexcan_devtype_data fsl_ls1021a_r2_devtype_data = {
+   .quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
+   FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_BROKEN_PERR_STATE |
+   FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
+ };
+ 
  static const struct can_bittiming_const flexcan_bittiming_const = {
.name = DRV_NAME,
.tseg1_min = 4,

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

2017-11-09 Thread David Miller 
From: Stephen Rothwell 
Date: Fri, 10 Nov 2017 10:31:00 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/cls_basic.c
>   net/sched/cls_u32.c
> 
> between commits:
> 
>   0b2a59894b76 ("cls_basic: use tcf_exts_get_net() before call_rcu()")
>   35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before call_rcu()")
> 
> from Linus' tree and commit:
> 
>   1d8134fea2eb ("net_sched: use idr to allocate basic filter handles")
> 
> from the net-next tree.

This should be resolved as I've just merged 'net' into 'net-next'.

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

2017-11-09 Thread Cong Wang 
On Thu, Nov 9, 2017 at 3:31 PM, Stephen Rothwell  wrote:
> I fixed it up (I think - 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.

It looks good to me.

Thanks!

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

2017-11-09 Thread Stephen Rothwell 
Hi all,

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

  net/sched/cls_basic.c
  net/sched/cls_u32.c

between commits:

  0b2a59894b76 ("cls_basic: use tcf_exts_get_net() before call_rcu()")
  35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before call_rcu()")

from Linus' tree and commit:

  1d8134fea2eb ("net_sched: use idr to allocate basic filter handles")

from the net-next tree.

I fixed it up (I think - 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 net/sched/cls_basic.c
index e43c56d5b96a,871351358c10..
--- a/net/sched/cls_basic.c
+++ b/net/sched/cls_basic.c
@@@ -118,11 -115,10 +120,13 @@@ static void basic_destroy(struct tcf_pr
list_for_each_entry_safe(f, n, >flist, link) {
list_del_rcu(>link);
tcf_unbind_filter(tp, >res);
+   idr_remove_ext(>handle_idr, f->handle);
 -  call_rcu(>rcu, basic_delete_filter);
 +  if (tcf_exts_get_net(>exts))
 +  call_rcu(>rcu, basic_delete_filter);
 +  else
 +  __basic_delete_filter(f);
}
+   idr_destroy(>handle_idr);
kfree_rcu(head, rcu);
  }
  
@@@ -133,7 -129,7 +137,8 @@@ static int basic_delete(struct tcf_prot
  
list_del_rcu(>link);
tcf_unbind_filter(tp, >res);
 +  tcf_exts_get_net(>exts);
+   idr_remove_ext(>handle_idr, f->handle);
call_rcu(>rcu, basic_delete_filter);
*last = list_empty(>flist);
return 0;
@@@ -226,9 -222,9 +231,10 @@@ static int basic_change(struct net *net
*arg = fnew;
  
if (fold) {
+   idr_replace_ext(>handle_idr, fnew, fnew->handle);
list_replace_rcu(>link, >link);
tcf_unbind_filter(tp, >res);
 +  tcf_exts_get_net(>exts);
call_rcu(>rcu, basic_delete_filter);
} else {
list_add_rcu(>link, >flist);
diff --cc net/sched/cls_u32.c
index b58eccb21f03,2737b71854c9..
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@@ -590,10 -589,8 +591,11 @@@ static void u32_clear_hnode(struct tcf_
 rtnl_dereference(n->next));
tcf_unbind_filter(tp, >res);
u32_remove_hw_knode(tp, n->handle);
+   idr_remove_ext(>handle_idr, n->handle);
 -  call_rcu(>rcu, u32_delete_key_freepf_rcu);
 +  if (tcf_exts_get_net(>exts))
 +  call_rcu(>rcu, u32_delete_key_freepf_rcu);
 +  else
 +  u32_destroy_key(n->tp, n, true);
}
}
  }

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

2017-10-30 Thread Mark Brown 
On Mon, Oct 30, 2017 at 10:43:07AM -0700, Jakub Kicinski wrote:
> On Mon, 30 Oct 2017 17:02:24 +, Mark Brown wrote:

> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.

> Unfortunately, this is not a correct resolution.  Please see below.

So I actually ended up just throwing this away (and the rest of what was
going on for net-next, there were just far too many of these self
conflicts.  The tree is one of the bigger time sinks when doing -next
but today was particularly heavy.


signature.asc
Description: PGP signature

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

2017-10-30 Thread Jakub Kicinski 
On Mon, 30 Oct 2017 17:02:24 +, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/netronome/nfp/flower/action.c
> 
> between commit:
> 
>   d309ae5c6a0064 ("nfp: refuse offloading filters that redirects to upper 
> devices")
> 
> from Linus' tree and commit:
> 
>   62d3f60b4d065c ("nfp: use struct fields for 8 bit-wide access")

Actually the conflict is with a much older commit b27d6a95a70d ("nfp:
compile flower vxlan tunnel set actions").

> 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.

Unfortunately, this is not a correct resolution.  Please see below.

> diff --cc drivers/net/ethernet/netronome/nfp/flower/action.c
> index 8ea9320014ee,0a5fc9f8545f..
> --- a/drivers/net/ethernet/netronome/nfp/flower/action.c
> +++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
> @@@ -105,19 -104,326 +104,329 @@@ nfp_fl_output(struct nfp_fl_output *out
>   if (!out_dev)
>   return -EOPNOTSUPP;
>   
> - /* Only offload egress ports are on the same device as the ingress
> -  * port.
> + tmp_flags = last ? NFP_FL_OUT_FLAGS_LAST : 0;
> + 
> + if (tun_type) {
> + /* Verify the egress netdev matches the tunnel type. */
> + if (!nfp_fl_netdev_is_tunnel_type(out_dev, tun_type))
> + return -EOPNOTSUPP;
> + 
> + if (*tun_out_cnt)
> + return -EOPNOTSUPP;
> + (*tun_out_cnt)++;
> + 
> + output->flags = cpu_to_be16(tmp_flags |
> + NFP_FL_OUT_FLAGS_USE_TUN);
> + output->port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type);
> + } else {
> + /* Set action output parameters. */
> + output->flags = cpu_to_be16(tmp_flags);
> + 
> + /* Only offload if egress ports are on the same device as the
> +  * ingress port.
> +  */
> + if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + return -EOPNOTSUPP;

The code from net should be inserted here.  Note that net-next only
indented this area, the code is unchanged.

if (!nfp_netdev_is_nfp_repr(out_dev))
return -EOPNOTSUPP;

should immediately follow switchdev_port_same_parent_id() check.

> + output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> + if (!output->port)
> + return -EOPNOTSUPP;
> + }
> + nfp_flow->meta.shortcut = output->port;
> + 
> + return 0;
> + }
> + 
> + static bool nfp_fl_supported_tun_port(const struct tc_action *action)
> + {
> + struct ip_tunnel_info *tun = tcf_tunnel_info(action);
> + 
> + return tun->key.tp_dst == htons(NFP_FL_VXLAN_PORT);
> + }
> + 
> + static struct nfp_fl_pre_tunnel *nfp_fl_pre_tunnel(char *act_data, int 
> act_len)
> + {
> + size_t act_size = sizeof(struct nfp_fl_pre_tunnel);
> + struct nfp_fl_pre_tunnel *pre_tun_act;
> + 
> + /* Pre_tunnel action must be first on action list.
> +  * If other actions already exist they need pushed forward.
>*/
> - if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + if (act_len)
> + memmove(act_data + act_size, act_data, act_len);
> + 
> + pre_tun_act = (struct nfp_fl_pre_tunnel *)act_data;
> + 
> + memset(pre_tun_act, 0, act_size);
> + 
> + pre_tun_act->head.jump_id = NFP_FL_ACTION_OPCODE_PRE_TUNNEL;
> + pre_tun_act->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> + 
> + return pre_tun_act;
> + }
> + 
> + static int
> + nfp_fl_set_vxlan(struct nfp_fl_set_vxlan *set_vxlan,
> +  const struct tc_action *action,
> +  struct nfp_fl_pre_tunnel *pre_tun)
> + {
> + struct ip_tunnel_info *vxlan = tcf_tunnel_info(action);
> + size_t act_size = sizeof(struct nfp_fl_set_vxlan);
> + u32 tmp_set_vxlan_type_index = 0;
> + /* Currently support one pre-tunnel so index is always 0. */
> + int pretun_idx = 0;
> + 
> + if (vxlan->options_len) {
> + /* Do not support options e.g. vxlan gpe. */
>   return -EOPNOTSUPP;
> + }
> + 
>  +if (!nfp_netdev_is_nfp_repr(out_dev))
>  +return -EOPNOTSUPP;
>  +
> - output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> - if (!output->port)
> + set_vxlan->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
> + set_vxlan->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> + 
> + /* Set tunnel type and pre-tunnel index. */
> + tmp_set_vxlan_type_index |=
> + FIELD_PREP(NFP_FL_IPV4_TUNNEL_TYPE,

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

2017-10-30 Thread Mark Brown 
Hi all,

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

  net/ipv4/tcp_output.c

between commit:

  5889e2c0e441d8 ("tcp: call tcp_rate_skb_sent() when retransmit with unaligned 
skb->data")

from Linus' tree and commit:

  e2080072ed2d98 ("tcp: new list for sent but unacked skbs for RACK recovery")

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.

diff --cc net/ipv4/tcp_output.c
index ae60dd3faed0,aab6e7145013..
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@@ -2840,13 -2905,14 +2907,16 @@@ int __tcp_retransmit_skb(struct sock *s
 skb_headroom(skb) >= 0x)) {
struct sk_buff *nskb;
  
-   nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
-   err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
--ENOBUFS;
+   tcp_skb_tsorted_save(skb) {
+   nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
+   err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
+-ENOBUFS;
+   } tcp_skb_tsorted_restore(skb);
+ 
 -  if (!err)
 +  if (!err) {
-   skb->skb_mstamp = tp->tcp_mstamp;
+   tcp_update_skb_after_send(tp, skb);
 +  tcp_rate_skb_sent(sk, skb);
 +  }
} else {
err = tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC);
}


signature.asc
Description: PGP signature

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

2017-10-30 Thread Mark Brown 
Hi all,

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

  kernel/bpf/sockmap.c

between commit:

  bfa640757e9378c ("bpf: rename sk_actions to align with bpf infrastructure")

from Linus' tree and commit:

  6aaae2b6c4330a4 ("bpf: rename bpf_compute_data_end into 
bpf_compute_data_pointers")

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.

diff --cc kernel/bpf/sockmap.c
index 66f00a2b27f4,eef843c3b419..
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c


signature.asc
Description: PGP signature

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

2017-10-30 Thread Mark Brown 
Hi all,

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

  drivers/net/ethernet/netronome/nfp/flower/action.c

between commit:

  d309ae5c6a0064 ("nfp: refuse offloading filters that redirects to upper 
devices")

from Linus' tree and commit:

  62d3f60b4d065c ("nfp: use struct fields for 8 bit-wide access")

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.

diff --cc drivers/net/ethernet/netronome/nfp/flower/action.c
index 8ea9320014ee,0a5fc9f8545f..
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@@ -105,19 -104,326 +104,329 @@@ nfp_fl_output(struct nfp_fl_output *out
if (!out_dev)
return -EOPNOTSUPP;
  
-   /* Only offload egress ports are on the same device as the ingress
-* port.
+   tmp_flags = last ? NFP_FL_OUT_FLAGS_LAST : 0;
+ 
+   if (tun_type) {
+   /* Verify the egress netdev matches the tunnel type. */
+   if (!nfp_fl_netdev_is_tunnel_type(out_dev, tun_type))
+   return -EOPNOTSUPP;
+ 
+   if (*tun_out_cnt)
+   return -EOPNOTSUPP;
+   (*tun_out_cnt)++;
+ 
+   output->flags = cpu_to_be16(tmp_flags |
+   NFP_FL_OUT_FLAGS_USE_TUN);
+   output->port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type);
+   } else {
+   /* Set action output parameters. */
+   output->flags = cpu_to_be16(tmp_flags);
+ 
+   /* Only offload if egress ports are on the same device as the
+* ingress port.
+*/
+   if (!switchdev_port_same_parent_id(in_dev, out_dev))
+   return -EOPNOTSUPP;
+ 
+   output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
+   if (!output->port)
+   return -EOPNOTSUPP;
+   }
+   nfp_flow->meta.shortcut = output->port;
+ 
+   return 0;
+ }
+ 
+ static bool nfp_fl_supported_tun_port(const struct tc_action *action)
+ {
+   struct ip_tunnel_info *tun = tcf_tunnel_info(action);
+ 
+   return tun->key.tp_dst == htons(NFP_FL_VXLAN_PORT);
+ }
+ 
+ static struct nfp_fl_pre_tunnel *nfp_fl_pre_tunnel(char *act_data, int 
act_len)
+ {
+   size_t act_size = sizeof(struct nfp_fl_pre_tunnel);
+   struct nfp_fl_pre_tunnel *pre_tun_act;
+ 
+   /* Pre_tunnel action must be first on action list.
+* If other actions already exist they need pushed forward.
 */
-   if (!switchdev_port_same_parent_id(in_dev, out_dev))
+   if (act_len)
+   memmove(act_data + act_size, act_data, act_len);
+ 
+   pre_tun_act = (struct nfp_fl_pre_tunnel *)act_data;
+ 
+   memset(pre_tun_act, 0, act_size);
+ 
+   pre_tun_act->head.jump_id = NFP_FL_ACTION_OPCODE_PRE_TUNNEL;
+   pre_tun_act->head.len_lw = act_size >> NFP_FL_LW_SIZ;
+ 
+   return pre_tun_act;
+ }
+ 
+ static int
+ nfp_fl_set_vxlan(struct nfp_fl_set_vxlan *set_vxlan,
+const struct tc_action *action,
+struct nfp_fl_pre_tunnel *pre_tun)
+ {
+   struct ip_tunnel_info *vxlan = tcf_tunnel_info(action);
+   size_t act_size = sizeof(struct nfp_fl_set_vxlan);
+   u32 tmp_set_vxlan_type_index = 0;
+   /* Currently support one pre-tunnel so index is always 0. */
+   int pretun_idx = 0;
+ 
+   if (vxlan->options_len) {
+   /* Do not support options e.g. vxlan gpe. */
return -EOPNOTSUPP;
+   }
+ 
 +  if (!nfp_netdev_is_nfp_repr(out_dev))
 +  return -EOPNOTSUPP;
 +
-   output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
-   if (!output->port)
+   set_vxlan->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
+   set_vxlan->head.len_lw = act_size >> NFP_FL_LW_SIZ;
+ 
+   /* Set tunnel type and pre-tunnel index. */
+   tmp_set_vxlan_type_index |=
+   FIELD_PREP(NFP_FL_IPV4_TUNNEL_TYPE, NFP_FL_TUNNEL_VXLAN) |
+   FIELD_PREP(NFP_FL_IPV4_PRE_TUN_INDEX, pretun_idx);
+ 
+   set_vxlan->tun_type_index = cpu_to_be32(tmp_set_vxlan_type_index);
+ 
+   set_vxlan->tun_id = vxlan->key.tun_id;
+   set_vxlan->tun_flags = vxlan->key.tun_flags;
+   set_vxlan->ipv4_ttl = vxlan->key.ttl;
+   set_vxlan->ipv4_tos = vxlan->key.tos;
+ 
+   /* Complete pre_tunnel action. */
+   pre_tun->ipv4_dst = vxlan->key.u.ipv4.dst;
+ 
+   return 0;
+ }
+ 
+ static void nfp_fl_set_helper32(u32 value, u32 mask, u8 *p_exact, u8 *p_mask)
+ {
+   u32 oldvalue = get_unaligned((u32

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

2017-06-29 Thread Stephen Rothwell 
Hi all,

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

  drivers/net/ethernet/rocker/rocker_ofdpa.c

between commit:

  acb4b7df48b5 ("rocker: move dereference before free")

from Linus' tree and commit:

  00fc0c51e35b ("rocker: Change world_ops API and implementation to be 
switchdev independant")

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/rocker/rocker_ofdpa.c
index a9ce82d3e9cf,bd0e3f157e9e..
--- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
+++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
@@@ -1505,10 -1409,10 +1409,10 @@@ static int ofdpa_port_ipv4_nh(struct of
*index = entry->index;
resolved = false;
} else if (removing) {
 -  ofdpa_neigh_del(found);
*index = found->index;
-   ofdpa_neigh_del(trans, found);
++  ofdpa_neigh_del(found);
} else if (updating) {
-   ofdpa_neigh_update(found, trans, NULL, false);
+   ofdpa_neigh_update(found, NULL, false);
resolved = !is_zero_ether_addr(found->eth_dst);
*index = found->index;
} else {

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

2017-05-02 Thread David Miller 
From: Stephen Rothwell 
Date: Wed, 3 May 2017 11:07:03 +1000

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   arch/avr32/include/uapi/asm/socket.h
> 
> between commit:
> 
>   26202873bb51 ("avr32: remove support for AVR32 architecture")
> 
> from Linus' tree and commits:
> 
>   a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
>   6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
>   5daab9db7b65 ("New getsockopt option to get socket cookie")
> 
> from the net-next tree.
> 
> I fixed it up (I removed the file) 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.

Duly noted in the pull request I sent to Linus, and now that he took
net-next in it is resolved in his tree.

Thanks!

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

2017-05-02 Thread Stephen Rothwell 
Hi all,

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

  arch/avr32/include/uapi/asm/socket.h

between commit:

  26202873bb51 ("avr32: remove support for AVR32 architecture")

from Linus' tree and commits:

  a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
  6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
  5daab9db7b65 ("New getsockopt option to get socket cookie")

from the net-next tree.

I fixed it up (I removed the file) 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: linux-next: manual merge of the net-next tree with Linus' tree

2017-03-23 Thread Alexei Starovoitov 

On 3/23/17 5:10 PM, David Miller wrote:

From: Stephen Rothwell 
Date: Fri, 24 Mar 2017 11:05:14 +1100


Hi all,

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

  kernel/bpf/hashtab.c

between commit:

  8c290e60fa2a ("bpf: fix hashmap extra_elems logic")

from Linus' tree and commit:

  bcc6b1b7ebf8 ("bpf: Add hash of maps support")

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.


I did the same resolution just an hour ago when merging net into
net-next.


yes. that's correct merge conflict resolution.
Just rebuilt and retested. All looks good.
Thanks!

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

2017-03-23 Thread David Miller 
From: Stephen Rothwell 
Date: Fri, 24 Mar 2017 11:05:14 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   kernel/bpf/hashtab.c
> 
> between commit:
> 
>   8c290e60fa2a ("bpf: fix hashmap extra_elems logic")
> 
> from Linus' tree and commit:
> 
>   bcc6b1b7ebf8 ("bpf: Add hash of maps support")
> 
> 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.

I did the same resolution just an hour ago when merging net into
net-next.

Thanks!

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

2017-03-23 Thread Stephen Rothwell 
Hi all,

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

  kernel/bpf/hashtab.c

between commit:

  8c290e60fa2a ("bpf: fix hashmap extra_elems logic")

from Linus' tree and commit:

  bcc6b1b7ebf8 ("bpf: Add hash of maps support")

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 kernel/bpf/hashtab.c
index 361a69dfe543,343fb5394c95..
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@@ -582,7 -609,20 +616,15 @@@ static void htab_elem_free_rcu(struct r
  
  static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l)
  {
+   struct bpf_map *map = >map;
+ 
+   if (map->ops->map_fd_put_ptr) {
+   void *ptr = fd_htab_map_get_ptr(map, l);
+ 
+   map->ops->map_fd_put_ptr(ptr);
+   }
+ 
 -  if (l->state == HTAB_EXTRA_ELEM_USED) {
 -  l->state = HTAB_EXTRA_ELEM_FREE;
 -  return;
 -  }
 -
 -  if (!(htab->map.map_flags & BPF_F_NO_PREALLOC)) {
 +  if (htab_is_prealloc(htab)) {
pcpu_freelist_push(>freelist, >fnode);
} else {
atomic_dec(>count);

RE: linux-next: manual merge of the net-next tree with Linus' tree

2017-02-02 Thread Yotam Gigi 
>-Original Message-
>From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>Behalf Of Stephen Rothwell
>Sent: Thursday, February 02, 2017 3:50 AM
>To: David Miller <da...@davemloft.net>; Networking <netdev@vger.kernel.org>
>Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Yotam Gigi
><yot...@mellanox.com>
>Subject: linux-next: manual merge of the net-next tree with Linus' tree
>
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
>  net/sched/cls_matchall.c
>
>between commit:
>
>  fd62d9f5c575 ("net/sched: matchall: Fix configuration race")
>
>from Linus' tree and commit:
>
>  ec2507d2a306 ("net/sched: cls_matchall: Fix error path")
>
>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.

Looks good. Thanks!

>
>--
>Cheers,
>Stephen Rothwell
>
>diff --cc net/sched/cls_matchall.c
>index b12bc2abea93,fcecf5aac666..
>--- a/net/sched/cls_matchall.c
>+++ b/net/sched/cls_matchall.c
>@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
>   struct tcf_exts e;
>   int err;
>
>-  tcf_exts_init(, TCA_MATCHALL_ACT, 0);
>+  err = tcf_exts_init(, TCA_MATCHALL_ACT, 0);
>+  if (err)
>+  return err;
>   err = tcf_exts_validate(net, tp, tb, est, , ovr);
>   if (err < 0)
>-  return err;
>+  goto errout;
>
>   if (tb[TCA_MATCHALL_CLASSID]) {
> - f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> - tcf_bind_filter(tp, >res, base);
> + head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> + tcf_bind_filter(tp, >res, base);
>   }
>
> - tcf_exts_change(tp, >exts, );
> + tcf_exts_change(tp, >exts, );
>
>   return 0;
>+ errout:
>+  tcf_exts_destroy();
>+  return err;
>  }
>
>  static int mall_change(struct net *net, struct sk_buff *in_skb,
>@@@ -162,39 -194,43 +167,44 @@@
>   return -EINVAL;
>   }
>
> - f = kzalloc(sizeof(*f), GFP_KERNEL);
> - if (!f)
> + new = kzalloc(sizeof(*new), GFP_KERNEL);
> + if (!new)
>   return -ENOBUFS;
>
>-  tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
> - err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
>++ err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
>+  if (err)
>+  goto err_exts_init;
>
>   if (!handle)
>   handle = 1;
> - f->handle = handle;
> - f->flags = flags;
> + new->handle = handle;
> + new->flags = flags;
>
> - err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
> + err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
>   if (err)
>-  goto errout;
>+  goto err_set_parms;
>
>   if (tc_should_offload(dev, tp, flags)) {
> - err = mall_replace_hw_filter(tp, f, (unsigned long) f);
> + err = mall_replace_hw_filter(tp, new, (unsigned long) new);
>   if (err) {
>   if (tc_skip_sw(flags))
>-  goto errout;
>+  goto err_replace_hw_filter;
>   else
>   err = 0;
>   }
>   }
>
> - *arg = (unsigned long) f;
> - rcu_assign_pointer(head->filter, f);
> -
> + *arg = (unsigned long) head;
> + rcu_assign_pointer(tp->root, new);
> + if (head)
> + call_rcu(>rcu, mall_destroy_rcu);
>   return 0;
>
>- errout:
>+ err_replace_hw_filter:
>+ err_set_parms:
> - tcf_exts_destroy(>exts);
>++ tcf_exts_destroy(>exts);
>+ err_exts_init:
> - kfree(f);
> + kfree(new);
>   return err;
>  }
>

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

2017-02-01 Thread Stephen Rothwell 
Hi all,

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

  net/sched/cls_matchall.c

between commit:

  fd62d9f5c575 ("net/sched: matchall: Fix configuration race")

from Linus' tree and commit:

  ec2507d2a306 ("net/sched: cls_matchall: Fix error path")

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 net/sched/cls_matchall.c
index b12bc2abea93,fcecf5aac666..
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
struct tcf_exts e;
int err;
  
-   tcf_exts_init(, TCA_MATCHALL_ACT, 0);
+   err = tcf_exts_init(, TCA_MATCHALL_ACT, 0);
+   if (err)
+   return err;
err = tcf_exts_validate(net, tp, tb, est, , ovr);
if (err < 0)
-   return err;
+   goto errout;
  
if (tb[TCA_MATCHALL_CLASSID]) {
 -  f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
 -  tcf_bind_filter(tp, >res, base);
 +  head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
 +  tcf_bind_filter(tp, >res, base);
}
  
 -  tcf_exts_change(tp, >exts, );
 +  tcf_exts_change(tp, >exts, );
  
return 0;
+ errout:
+   tcf_exts_destroy();
+   return err;
  }
  
  static int mall_change(struct net *net, struct sk_buff *in_skb,
@@@ -162,39 -194,43 +167,44 @@@
return -EINVAL;
}
  
 -  f = kzalloc(sizeof(*f), GFP_KERNEL);
 -  if (!f)
 +  new = kzalloc(sizeof(*new), GFP_KERNEL);
 +  if (!new)
return -ENOBUFS;
  
-   tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
 -  err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
++  err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
+   if (err)
+   goto err_exts_init;
  
if (!handle)
handle = 1;
 -  f->handle = handle;
 -  f->flags = flags;
 +  new->handle = handle;
 +  new->flags = flags;
  
 -  err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
 +  err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
if (err)
-   goto errout;
+   goto err_set_parms;
  
if (tc_should_offload(dev, tp, flags)) {
 -  err = mall_replace_hw_filter(tp, f, (unsigned long) f);
 +  err = mall_replace_hw_filter(tp, new, (unsigned long) new);
if (err) {
if (tc_skip_sw(flags))
-   goto errout;
+   goto err_replace_hw_filter;
else
err = 0;
}
}
  
 -  *arg = (unsigned long) f;
 -  rcu_assign_pointer(head->filter, f);
 -
 +  *arg = (unsigned long) head;
 +  rcu_assign_pointer(tp->root, new);
 +  if (head)
 +  call_rcu(>rcu, mall_destroy_rcu);
return 0;
  
- errout:
+ err_replace_hw_filter:
+ err_set_parms:
 -  tcf_exts_destroy(>exts);
++  tcf_exts_destroy(>exts);
+ err_exts_init:
 -  kfree(f);
 +  kfree(new);
return err;
  }

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

2016-10-02 Thread Stephen Rothwell 
Hi all,

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

  net/sctp/sctp_diag.c

between commit:

  1cceda784980 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock")

from Linus' tree and commit:

  d545caca827b ("net: inet: diag: expose the socket mark to privileged 
processes.")

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 net/sctp/sctp_diag.c
index cef0cee182d4,807158e32f5f..
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@@ -299,9 -314,10 +303,10 @@@ static int sctp_sock_dump(struct sock *
sk_user_ns(NETLINK_CB(cb->skb).sk),
NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq,
-   NLM_F_MULTI, cb->nlh) < 0) {
+   NLM_F_MULTI, cb->nlh,
+   commp->net_admin) < 0) {
cb->args[3] = 1;
 -  err = 2;
 +  err = 1;
goto release;
}
cb->args[3] = 1;
@@@ -309,8 -325,9 +314,9 @@@
if (inet_sctp_diag_fill(sk, assoc, skb, r,
sk_user_ns(NETLINK_CB(cb->skb).sk),
NETLINK_CB(cb->skb).portid,
-   cb->nlh->nlmsg_seq, 0, cb->nlh) < 0) {
+   cb->nlh->nlmsg_seq, 0, cb->nlh,
+   commp->net_admin) < 0) {
 -  err = 2;
 +  err = 1;
goto release;
}
  next:

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

2016-10-02 Thread Stephen Rothwell 
Hi all,

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

  net/sctp/outqueue.c

between commit:

  be4947bf46cb ("sctp: change to check peer prsctp_capable when using prsctp 
polices")

from Linus' tree and commit:

  2c89791eeb6f ("sctp: remove the unnecessary state check in sctp_outq_tail")

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 net/sctp/outqueue.c
index 107233da5cc9,3ec6da8bbb53..
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@@ -299,42 -298,19 +298,19 @@@ void sctp_outq_tail(struct sctp_outq *q
 * immediately.
 */
if (sctp_chunk_is_data(chunk)) {
-   /* Is it OK to queue data chunks?  */
-   /* From 9. Termination of Association
-*
-* When either endpoint performs a shutdown, the
-* association on each peer will stop accepting new
-* data from its user and only deliver data in queue
-* at the time of sending or receiving the SHUTDOWN
-* chunk.
-*/
-   switch (q->asoc->state) {
-   case SCTP_STATE_CLOSED:
-   case SCTP_STATE_SHUTDOWN_PENDING:
-   case SCTP_STATE_SHUTDOWN_SENT:
-   case SCTP_STATE_SHUTDOWN_RECEIVED:
-   case SCTP_STATE_SHUTDOWN_ACK_SENT:
-   /* Cannot send after transport endpoint shutdown */
-   error = -ESHUTDOWN;
-   break;
- 
-   default:
-   pr_debug("%s: outqueueing: outq:%p, chunk:%p[%s])\n",
-__func__, q, chunk, chunk && chunk->chunk_hdr ?
-
sctp_cname(SCTP_ST_CHUNK(chunk->chunk_hdr->type)) :
-"illegal chunk");
- 
-   sctp_chunk_hold(chunk);
-   sctp_outq_tail_data(q, chunk);
-   if (chunk->asoc->peer.prsctp_capable &&
-   SCTP_PR_PRIO_ENABLED(chunk->sinfo.sinfo_flags))
-   chunk->asoc->sent_cnt_removable++;
-   if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED)
-   SCTP_INC_STATS(net, SCTP_MIB_OUTUNORDERCHUNKS);
-   else
-   SCTP_INC_STATS(net, SCTP_MIB_OUTORDERCHUNKS);
-   break;
-   }
+   pr_debug("%s: outqueueing: outq:%p, chunk:%p[%s])\n",
+__func__, q, chunk, chunk && chunk->chunk_hdr ?
+sctp_cname(SCTP_ST_CHUNK(chunk->chunk_hdr->type)) :
+"illegal chunk");
+ 
+   sctp_outq_tail_data(q, chunk);
 -  if (chunk->asoc->prsctp_enable &&
++  if (chunk->asoc->peer.prsctp_capable &&
+   SCTP_PR_PRIO_ENABLED(chunk->sinfo.sinfo_flags))
+   chunk->asoc->sent_cnt_removable++;
+   if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED)
+   SCTP_INC_STATS(net, SCTP_MIB_OUTUNORDERCHUNKS);
+   else
+   SCTP_INC_STATS(net, SCTP_MIB_OUTORDERCHUNKS);
} else {
list_add_tail(>list, >control_chunk_list);
SCTP_INC_STATS(net, SCTP_MIB_OUTCTRLCHUNKS);

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

2016-06-29 Thread Stephen Rothwell 
Hi all,

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

  drivers/net/phy/fixed_phy.c

between commit:

  69fc58a57e56 ("net: phy: Manage fixed PHY address space using IDA")

from Linus' tree and commit:

  bf7afb29d545 ("phy: improve safety of fixed-phy MII register reading")

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/phy/fixed_phy.c
index 9ec7f7353434,b376ada83598..
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@@ -23,9 -23,9 +23,10 @@@
  #include 
  #include 
  #include 
+ #include 
 +#include 
  
- #define MII_REGS_NUM 29
+ #include "swphy.h"
  
  struct fixed_mdio_bus {
struct mii_bus *mii_bus;

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

2016-05-02 Thread Stephen Rothwell 
Hi all,

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

  net/ipv4/ip_gre.c

between commits:

  2090714e1d6e ("gre: build header correctly for collect metadata tunnels")
  b7f8fe251e46 ("gre: do not pull header in ICMP error processing")

from Linus' tree and commit:

  95f5c64c3c13 ("gre: Move utility functions to common headers")
  182a352d2d5e ("gre: Create common functions for transmit")

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 net/ipv4/ip_gre.c
index 205a2b8a5a84,2480d79b0e37..
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@@ -341,8 -221,9 +221,9 @@@ static void gre_err(struct sk_buff *skb
const int code = icmp_hdr(skb)->code;
struct tnl_ptk_info tpi;
bool csum_err = false;
+   int hdr_len;
  
-   if (parse_gre_header(skb, , _err) < 0) {
 -  if (gre_parse_header(skb, , _err, _len)) {
++  if (gre_parse_header(skb, , _err, _len) < 0) {
if (!csum_err)  /* ignore csum errors. */
return;
}
@@@ -574,15 -414,12 +415,12 @@@ static void gre_fb_xmit(struct sk_buff 
}
  
/* Push Tunnel header. */
-   skb = gre_handle_offloads(skb, !!(tun_info->key.tun_flags & 
TUNNEL_CSUM));
-   if (IS_ERR(skb)) {
-   skb = NULL;
+   if (gre_handle_offloads(skb, !!(tun_info->key.tun_flags & TUNNEL_CSUM)))
goto err_free_rt;
-   }
  
flags = tun_info->key.tun_flags & (TUNNEL_CSUM | TUNNEL_KEY);
-   build_header(skb, tunnel_hlen, flags, proto,
-tunnel_id_to_key(tun_info->key.tun_id), 0);
 -  gre_build_header(skb, tunnel_hlen, flags, htons(ETH_P_TEB),
++  gre_build_header(skb, tunnel_hlen, flags, proto,
+tunnel_id_to_key(tun_info->key.tun_id), 0);
  
df = key->tun_flags & TUNNEL_DONT_FRAGMENT ?  htons(IP_DF) : 0;

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

2016-03-15 Thread Gregory CLEMENT 
Hi Stephen,
 
 On mar., mars 15 2016, Stephen Rothwell  wrote:

> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>   arch/arm/boot/dts/armada-xp-db.dts
>   arch/arm/boot/dts/armada-xp-gp.dts
>   arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
>
> between commit:
>
>   d7d5a43c0d16 ("ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory 
> window")
>
> from Linus' tree and commits:
>
>   9dd7a57e2cbf ("ARM: dts: armada-xp: enable buffer manager support on Armada 
> XP boards")
>   293fdc24fcc9 ("ARM: dts: armada-xp-openblocks-ax3-4: Add BM support")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This fix is good, thanks!

Gregory

>
> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm/boot/dts/armada-xp-db.dts
> index 45813a5526c8,30657302305d..
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@@ -76,8 -76,9 +76,9 @@@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>   
>   devbus-bootcs {
>   status = "okay";
> @@@ -229,34 -242,10 +242,38 @@@
>   spi-max-frequency = <2000>;
>   };
>   };
>  +
>  +nand@d {
>  +status = "okay";
>  +num-cs = <1>;
>  +marvell,nand-keep-config;
>  +marvell,nand-enable-arbiter;
>  +nand-on-flash-bbt;
>  +
>  +partitions {
>  +compatible = "fixed-partitions";
>  +#address-cells = <1>;
>  +#size-cells = <1>;
>  +
>  +partition@0 {
>  +label = "U-Boot";
>  +reg = <0 0x80>;
>  +};
>  +partition@80 {
>  +label = "Linux";
>  +reg = <0x80 0x80>;
>  +};
>  +partition@100 {
>  +label = "Filesystem";
>  +reg = <0x100 0x3f00>;
>  +
>  +};
>  +};
>  +};
>   };
> + 
> + bm-bppi {
> + status = "okay";
> + };
>   };
>   };
> diff --cc arch/arm/boot/dts/armada-xp-gp.dts
> index 5730b875c4f5,a1ded01d0c07..
> --- a/arch/arm/boot/dts/armada-xp-gp.dts
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@@ -95,8 -95,9 +95,9 @@@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>   
>   devbus-bootcs {
>   status = "okay";
> diff --cc arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> index 853bd392a4fe,3aa29a91c7b8..
> --- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> +++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> @@@ -65,9 -65,10 +65,10 @@@
>   soc {
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
>  -  MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x01, 0x2f) 0 0 0xe800 0x800
>  +

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

2016-03-14 Thread Stephen Rothwell 
Hi all,

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

  arch/arm/boot/dts/armada-xp-db.dts
  arch/arm/boot/dts/armada-xp-gp.dts
  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts

between commit:

  d7d5a43c0d16 ("ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory 
window")

from Linus' tree and commits:

  9dd7a57e2cbf ("ARM: dts: armada-xp: enable buffer manager support on Armada 
XP boards")
  293fdc24fcc9 ("ARM: dts: armada-xp-openblocks-ax3-4: Add BM support")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/boot/dts/armada-xp-db.dts
index 45813a5526c8,30657302305d..
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@@ -76,8 -76,9 +76,9 @@@
ranges = ;
++MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
+ MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
  
devbus-bootcs {
status = "okay";
@@@ -229,34 -242,10 +242,38 @@@
spi-max-frequency = <2000>;
};
};
 +
 +  nand@d {
 +  status = "okay";
 +  num-cs = <1>;
 +  marvell,nand-keep-config;
 +  marvell,nand-enable-arbiter;
 +  nand-on-flash-bbt;
 +
 +  partitions {
 +  compatible = "fixed-partitions";
 +  #address-cells = <1>;
 +  #size-cells = <1>;
 +
 +  partition@0 {
 +  label = "U-Boot";
 +  reg = <0 0x80>;
 +  };
 +  partition@80 {
 +  label = "Linux";
 +  reg = <0x80 0x80>;
 +  };
 +  partition@100 {
 +  label = "Filesystem";
 +  reg = <0x100 0x3f00>;
 +
 +  };
 +  };
 +  };
};
+ 
+   bm-bppi {
+   status = "okay";
+   };
};
  };
diff --cc arch/arm/boot/dts/armada-xp-gp.dts
index 5730b875c4f5,a1ded01d0c07..
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@@ -95,8 -95,9 +95,9 @@@
ranges = ;
++MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
+ MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
  
devbus-bootcs {
status = "okay";
diff --cc arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 853bd392a4fe,3aa29a91c7b8..
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@@ -65,9 -65,10 +65,10 @@@
soc {
ranges = ;
++MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
+

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

2015-07-14 Thread Nikolay Aleksandrov 
On 07/14/2015 03:46 AM, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the net-next tree got a conflict in:
 
   net/bridge/br_mdb.c
 
 between commit:
 
   f1158b74e54f (bridge: mdb: zero out the local br_ip variable before use)
 
 from Linus' tree and commit:
 
   74fe61f17e99 (bridge: mdb: add vlan support for user entries)
 
 from the net-next tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).
 

Looks good to me, thanks Stephen!

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

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

2015-07-13 Thread Stephen Rothwell 
Hi all,

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

  net/bridge/br_mdb.c

between commit:

  f1158b74e54f (bridge: mdb: zero out the local br_ip variable before use)

from Linus' tree and commit:

  74fe61f17e99 (bridge: mdb: add vlan support for user entries)

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc net/bridge/br_mdb.c
index c11cf2611db0,a8d0e93d43f2..
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@@ -348,10 -352,8 +353,10 @@@ static int br_mdb_add_group(struct net_
if (unlikely(!p))
return -ENOMEM;
rcu_assign_pointer(*pp, p);
 +  if (state == MDB_TEMPORARY)
 +  mod_timer(p-timer, now + br-multicast_membership_interval);
  
-   br_mdb_notify(br-dev, port, group, RTM_NEWMDB);
+   br_mdb_notify(br-dev, port, group, RTM_NEWMDB, state);
return 0;
  }
  
@@@ -374,7 -376,7 +379,8 @@@ static int __br_mdb_add(struct net *net
if (!p || p-br != br || p-state == BR_STATE_DISABLED)
return -EINVAL;
  
 +  memset(ip, 0, sizeof(ip));
+   ip.vid = entry-vid;
ip.proto = entry-addr.proto;
if (ip.proto == htons(ETH_P_IP))
ip.u.ip4 = entry-addr.u.ip4;
@@@ -421,14 -423,21 +427,15 @@@ static int __br_mdb_del(struct net_brid
if (!netif_running(br-dev) || br-multicast_disabled)
return -EINVAL;
  
 +  memset(ip, 0, sizeof(ip));
+   ip.vid = entry-vid;
ip.proto = entry-addr.proto;
 -  if (ip.proto == htons(ETH_P_IP)) {
 -  if (timer_pending(br-ip4_other_query.timer))
 -  return -EBUSY;
 -
 +  if (ip.proto == htons(ETH_P_IP))
ip.u.ip4 = entry-addr.u.ip4;
  #if IS_ENABLED(CONFIG_IPV6)
 -  } else {
 -  if (timer_pending(br-ip6_other_query.timer))
 -  return -EBUSY;
 -
 +  else
ip.u.ip6 = entry-addr.u.ip6;
  #endif
 -  }
  
spin_lock_bh(br-multicast_lock);
mdb = mlock_dereference(br-mdb, br);


pgpm_Y4weDZDx.pgp
Description: OpenPGP digital signature

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

2015-05-28 Thread Tom Lendacky 

On 05/27/2015 11:17 PM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/amd-xgbe-phy.c between commit 983942a5eaca
(amd-xgbe-phy: Fix initial mode when autoneg is disabled) from Linus'
tree and commit 7c12aa08779c (amd-xgbe: Move the PHY support into
amd-xgbe) from the net-next tree.

I fixed it up (the latter removed the file, so I did that - there may
be more needed) and can carry the fix as necessary (no action is
required).


I looked over the tree and it appears that everything is good. Deleting
the file is the correct action and it looks like the necessary changes
to the Makefiles and Kconfigs are present to account for that.

Thanks,
Tom




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

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

2015-05-27 Thread Stephen Rothwell 
Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/amd-xgbe-phy.c between commit 983942a5eaca
(amd-xgbe-phy: Fix initial mode when autoneg is disabled) from Linus'
tree and commit 7c12aa08779c (amd-xgbe: Move the PHY support into
amd-xgbe) from the net-next tree.

I fixed it up (the latter removed the file, so I did that - there may
be more needed) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpfQBjvZ33om.pgp
Description: OpenPGP digital signature