1. 23 8月, 2019 1 次提交
  2. 16 8月, 2019 2 次提交
  3. 09 8月, 2019 1 次提交
  4. 03 8月, 2019 1 次提交
  5. 27 7月, 2019 1 次提交
  6. 25 7月, 2019 1 次提交
    • A
      qed: reduce maximum stack frame size · 7c116e02
      Arnd Bergmann 提交于
      clang warns about an overly large stack frame in one function
      when it decides to inline all __qed_get_vport_*() functions into
      __qed_get_vport_stats():
      
      drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=]
      
      Use a noinline_for_stack annotation to prevent clang from inlining
      these, which keeps the maximum stack usage at around half of that
      in the worst case, similar to what we get with gcc.
      
      Fixes: 86622ee7 ("qed: Move statistics to L2 code")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c116e02
  7. 22 7月, 2019 1 次提交
  8. 04 7月, 2019 1 次提交
  9. 19 6月, 2019 1 次提交
    • A
      qed: Fix -Wmaybe-uninitialized false positive · 815deee0
      Arnd Bergmann 提交于
      A previous attempt to shut up the uninitialized variable use
      warning was apparently insufficient. When CONFIG_PROFILE_ANNOTATED_BRANCHES
      is set, gcc-8 still warns, because the unlikely() check in DP_NOTICE()
      causes it to no longer track the state of all variables correctly:
      
      drivers/net/ethernet/qlogic/qed/qed_dev.c: In function 'qed_llh_set_ppfid_affinity':
      drivers/net/ethernet/qlogic/qed/qed_dev.c:798:47: error: 'abs_ppfid' may be used uninitialized in this function [-Werror=maybe-uninitialized]
        addr = NIG_REG_PPF_TO_ENGINE_SEL + abs_ppfid * 0x4;
                                           ~~~~~~~~~~^~~~~
      
      This is not a nice workaround, but always initializing the output from
      qed_llh_abs_ppfid() at least shuts up the false positive reliably.
      
      Fixes: 79284ade ("qed: Add llh ppfid interface and 100g support for offload protocols")
      Fixes: 8e2ea3ea ("qed: Fix static checker warning")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: Michal Kalderon <michal.kalderon@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      815deee0
  10. 15 6月, 2019 4 次提交
  11. 05 6月, 2019 1 次提交
  12. 03 6月, 2019 1 次提交
  13. 31 5月, 2019 1 次提交
  14. 30 5月, 2019 1 次提交
  15. 29 5月, 2019 1 次提交
  16. 27 5月, 2019 8 次提交
  17. 17 4月, 2019 1 次提交
  18. 15 4月, 2019 4 次提交
  19. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon 提交于
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  20. 21 3月, 2019 1 次提交
  21. 22 2月, 2019 1 次提交
  22. 19 2月, 2019 2 次提交
  23. 14 2月, 2019 1 次提交
  24. 09 2月, 2019 1 次提交
  25. 07 2月, 2019 1 次提交