summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2017-10-02 07:17:50 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-12-25 14:26:29 +0100
commitfb383223d00ffa445b266c5fd54ed80fd8c57d17 (patch)
treefdcb82f0de849d8369b01c1dad24ae28f7ccb43e
parent2b401d9f1d4543e4e1ad23a46726376adb958831 (diff)
downloadlinux-stable-fb383223d00ffa445b266c5fd54ed80fd8c57d17.tar.gz
linux-stable-fb383223d00ffa445b266c5fd54ed80fd8c57d17.tar.bz2
linux-stable-fb383223d00ffa445b266c5fd54ed80fd8c57d17.zip
fm10k: ensure we process SM mbx when processing VF mbx
[ Upstream commit 17a91809942ca32c70026d2d5ba3348a2c4fdf8f ] When we process VF mailboxes, the driver is likely going to also queue up messages to the switch manager. This process merely queues up the FIFO, but doesn't actually begin the transmission process. Because we hold the mailbox lock during this VF processing, the PF<->SM mailbox is not getting processed at this time. Ensure that we actually process the PF<->SM mailbox in between each PF<->VF mailbox. This should ensure prompt transmission of the messages queued up after each VF message is received and handled. 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> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-rw-r--r--drivers/net/ethernet/intel/fm10k/fm10k_iov.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
index f919199944a0..e72fd52bacfe 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_iov.c
@@ -126,6 +126,9 @@ process_mbx:
struct fm10k_mbx_info *mbx = &vf_info->mbx;
u16 glort = vf_info->glort;
+ /* process the SM mailbox first to drain outgoing messages */
+ hw->mbx.ops.process(hw, &hw->mbx);
+
/* verify port mapping is valid, if not reset port */
if (vf_info->vf_flags && !fm10k_glort_valid_pf(hw, glort))
hw->iov.ops.reset_lport(hw, vf_info);