Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 3月, 2017 1 次提交
  3. 27 2月, 2017 2 次提交
    • M
      qed: Don't use attention PTT for configuring BW · 6f437d43
      由 Mintz, Yuval 提交于 
      Commit 653d2ffd6405 ("qed*: Fix link indication race") introduced another
race - one of the inner functions called from the link-change flow is
explicitly using the slowpath context dedicated PTT instead of gaining
that PTT from the caller. Since this flow can now be called from
a different context as well, we're in risk of the PTT breaking.

Fixes: 653d2ffd6405 ("qed*: Fix link indication race")
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f437d43
    • M
      qed: Fix race with multiple VFs · fd3c615a
      由 Mintz, Yuval 提交于 
      A PF syncronizes all IOV activity relating to its VFs
by using a single workqueue handling the work.
The workqueue would reach a bitmask of pending VF events
and act upon each in turn.

Problem is that the indication of a VF message [which sets
the 'vf event' bit for that VF] arrives and is set in
the slowpath attention context, which isn't syncronized with
the processing of the events.
When multiple VFs are present, it's possible that PF would
lose the indication of one of the VF's pending evens, leading
that VF to later timeout.

Instead of adding locks/barriers, simply move from a bitmask
into a per-VF indication inside that VF entry in the PF database.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd3c615a
  5. 21 2月, 2017 7 次提交
  7. 20 2月, 2017 1 次提交
  9. 16 2月, 2017 1 次提交
  11. 21 1月, 2017 1 次提交
    • A
      qed: avoid possible stack overflow in qed_ll2_acquire_connection · 0629a330
      由 Arnd Bergmann 提交于 
      struct qed_ll2_info is rather large, so putting it on the stack
can cause an overflow, as this warning tries to tell us:

drivers/net/ethernet/qlogic/qed/qed_ll2.c: In function 'qed_ll2_start':
drivers/net/ethernet/qlogic/qed/qed_ll2.c:2159:1: error: the frame size of 1056 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

qed_ll2_start_ooo() already uses a dynamic allocation for the structure
to work around that problem, and we could do the same in qed_ll2_start()
as well as qed_roce_ll2_start(), but since the structure is only
used to pass a couple of initialization values here, it seems nicer
to replace it with a different structure.

Lacking any idea for better naming, I'm adding 'struct qed_ll2_conn',
which now contains all the initialization data, and this now simply
gets copied into struct qed_ll2_info rather than assigning all members
one by one.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0629a330
  13. 18 1月, 2017 1 次提交
  15. 02 1月, 2017 7 次提交
  17. 18 12月, 2016 1 次提交
  19. 14 12月, 2016 1 次提交
  21. 06 12月, 2016 1 次提交
  23. 03 12月, 2016 2 次提交
  25. 01 12月, 2016 2 次提交
    • 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
    • M
      qed: Optimize qed_chain datapath usage · 6d937acf
      由 Mintz, Yuval 提交于 
      The chain structure and functions are widely used by the qed* modules,
both for configuration and datapath.
E.g., qede's Tx has one such chain and its Rx has two.

Currently, the strucutre's fields which are required for datapath
related functions [produce/consume] are intertwined with fields which
are required only for configuration purposes [init/destroy/etc.].

This patch re-arranges the chain structure so that all the fields which
are required for datapath usage could reside in a single cacheline instead
of the two which are required today.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d937acf
  27. 11 11月, 2016 2 次提交
  29. 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
  31. 01 11月, 2016 7 次提交
  33. 23 10月, 2016 2 次提交