1. 16 8月, 2016 2 次提交
  2. 31 7月, 2016 2 次提交
  3. 01 7月, 2016 4 次提交
  4. 20 6月, 2016 1 次提交
  5. 18 6月, 2016 1 次提交
  6. 09 6月, 2016 1 次提交
  7. 04 6月, 2016 1 次提交
  8. 03 6月, 2016 1 次提交
    • Y
      qed: Utilize FW 8.10.3.0 · 351a4ded
      Yuval Mintz 提交于
      The New QED firmware contains several fixes, including:
        - Wrong classification of packets in 4-port devices.
        - Anti-spoof interoperability with encapsulated packets.
        - Tx-switching of encapsulated packets.
      It also slightly improves Tx performance of the device.
      
      In addition, this firmware contains the necessary logic for
      supporting iscsi & rdma, for which we plan on pushing protocol
      drivers in the imminent future.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      351a4ded
  9. 02 6月, 2016 1 次提交
    • A
      qed: fix qed_fill_link() error handling · 14b84e86
      Arnd Bergmann 提交于
      gcc warns about qed_fill_link possibly accessing uninitialized data:
      
      drivers/net/ethernet/qlogic/qed/qed_main.c: In function 'qed_fill_link':
      drivers/net/ethernet/qlogic/qed/qed_main.c:1170:35: error: 'link_caps' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      While this warning is only about the specific case of CONFIG_QED_SRIOV
      being disabled but the function getting called for a VF (which should
      never happen), another possibility is that qed_mcp_get_*() fails without
      returning data.
      
      This rearranges the code so we bail out in either of the two cases
      and print a warning instead of accessing the uninitialized data.
      
      The qed_link_output structure remains untouched in this case, but
      all callers first call memset() on it, so at least we are not leaking
      stack data then.
      
      As discussed, we also use a compile-time check to ensure we never
      use any of the VF code if CONFIG_QED_SRIOV is disabled, and the
      PCI device table is updated to no longer bind to virtual functions
      in that configuration.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14b84e86
  10. 27 5月, 2016 2 次提交
  11. 21 5月, 2016 1 次提交
  12. 20 5月, 2016 2 次提交
  13. 12 5月, 2016 8 次提交
  14. 09 5月, 2016 1 次提交
  15. 07 5月, 2016 1 次提交
    • S
      qede: prevent chip hang when increasing channels · 8e0ddc04
      Sudarsana Reddy Kalluru 提交于
      qede requires qed to provide enough resources to accommodate 16 combined
      channels, but that upper-bound isn't actually being enforced by it.
      Instead, qed inform back to qede how many channels can be opened based on
      available resources - but that calculation doesn't really take into account
      the resources requested by qede; Instead it considers other FW/HW available
      resources.
      
      As a result, if a user would increase the number of channels to more than
      16 [e.g., using ethtool] the chip would hang.
      
      This change increments the resources requested by qede to 64 combined
      channels instead of 16; This value is an upper bound on the possible
      available channels [due to other FW/HW resources].
      Signed-off-by: NSudarsana Reddy Kalluru <sudarsana.kalluru@qlogic.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e0ddc04
  16. 02 5月, 2016 1 次提交
  17. 26 4月, 2016 1 次提交
  18. 22 4月, 2016 3 次提交
  19. 16 4月, 2016 3 次提交
  20. 14 4月, 2016 2 次提交
  21. 11 3月, 2016 1 次提交