When a VF issues an LPORT_STATE request to enable a port which is
already enabled, the PF will first disable the VF. Then it is supposed
to re-enable the VF again with new settings. This is primarily done in
order to ensure that the switch management software properly clears the
previous VF settings. (ie: switch flow rules and so forth). However,
there is a bug in the flow because we check if VF is enabled and don't
re-enable it at the end. The issue is that we disable the VF in order to
clear switch rules, and never follow-up with a re-enable. This results in
a call to enable the VF results in disabling the logical port.
Signed-off-by: Wang Xiao W <xiao.w.wang at intel.com>
---
drivers/net/fm10k/base/fm10k_pf.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/fm10k/base/fm10k_pf.c
b/drivers/net/fm10k/base/fm10k_pf.c
index 86283fa..aa04937 100644
--- a/drivers/net/fm10k/base/fm10k_pf.c
+++ b/drivers/net/fm10k/base/fm10k_pf.c
@@ -1418,6 +1418,14 @@ s32 fm10k_iov_msg_lport_state_pf(struct fm10k_hw *hw,
u32 **results,
err = fm10k_update_lport_state_pf(hw, vf_info->glort,
1, false);
+ /* need to clear VF_FLAG_ENABLED in order to ensure that we
+ * actually re-enable the lport state below. Note that this
+ * has no impact if VF is already disabled, as the flags are
+ * already zeroed.
+ */
+ if (!err)
+ vf_info->vf_flags = FM10K_VF_FLAG_CAPABLE(vf_info);
+
/* when enabling the port we should reset the rate limiters */
hw->iov.ops.configure_tc(hw, vf_info->vf_idx, vf_info->rate);
--
1.9.3
