1. 01 5月, 2017 2 次提交
  2. 28 4月, 2017 2 次提交
  3. 25 4月, 2017 2 次提交
  4. 18 4月, 2017 1 次提交
  5. 07 4月, 2017 1 次提交
  6. 04 4月, 2017 1 次提交
  7. 29 3月, 2017 4 次提交
    • M
      qed: Use BDQ resource for storage protocols · d0d40a73
      Mintz, Yuval 提交于
      Until now, qed used some port-defined value as BDQ index for both iSCSI
      and FCoE.
      
      As management firmware now treats BDQ as a resource and tells each PF
      its BDQ-range, start using a valure from that range instead.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0d40a73
    • T
      qed: Utilize resource-lock based scheme · 9c8517c4
      Tomer Tayar 提交于
      Management firmware is used as an arbiter between the various PFs
      in matters of resources, but some of the resources that need to
      be divided are dependent on the non-management firmware used,
      so management firmware first needs to be told how many resources
      there are before trying to divide them.
      
      As part of the initialization sequence, driver would first inform
      the management firmware of the available resources under
      a dedicated resource lock, and afterwards request for various
      resources which might be based on the previous set values.
      Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c8517c4
    • T
      qed: Move to new load request scheme · 5d24bcf1
      Tomer Tayar 提交于
      Management firmware is used as an arbiter between the various PFs
      in regard to loading - it causes the various PFs to load/unload
      sequentially and informs each of its appropriate rule in the init.
      
      But the existing flow is too weak to handle some scenarios where
      PFs aren't properly cleaned prior to loading.
      The significant scenarios falling under this criteria:
        a. Preboot drivers in some environment can't properly unload.
        b. Unexpected driver replacement [kdump, PDA].
      
      Modern management firmware supports a more intricate loading flow,
      where the driver has the ability to overcome previous limitations.
      This moves qed into using this newer scheme.
      
      Notice new scheme is backward compatible, so new drivers would
      still be able to load properly on top of older management firmwares
      and vice versa.
      Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d24bcf1
    • T
      qed: Correct HW stop flow · 1226337a
      Tomer Tayar 提交于
      Management firmware is used as arbiter between different PFs
      which are loading/unloading, but in order to use the synchronization
      it offers the contending configurations need to be applied either
      between their LOAD_REQ <-> LOAD_DONE or UNLOAD_REQ <-> UNLOAD_DONE
      management firmware commands.
      
      Existing HW stop flow utilizes 2 different functions: qed_hw_stop() and
      qed_hw_reset() which don't abide this requirement; Most of the closure
      is doing outside the scope of the unload request.
      
      This patch removes qed_hw_reset() and places the relevant stop
      functionality underneath the management firmware protection.
      Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1226337a
  8. 15 3月, 2017 1 次提交
  9. 14 3月, 2017 1 次提交
  10. 27 2月, 2017 1 次提交
  11. 20 2月, 2017 1 次提交
  12. 16 2月, 2017 1 次提交
  13. 02 1月, 2017 2 次提交
  14. 03 12月, 2016 2 次提交
  15. 01 12月, 2016 1 次提交
    • M
      qed*: Handle-based L2-queues. · 3da7a37a
      Mintz, Yuval 提交于
      The driver needs to maintain several FW/HW-indices for each one of
      its queues. Currently, that mapping is done by the QED where it uses
      an rx/tx array of so-called hw-cids, populating them whenever a new
      queue is opened and clearing them upon destruction of said queues.
      
      This maintenance is far from ideal - there's no real reason why
      QED needs to maintain such a data-structure. It becomes even worse
      when considering the fact that the PF's queues and its child VFs' queues
      are all mapped into the same data-structure.
      As a by-product, the set of parameters an interface needs to supply for
      queue APIs is non-trivial, and some of the variables in the API
      structures have different meaning depending on their exact place
      in the configuration flow.
      
      This patch re-organizes the way L2 queues are configured and maintained.
      In short:
        - Required parameters for queue init are now well-defined.
        - Qed would allocate a queue-cid based on parameters.
          Upon initialization success, it would return a handle to caller.
        - Queue-handle would be maintained by entity requesting queue-init,
          not necessarily qed.
        - All further queue-APIs [update, destroy] would use the opaque
          handle as reference for the queue instead of various indices.
      
      The possible owners of such handles:
        - PF queues [qede] - complete handles based on provided configuration.
        - VF queues [qede] - fw-context-less handles, containing only relative
          information; Only the PF-side would need the absolute indices
          for configuration, so they're omitted here.
        - VF queues [qed, PF-side] - complete handles based on VF initialization.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3da7a37a
  16. 01 11月, 2016 4 次提交
  17. 04 10月, 2016 3 次提交
  18. 08 9月, 2016 1 次提交
  19. 23 8月, 2016 1 次提交
  20. 20 8月, 2016 1 次提交
    • Y
      qed: utilize FW 8.10.10.0 · 05fafbfb
      Yuval Mintz 提交于
      This new firmware for the qed* adpaters fixes several issues:
       - Better blocking of malicious VFs.
       - After FLR, Tx-switching [internal routing] of packets might
         be incorrect.
       - Deletion of unicast MAC filters would sometime have side-effect
         of corrupting the MAC filters configred for a device.
      It also contains fixes for future qed* drivers that *hopefully* would be
      sent for review in the near future.
      
      In addition, it would allow driver some new functionality, including:
       - Allowing PF/VF driver compaitibility with old drivers [running
         pre-8.10.5.0 firmware].
       - Better debug facilities.
      
      This would also bump the qed* driver versions to 8.10.9.20.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05fafbfb
  21. 19 8月, 2016 1 次提交
  22. 29 6月, 2016 1 次提交
  23. 04 6月, 2016 2 次提交
  24. 18 5月, 2016 1 次提交
  25. 12 5月, 2016 2 次提交