Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 12月, 2013 1 次提交
  3. 06 12月, 2013 1 次提交
  5. 29 10月, 2013 1 次提交
    • A
      bnx2x: Disable VF access on PF removal · 826cb7b4
      由 Ariel Elior 提交于 
      When the bnx2x driver is rmmoded, if VFs of a given PF will be assigned
to a VM then that PF will be unable to call `pci_disable_sriov()'.

If for that same PF there would also exist unassigned VFs in the hypervisor,
the result will be that after the removal there will still be virtual PCI
functions on the hypervisor.
If the bnx2x module were to be re-inserted, the result will be that the VFs
on the hypervisor will be re-probed directly following the PF's probe, even
though that in regular loading flow sriov is only enabled once PF is loaded.
The probed VF will then try to access its bar, causing a PCI error as the HW
is not in a state enabling such a request.

This patch adds a missing disablement procedure to the PF's removal, one that
sets registers viewable to the VF to indicate that the VFs have no permission
to access the bar, thus resulting in probe errors instead of PCI errors.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      826cb7b4
  7. 22 10月, 2013 2 次提交
  9. 29 9月, 2013 1 次提交
  11. 24 9月, 2013 2 次提交
  13. 21 9月, 2013 1 次提交
  15. 10 9月, 2013 1 次提交
  17. 06 9月, 2013 1 次提交
  19. 28 8月, 2013 2 次提交
  21. 20 8月, 2013 2 次提交
  23. 14 8月, 2013 1 次提交
  25. 02 8月, 2013 1 次提交
    • Y
      bnx2x: Revising locking scheme for MAC configuration · 8b09be5f
      由 Yuval Mintz 提交于 
      On very rare occasions, repeated load/unload stress test in the presence of
our storage driver (bnx2i/bnx2fc) causes a kernel panic in bnx2x code
(NULL pointer dereference). Stack traces indicate the issue happens during MAC
configuration; thorough code review showed that indeed several races exist
in which one thread can iterate over the list of configured MACs while another
deletes entries from the same list.

This patch adds a varient on the single-writer/Multiple-reader lock mechanism -
It utilizes an already exsiting bottom-half lock, using it so that Whenever
a writer is unable to continue due to the existence of another writer/reader,
it pends its request for future deliverance.
The writer / last readers will check for the existence of such requests and
perform them instead of the original initiator.
This prevents the writer from having to sleep while waiting for the lock
to be accessible, which might cause deadlocks given the locks already
held by the writer.

Another result of this patch is that setting of Rx Mode is now made in
sleepable context - Setting of Rx Mode is made under a bottom-half lock, which
was always nontrivial for the bnx2x driver, as the HW/FW configuration requires
wait for completions.
Since sleep was impossible (due to the sleepless-context), various mechanisms
were utilized to prevent the calling thread from sleep, but the truth was that
when the caller thread (i.e, the one calling ndo_set_rx_mode()) returned, the
Rx mode was still not set in HW/FW.

bnx2x_set_rx_mode() will now overtly schedule for the Rx changes to be
configured by the sp_rtnl_task which hold the RTNL lock and is sleepable
context.
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b09be5f
  27. 24 6月, 2013 4 次提交
  29. 03 6月, 2013 3 次提交
  31. 28 3月, 2013 3 次提交
  33. 12 3月, 2013 3 次提交
  35. 24 1月, 2013 1 次提交
    • A
      bnx2x: SR-IOV version compatibility bugfix · 4c133c39
      由 Ariel Elior 提交于 
      When posting a message on the bulletin board, the PF calculates crc
over the message and places the result in the message. When the VF
samples the Bulletin Board it copies the message aside and validates
this crc. The length of the message is crucial here and must be the
same in both parties. Since the PF is running in the Hypervisor and
the VF is running in a Vm, they can possibly be of different versions.
As the Bulletin Board is designed to grow forward in future versions,
in the VF the length must not be the size of the message structure
but instead it should be a field in the message itself.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c133c39
  37. 16 1月, 2013 1 次提交
  39. 10 1月, 2013 1 次提交
  41. 08 1月, 2013 1 次提交
  43. 02 1月, 2013 6 次提交