Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 7月, 2017 4 次提交
  3. 03 7月, 2017 1 次提交
  5. 05 6月, 2017 1 次提交
    • M
      qed: VFs to try utilizing the doorbell bar · 1a850bfc
      由 Mintz, Yuval 提交于 
      VFs are currently not mapping their doorbell bar, instead relying
on the small doorbell window they have in their limited regview bar.

In order to increase the number of possible Tx connections [queues]
employeed by VF past 16, we need to start using the doorbell bar if
one such is exposed - VF would communicate this fact to PF which would
return the size-bar internally configured into chip, according to
which the VF would decide whether to actually utilize the doorbell
bar.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a850bfc
  7. 02 6月, 2017 3 次提交
  9. 31 5月, 2017 1 次提交
    • M
      qed: Don't log missing periodic stats by default · 512c7840
      由 Mintz, Yuval 提交于 
      Current implementation lacks the logic for providing management
firmware with RDMA-related statistics; [much] worse than that -
it logs such events by default to system logs.

Since the statistics' gathering is done periodically, using sufficiently
new management firmware the system logs would get filled with these
unnecessary prints.

For now, reduce the verbosity of the log so that it would not be
logged by default.

Fixes: 6c754246 ("qed: Add support for NCSI statistics")
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      512c7840
  11. 25 5月, 2017 3 次提交
  13. 19 5月, 2017 1 次提交
  15. 09 5月, 2017 2 次提交
  17. 05 5月, 2017 2 次提交
  19. 01 5月, 2017 1 次提交
  21. 28 4月, 2017 1 次提交
  23. 25 4月, 2017 3 次提交
  25. 18 4月, 2017 1 次提交
  27. 07 4月, 2017 2 次提交
  29. 04 4月, 2017 1 次提交
  31. 29 3月, 2017 3 次提交
    • 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
    • M
      qed: hw_init() to receive parameter-struct · c0c2d0b4
      由 Mintz, Yuval 提交于 
      We'll soon need additional information, so start by changing
the infrastructure to receive the initializing variables
via a parameter struct.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0c2d0b4
    • 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
  33. 15 3月, 2017 1 次提交
  35. 21 2月, 2017 2 次提交
    • 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
    • M
      qed: Don't allocate SBs using main PTT · 85750d74
      由 Mintz, Yuval 提交于 
      Flows accessing registers require the flow to hold a PTT entry.
To protect 'major' load/unload flows a main_ptt is pre-allocated
to guarantee such flows wouldn't be blocked by PTT being
unavailable.

Status block initialization currently uses the main_ptt which
is incorrect, as this flow might run concurrently to others
[E.g., loading qedr while toggling qede]. That would have dire
effects as it means registers' access to device breaks and further
read/writes might access incorrect addresses.

Instead, when initializing status blocks acquire/release a PTT
as part of the flow.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85750d74
  37. 20 2月, 2017 1 次提交
  39. 16 2月, 2017 1 次提交
  41. 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
  43. 11 11月, 2016 1 次提交
  45. 01 11月, 2016 2 次提交