1. 30 1月, 2016 3 次提交
  2. 13 1月, 2016 1 次提交
    • A
      net: bnxt: always return values from _bnxt_get_max_rings · 415b6f19
      Arnd Bergmann 提交于
      Newly added code in the bnxt driver uses a couple of variables that
      are never initialized when CONFIG_BNXT_SRIOV is not set, and gcc
      correctly warns about that:
      
      In file included from include/linux/list.h:8:0,
                       from include/linux/module.h:9,
                       from drivers/net/ethernet/broadcom/bnxt/bnxt.c:10:
      drivers/net/ethernet/broadcom/bnxt/bnxt.c: In function 'bnxt_get_max_rings':
      include/linux/kernel.h:794:26: warning: 'cp' may be used uninitialized in this function [-Wmaybe-uninitialized]
      include/linux/kernel.h:794:26: warning: 'tx' may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/net/ethernet/broadcom/bnxt/bnxt.c:5730:11: warning: 'rx' may be used uninitialized in this function [-Wmaybe-uninitialized]
      drivers/net/ethernet/broadcom/bnxt/bnxt.c:5736:6: note: 'rx' was declared here
      
      This changes the condition so that we fall back to using the PF
      data if VF is not available, and always initialize the variables
      to something useful.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 6e6c5a57 ("bnxt_en: Modify bnxt_get_max_rings() to support shared or non shared rings.")
      Acked-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      415b6f19
  3. 11 1月, 2016 2 次提交
  4. 05 1月, 2016 7 次提交
  5. 28 12月, 2015 12 次提交
  6. 12 12月, 2015 4 次提交
  7. 04 12月, 2015 3 次提交
  8. 19 11月, 2015 1 次提交
    • E
      net: provide generic busy polling to all NAPI drivers · 93d05d4a
      Eric Dumazet 提交于
      NAPI drivers no longer need to observe a particular protocol
      to benefit from busy polling (CONFIG_NET_RX_BUSY_POLL=y)
      
      napi_hash_add() and napi_hash_del() are automatically called
      from core networking stack, respectively from
      netif_napi_add() and netif_napi_del()
      
      This patch depends on free_netdev() and netif_napi_del() being
      called from process context, which seems to be the norm.
      
      Drivers might still prefer to call napi_hash_del() on their
      own, since they might combine all the rcu grace periods into
      a single one, knowing their NAPI structures lifetime, while
      core networking stack has no idea of a possible combining.
      
      Once this patch proves to not bring serious regressions,
      we will cleanup drivers to either remove napi_hash_del()
      or provide appropriate rcu grace periods combining.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93d05d4a
  9. 06 11月, 2015 5 次提交
  10. 26 10月, 2015 1 次提交
  11. 24 10月, 2015 1 次提交