When removing VFs, the driver takes a weird approach of assigning
pf->num_alloc_vfs to 0 before iterating over the VFs using a temporary
variable.
This logic has been in the driver for a long time, and seems to have
been carried forward from i40e.
We want to refactor the way VFs are stored, and iterating over the data
structure without the ice_for_each_vf interface impedes this work.
The logic relies on implicitly using the num_alloc_vfs as a sort of
"safe guard" for accessing VF data.
While this sort of guard makes sense for Single Root IOV where all VFs
are added at once, the data structures don't work for VFs which can be
added and removed dynamically. We also have a separate state flag,
ICE_VF_DEINIT_IN_PROGRESS which is a stronger protection against
concurrent removal and access.
Avoid the custom tmp iteration and replace it with the standard
ice_for_each_vf iterator. Delay the assignment of num_alloc_vfs until
after this loop finishes.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
{
struct device *dev = ice_pf_to_dev(pf);
struct ice_hw *hw = &pf->hw;
- unsigned int tmp, i;
+ unsigned int i;
if (!pf->vf)
return;
else
dev_warn(dev, "VFs are assigned - not disabling SR-IOV\n");
- tmp = pf->num_alloc_vfs;
- pf->num_qps_per_vf = 0;
- pf->num_alloc_vfs = 0;
- for (i = 0; i < tmp; i++) {
+ ice_for_each_vf(pf, i) {
struct ice_vf *vf = &pf->vf[i];
mutex_lock(&vf->cfg_lock);
if (ice_sriov_free_msix_res(pf))
dev_err(dev, "Failed to free MSIX resources used by SR-IOV\n");
+ pf->num_qps_per_vf = 0;
+ pf->num_alloc_vfs = 0;
devm_kfree(dev, pf->vf);
pf->vf = NULL;