Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 26 11月, 2015 1 次提交
  3. 23 10月, 2015 1 次提交
  5. 20 10月, 2015 1 次提交
  7. 16 10月, 2015 1 次提交
  9. 15 10月, 2015 1 次提交
  11. 14 10月, 2015 2 次提交
  13. 09 10月, 2015 3 次提交
  15. 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
  17. 30 9月, 2015 1 次提交
  19. 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
  21. 27 8月, 2015 3 次提交
  23. 06 8月, 2015 1 次提交
  25. 23 7月, 2015 3 次提交
  27. 15 7月, 2015 4 次提交
  29. 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
  31. 28 5月, 2015 1 次提交
  33. 15 4月, 2015 4 次提交
  35. 03 4月, 2015 3 次提交
  37. 09 3月, 2015 1 次提交
  39. 07 3月, 2015 1 次提交
  41. 05 3月, 2015 1 次提交
  43. 03 3月, 2015 1 次提交
  45. 25 2月, 2015 1 次提交
    • N
      i40e: Add support for getlink, setlink ndo ops · 51616018
      由 Neerav Parikh 提交于 
      Add support for bridge offload ndo_ops getlink and setlink to
enable bridge hardware mode as per the mode set via IFLA_BRIDGE_MODE.
The support is only enabled in case of a PF VSI and not available for
any other VSI type.

By default the i40e driver inserts a bridge as part of the bring-up
when a FDIR type VSI and/or a FCoE VSI is created. This bridge is
created in VEB mode by default i.e. after creating the bridge using
"Add VEB" AQ command the loopback for the PF's default VSI is enabled.

The patch adds capability where all the VSIs created as downlink to
the bridge inherits the loopback property and enables loopback only
if the uplink bridge is operating in VEB mode.
Hence, there is no need to explicitly enable loopback as part of
allocating resources for SR-IOV VFs and call to do that has been
removed.

In case a user-request is made either via "bridge" utility or using
the bridge netlink interface that requires to change the hardware
bridge mode then that would require a PF reset and rebuild of the
switch hierarchy.

Also update the copyright year.

Change-ID: I4d78fc1c83158efda29ba7be92239b74f75d6d25
Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
Tested-By: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      51616018
  47. 24 2月, 2015 1 次提交
  49. 09 2月, 2015 1 次提交
    • M
      i40e: add locking around VF reset · 3ba9bcb4
      由 Mitch Williams 提交于 
      During VF deallocation, we need to lock out the VF reset code. However,
we cannot depend on simply masking the interrupt, as this does not lock
out the service task, which can still call the reset routine. Instead,
leave the interrupt enabled, but add locking around the VF disable and
reset routines.

For the disable code, we wait to get the lock, as the reset code will
take a finite amount of time to run. For the reset code, we just return
if we fail to get the lock. Since we know that the VFs are being
disabled, we don't need to handle the reset.
This fixes a panic when disabling SR-IOV.

Change-ID: Iea0a6cdef35c331f48c6d5b2f8e6f0e86322e7d8
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3ba9bcb4