fm10k: don't loop while resetting VFs due to VFLR event
authorJacob Keller <jacob.e.keller@intel.com>
Mon, 10 Jul 2017 20:23:10 +0000 (13:23 -0700)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Mon, 2 Oct 2017 15:06:30 +0000 (08:06 -0700)
commitd876c1583bb1b7f7264880265b824e88b791aa5d
tree4f71ccdb5b967c51f4ebf573d3d377ba913ac739
parent4abf01b43b62525e4f1a20dd1a2bc4a1967d8928
fm10k: don't loop while resetting VFs due to VFLR event

We've always had a really weird looping construction for resetting VFs.
We read the VFLRE register and reset the VF if the corresponding bit is
set, which makes sense. However we loop continuously until we no longer
have any bits left unset. At first this makes sense, as a sort of "keep
trying until we succeed" concept.

Unfortunately this causes a problem if we happen to surprise remove
while this code is executing, because in this case we'll always read all
1s for the VFLRE register. This results in a hard lockup on the CPU
because the loop will never terminate.

Because our own reset function will clear the VFLR event register
always, (except when we've lost PCIe link obviously) there is no real
reason to loop. In practice, we'll loop over once and find that no VFs
are pending anymore.

Lets just check once. Since we're clear the notification when we reset
there's no benefit to the loop. Additionally, there shouldn't be a race
as future VLFRE events should trigger an interrupt. Additionally, we
didn't warn or do anything in the looped case anyways.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/fm10k/fm10k_iov.c