1. 19 8月, 2016 1 次提交
    • Y
      qede: Fix Tx timeout due to xmit_more · 039a3927
      Yuval Mintz 提交于
      Driver uses netif_tx_queue_stopped() to make sure the xmit_more
      indication will be honored, but that only checks for DRV_XOFF.
      
      At the same time, it's possible that during transmission the DQL will
      close the transmission queue with STACK_XOFF indication.
      In re-configuration flows, when the threshold is relatively low, it's
      possible that the device has no pending tranmissions, and during
      tranmission the driver would miss doorbelling the HW.
      Since there are no pending transmission, there will never be a Tx
      completion [and thus the DQL would not remove the STACK_XOFF indication],
      eventually causing the Tx queue to timeout.
      
      While we're at it - also doorbell in case driver has to close the
      transmission queue on its own [although this one is less important -
      if the ring is full, we're bound to receive completion eventually,
      which means the doorbell would only be postponed and not indefinetly
      blocked].
      
      Fixes: 312e0676 ("qede: Utilize xmit_more")
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      039a3927
  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 次提交
  22. 08 3月, 2016 1 次提交