1. 20 2月, 2017 1 次提交
  2. 16 2月, 2017 1 次提交
  3. 02 1月, 2017 2 次提交
    • M
      qed*: Change maximal number of queues · e1d32acb
      Mintz, Yuval 提交于
      Today qede requests contexts that would suffice for 64 'whole'
      combined queues [192 meant for 64 rx, tx and xdp tx queues],
      but registers netdev and limits the number of queues based on
      information received by qed. In turn, qed doesn't take context
      into account when informing qede how many queues it can support.
      
      This would lead to a configuration problem in case user tries
      configuring >64 combined queues to interface [or >96 in case
      xdp isn't enabled]. Since we don't have a mangement firware
      that actually provides so many interrupt lines to a single
      device we're currently safe but that's about to change soon.
      
      The new maximum is hence changed:
        - For RoCE devices, the limit would remain 64.
        - For non-RoCE devices, the limit might be higher [depending
          on the actual configuration of the device].
      qed would start enforcing that limit in both scenarios.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1d32acb
    • M
      qed*: Update to dual-license · e8f1cb50
      Mintz, Yuval 提交于
      Since the submission of the qedr driver, there's inconsistency
      in the licensing of the various qed/qede files - some are GPLv2
      and some are dual-license.
      Since qedr requires dual-license and it's dependent on both,
      we're updating the licensing of all qed/qede source files.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8f1cb50
  4. 11 11月, 2016 1 次提交
  5. 01 11月, 2016 3 次提交
  6. 23 10月, 2016 1 次提交
  7. 14 10月, 2016 2 次提交
  8. 04 10月, 2016 2 次提交
  9. 08 9月, 2016 2 次提交
  10. 07 9月, 2016 1 次提交
    • J
      qed: Remove OOM messages · 2591c280
      Joe Perches 提交于
      These messages are unnecessary as OOM allocation failures already do
      a dump_stack() giving more or less the same information.
      
      $ size drivers/net/ethernet/qlogic/qed/built-in.o* (defconfig x86-64)
         text	   data	    bss	    dec	    hex	filename
       127817	  27969	  32800	 188586	  2e0aa	drivers/net/ethernet/qlogic/qed/built-in.o.new
       132474	  27969	  32800	 193243	  2f2db	drivers/net/ethernet/qlogic/qed/built-in.o.old
      
      Miscellanea:
      
      o Change allocs to the generally preferred forms where possible.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2591c280
  11. 19 8月, 2016 1 次提交
  12. 16 8月, 2016 2 次提交
  13. 11 8月, 2016 1 次提交
  14. 02 8月, 2016 1 次提交
  15. 24 6月, 2016 1 次提交
  16. 20 6月, 2016 1 次提交
  17. 04 6月, 2016 1 次提交
  18. 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
  19. 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
  20. 27 5月, 2016 1 次提交
  21. 18 5月, 2016 1 次提交
  22. 17 5月, 2016 1 次提交
  23. 12 5月, 2016 5 次提交
    • Y
      qed*: Tx-switching configuration · 831bfb0e
      Yuval Mintz 提交于
      Device should be configured by default to VEB once VFs are active.
      This changes the configuration of both PFs' and VFs' vports into enabling
      tx-switching once sriov is enabled.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      831bfb0e
    • Y
      qed: Bulletin and Link · 36558c3d
      Yuval Mintz 提交于
      Up to this point, VF and PF communication always originates from VF.
      As a result, VF cannot be notified of any async changes, and specifically
      cannot be informed of the current link state.
      
      This introduces the bulletin board, the mechanism through which the PF
      is going to communicate async notifications back to the VF. basically,
      it's a well-defined structure agreed by both PF and VF which the VF would
      continuously poll and into which the PF would DMA messages when needed.
      [Bulletin board is actually allocated and communicated in previous patches
      but never before used]
      
      Based on the bulletin infrastructure, the VF can query its link status
      and receive said async carrier changes.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36558c3d
    • Y
      qed: IOV configure and FLR · 0b55e27d
      Yuval Mintz 提交于
      While previous patches have already added the necessary logic to probe
      VFs as well as enabling them in the HW, this patch adds the ability to
      support VF FLR & SRIOV disable.
      
      It then wraps both flows together into the first IOV callback to be
      provided to the protocol driver - `configure'. This would later to be used
      to enable and disable SRIOV in the adapter.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b55e27d
    • Y
      qed: Introduce VFs · 1408cc1f
      Yuval Mintz 提交于
      This adds the qed VFs for the first time -
      The vfs are limited functions, with a very different PCI bar structure
      [when compared with PFs] to better impose the related security demands
      associated with them.
      
      This patch includes the logic neccesary to allow VFs to successfully probe
      [without actually adding the ability to enable iov].
      This includes diverging all the flows that would occur as part of the pci
      probe of the driver, preventing VF from accessing registers/memories it
      can't and instead utilize the VF->PF channel to query the PF for needed
      information.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1408cc1f
    • Y
      qed: Add VF->PF channel infrastructure · 37bff2b9
      Yuval Mintz 提交于
      Communication between VF and PF is based on a dedicated HW channel;
      VF will prepare a messge, and by signaling the HW the PF would get a
      notification of that message existance. The PF would then copy the
      message, process it and DMA an answer back to the VF as a response.
      
      The messages themselves are TLV-based - allowing easier backward/forward
      compatibility.
      
      This patch adds the infrastructure of the channel on the PF side -
      starting with the arrival of the notification and ending with DMAing
      the response back to the VF.
      
      It also adds a dummy-response as reference, as it only lays the
      groundwork of the communication; it doesn't really add support of any
      actual messages.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37bff2b9
  24. 02 5月, 2016 1 次提交
  25. 26 4月, 2016 2 次提交
  26. 16 4月, 2016 3 次提交