Searched hist:"3 ba9bcb4b68fa63f38bca910ccd4a1bf3cb4195f" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/drivers/net/ethernet/intel/i40e/ |
| H A D | i40e.h | diff 3ba9bcb4b68fa63f38bca910ccd4a1bf3cb4195f Fri Jan 09 05:18:15 CST 2015 Mitch Williams <mitch.a.williams@intel.com> i40e: add locking around VF reset
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: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
| H A D | i40e_virtchnl_pf.c | diff 3ba9bcb4b68fa63f38bca910ccd4a1bf3cb4195f Fri Jan 09 05:18:15 CST 2015 Mitch Williams <mitch.a.williams@intel.com> i40e: add locking around VF reset
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: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|