1. 27 Jul, 2015 34 commits
  2. 26 Jul, 2015 6 commits
    • KY Srinivasan's avatar
      hv_netvsc: Wait for sub-channels to be processed during probe · b3e6b82a
      KY Srinivasan authored
      The current code returns from probe without waiting for the proper handling
      of subchannels that may be requested. If the netvsc driver were to be rapidly
      loaded/unloaded, we can  trigger a panic as the unload will be tearing
      down state that may not have been fully setup yet. We fix this issue by making
      sure that we return from the probe call only after ensuring that the
      sub-channel offers in flight are properly handled.
      
      Reviewed-and-tested-by: Haiyang Zhang <haiyangz@microsoft.com
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3e6b82a
    • Hariprasad Shenai's avatar
      cxgb4: Allow firmware flash, only if cxgb4 is the master driver · 402b7645
      Hariprasad Shenai authored
      Adapter can go for a toss, if cxgb4 is loaded as slave and we try to
      upgrade the firmware. So add a check for the same before flashing
      firmware using ethtool.
      Signed-off-by: default avatarHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      402b7645
    • Thomas Graf's avatar
      vxlan: Use proper endian type for vni in vxlan[6]_xmit_skb · 6b6948dd
      Thomas Graf authored
      Silences the following sparse warnings:
      drivers/net/vxlan.c:1818:21: warning: incorrect type in assignment (different base types)
      drivers/net/vxlan.c:1818:21:    expected restricted __be32 [usertype] vx_vni
      drivers/net/vxlan.c:1818:21:    got unsigned int [unsigned] [usertype] vni
      drivers/net/vxlan.c:2014:58: warning: incorrect type in argument 11 (different base types)
      drivers/net/vxlan.c:2014:58:    expected unsigned int [unsigned] [usertype] vni
      drivers/net/vxlan.c:2014:58:    got restricted __be32 [usertype] <noident>
      
      Fixes: 614732ea ("openvswitch: Use regular VXLAN net_device device")
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b6948dd
    • David S. Miller's avatar
      Merge branch 'tipc' · 1d70ec70
      David S. Miller authored
      Jon Maloy says:
      
      ====================
      tipc: clean up socket message reception
      
      Despite recent improvements the message reception code in socket.c is
      perceived as obscure and hard to follow, especially regarding the logics
      for message rejection. With the commits in this series we try to remedy
      this situation.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d70ec70
    • Jon Paul Maloy's avatar
      tipc: clean up socket layer message reception · cda3696d
      Jon Paul Maloy authored
      When a message is received in a socket, one of the call chains
      tipc_sk_rcv()->tipc_sk_enqueue()->filter_rcv()(->tipc_sk_proto_rcv())
      or
      tipc_sk_backlog_rcv()->filter_rcv()(->tipc_sk_proto_rcv())
      are followed. At each of these levels we may encounter situations
      where the message may need to be rejected, or a new message
      produced for transfer back to the sender. Despite recent
      improvements, the current code for doing this is perceived
      as awkward and hard to follow.
      
      Leveraging the two previous commits in this series, we now
      introduce a more uniform handling of such situations. We
      let each of the functions in the chain itself produce/reverse
      the message to be returned to the sender, but also perform the
      actual forwarding. This simplifies the necessary logics within
      each function.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cda3696d
    • Jon Paul Maloy's avatar
      tipc: introduce new tipc_sk_respond() function · bcd3ffd4
      Jon Paul Maloy authored
      Currently, we use the code sequence
      
      if (msg_reverse())
         tipc_link_xmit_skb()
      
      at numerous locations in socket.c. The preparation of arguments
      for these calls, as well as the sequence itself, makes the code
      unecessarily complex.
      
      In this commit, we introduce a new function, tipc_sk_respond(),
      that performs this call combination. We also replace some, but not
      yet all, of these explicit call sequences with calls to the new
      function. Notably, we let the function tipc_sk_proto_rcv() use
      the new function to directly send out PROBE_REPLY messages,
      instead of deferring this to the calling tipc_sk_rcv() function,
      as we do now.
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bcd3ffd4