1. 25 5月, 2017 1 次提交
  2. 22 5月, 2017 1 次提交
  3. 28 4月, 2017 1 次提交
  4. 05 4月, 2017 1 次提交
  5. 29 3月, 2017 5 次提交
    • 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: Support management-based resource locking · 95691c9c
      Tomer Tayar 提交于
      Global locking can't properly be used to synchronize between different
      PFs in all scenarios, as those instances might reside in different
      logical partitions [e.g., when a PF is assigned via PDA to some VM].
      
      The management firmware provides a generic infrastructure for
      device locks. For each 'resource', it's guaranteed it could be acquired
      by at most a single PF at any given time [or by management firmware].
      
      This patch adds the necessary logic in qed for utilizing said
      infrastructure, implementing lock/unlock internal APIs.
      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>
      95691c9c
    • M
      qed: Send pf-flr as part of initialization · 18a69e36
      Mintz, Yuval 提交于
      During HW initialization, driver would set various registers to their
      needed values - but it assumes all registers start at their reset-value,
      so there's no need to re-configure a register's default value.
      
      This assumption might be incorrect, e.g., in case of preboot driver
      running and initializing the driver prior to our driver.
      
      To overcome this, we now ask management firmware to initiate a PF-flr
      early during the initialization sequence. That would return everything
      in the PF's scope back to default and prevent previous configurations
      from still being applied.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18a69e36
    • 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
  6. 24 3月, 2017 4 次提交
    • M
      qed: Reduce verbosity of unimplemented MFW messages · 39815944
      Mintz, Yuval 提交于
      Management firmware and driver are meant to be both backward and forward
      compatibile with each other.
      
      If a new mangement firmware would work with an older driver,
      it's possible that driver would receive indications which are meaningless
      to it. That's perfectly acceptible from the firmware part - so no need to
      log such messages at default verbosity; That would only serve to confuse
      users.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39815944
    • M
      qed: Correct endian order of MAC passed to MFW · 17991002
      Mintz, Yuval 提交于
      The management firmware is running on a Big Endian processor,
      and when running on LE platform HW is configured to swap access
      to memory shared between management firmware and driver on
      32-bit granulariy.
      
      As a result, for matters of simplicity most of the APIs between
      driver and management firmware are based on 32-bit variables.
      MAC settings are one exception, as driver needs to fill a byte
      array when indicating to management firmware that primary MAC
      has changed.
      Due to the swap, driver must make sure that the mac that was
      provided in byte-order would be translated into native order,
      otherwise after the swap the management firmware would read
      it swapped.
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17991002
    • T
      qed: Pass src/dst sizes when interacting with MFW · 2f67af8c
      Tomer Tayar 提交于
      The driver interaction with management firmware involves a union
      of all the data-members relating to the commands the driver prepares.
      
      Current interface assumes the caller always passes such a union -
      but thats cumbersome as well as risky [chancing a stack corruption
      in case caller accidentally passes a smaller member instead of union].
      
      Change implementation so that caller could pass a pointer to any
      of the members instead of the union.
      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>
      2f67af8c
    • T
      qed: Revise MFW command locking · 4ed1eea8
      Tomer Tayar 提交于
      Interaction of driver -> management firmware is based
      on a one-pending mailbox [per interface], and various
      mailbox commands need to be synchronized.
      
      Current scheme is messy, and there's a difficulty extending
      it as it deals differently with various commands as well as
      making assumption on the required behavior for load/unload
      requests.
      
      Drop the current scheme into a completion-list-based approach;
      Each flow would try sending the command when possible,
      allowing one flow to complete another flow's completion and
      relieve the mailbox before sending its own command.
      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>
      4ed1eea8
  7. 27 2月, 2017 1 次提交
  8. 21 2月, 2017 1 次提交
    • M
      qed*: Fix link indication race · 65ed2ffd
      Mintz, Yuval 提交于
      Driver changes the link properties via communication with
      the management firmware, and re-reads the resulting link status
      when it receives an indication that the link has changed.
      However, there are certain scenarios where such indications
      might be missing, and so driver also re-reads the current link
      results without attention in several places. Specifically, it
      does so during load and when resetting the link.
      
      This creates a race where driver might reflect incorrect
      link status - e.g., when explicit reading of the link status is
      switched by attention with the changed configuration.
      
      Correct this flow by a lock syncronizing the handling of the
      link indications [both explicit requests and attention].
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65ed2ffd
  9. 20 2月, 2017 1 次提交
  10. 02 1月, 2017 2 次提交
  11. 10 11月, 2016 1 次提交
    • M
      qed: Prevent stack corruption on MFW interaction · bb480242
      Mintz, Yuval 提交于
      Driver uses a union for copying data to & from management firmware
      when interacting with it.
      Problem is that the function always copies sizeof(union) while commit
      2edbff8d ("qed: Learn resources from management firmware") is casting
      a union elements which is of smaller size [24-byte instead of 88-bytes].
      
      Also, the union contains some inappropriate elements which increase its
      size [should have been 32-bytes]. While this shouldn't corrupt other
      PF messages to the MFW [as management firmware enforces permissions so
      that each PF is allowed to write only to its own mailbox] we fix this
      here as well.
      
      Fixes: 2edbff8d ("qed: Learn resources from management firmware")
      Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb480242
  12. 01 11月, 2016 5 次提交
  13. 20 9月, 2016 1 次提交
  14. 07 9月, 2016 2 次提交
  15. 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
  16. 19 8月, 2016 1 次提交
  17. 16 8月, 2016 3 次提交
  18. 11 8月, 2016 1 次提交
  19. 04 6月, 2016 1 次提交
  20. 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
  21. 18 5月, 2016 1 次提交
  22. 12 5月, 2016 2 次提交
    • 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
  23. 02 5月, 2016 1 次提交
  24. 27 4月, 2016 1 次提交