Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 04 2月, 2016 1 次提交
  3. 08 1月, 2016 2 次提交
  5. 13 12月, 2015 2 次提交
  7. 03 12月, 2015 2 次提交
  9. 02 12月, 2015 2 次提交
  11. 26 11月, 2015 1 次提交
  13. 23 10月, 2015 1 次提交
  15. 20 10月, 2015 1 次提交
  17. 16 10月, 2015 1 次提交
  19. 15 10月, 2015 1 次提交
  21. 14 10月, 2015 2 次提交
  23. 09 10月, 2015 3 次提交
  25. 08 10月, 2015 1 次提交
    • M
      i40e: stop VF rings · 0325fca7
      由 Mitch Williams 提交于 
      Explicitly stop the rings belonging to each VF when disabling SR-IOV.
Even though the VFs were gone, and the associated VSIs were removed, the
rings were not stopped, and in some circumstances the hardware would
continue to access the memory formerly used by the rings, causing memory
corruption or DMAR errors, both of which would lead to general malaise
of the kernel.

To relieve this condition, explicitly stop all the rings associated with
each VF before releasing its resources.

Change-ID: I78c05d562c66e7b594b7e48d67860f49b3e5b6ec
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0325fca7
  27. 30 9月, 2015 1 次提交
  29. 29 9月, 2015 1 次提交
    • A
      i40e: Fix for recursive RTNL lock during PROMISC change · 30e2561b
      由 Anjali Singhai 提交于 
      The sync_vsi_filters function can be called directly under RTNL
or through the timer subtask without one. This was causing a deadlock.

If sync_vsi_filters is called from a thread which held the lock,
and in another thread the PROMISC setting got changed we would
be executing the PROMISC change in the thread which already held
the lock alongside the other filter update. The PROMISC change
requires a reset if we are on a VEB, which requires it to be called
under RTNL.

Earlier the driver would call reset for PROMISC change without
checking if we were already under RTNL and would try to grab it
causing a deadlock. This patch changes the flow to see if we are
already under RTNL before trying to grab it.
Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: NKiran Patil <kiran.patil@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      30e2561b
  31. 27 8月, 2015 3 次提交
  33. 06 8月, 2015 1 次提交
  35. 23 7月, 2015 3 次提交
  37. 15 7月, 2015 4 次提交
  39. 05 6月, 2015 1 次提交
    • A
      i40e: start up in VEPA mode by default · fc60861e
      由 Anjali Singhai Jain 提交于 
      The patch fixes a bug in the default configuration which
prevented a software bridge loaded on the PF interface from
working correctly because broadcast packets are incorrectly
looped back.

Fix the general case, by loading the driver in VEPA mode Until a
VF or VMDq VSI is added. This way loopback on the Main VSI is
turned off until needed and can resolve the issue of unnecessary
reflection for users that do not have VF or VMDq VSIs setup.

The driver must now coordinate the loopback setting for the Flow
Director (FDIR) VSI to make sure it is in sync with the current
VEB or VEPA mode setting.

The user can still switch bridge modes from the bridge commands and
choose to be in VEPA mode with VF VSIs. Because of hardware
requirements, the call to switch to VEB mode when no VF/VMDqs are
present will be rejected.

NOTE: This patch uses BIT_ULL as that is preferred going forward,
a followup patch in the lower priority queue to net-next will fix
up the remaining 1 << usages.

Change-ID: Ib121ddb18fe4b3c4f52e9deda6fcbeb9105683d1
Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fc60861e
  41. 28 5月, 2015 1 次提交
  43. 15 4月, 2015 4 次提交
  45. 03 4月, 2015 1 次提交