Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 5月, 2018 1 次提交
  3. 08 5月, 2018 1 次提交
  5. 30 3月, 2018 2 次提交
  7. 03 1月, 2018 3 次提交
  9. 27 7月, 2017 1 次提交
  11. 03 7月, 2017 1 次提交
  13. 31 5月, 2017 3 次提交
  15. 25 5月, 2017 2 次提交
  17. 19 5月, 2017 1 次提交
  19. 18 4月, 2017 1 次提交
  21. 04 4月, 2017 1 次提交
  23. 29 3月, 2017 4 次提交
    • 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
  25. 15 3月, 2017 1 次提交
  27. 14 3月, 2017 1 次提交
  29. 20 2月, 2017 1 次提交
  31. 02 1月, 2017 1 次提交
  33. 11 11月, 2016 1 次提交
  35. 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
  37. 01 11月, 2016 5 次提交
  39. 04 10月, 2016 1 次提交
  41. 08 9月, 2016 1 次提交
  43. 07 9月, 2016 1 次提交
  45. 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
  47. 19 8月, 2016 1 次提交
  49. 09 8月, 2016 1 次提交
  51. 20 6月, 2016 1 次提交
  53. 09 6月, 2016 1 次提交