summaryrefslogtreecommitdiff
path: root/tools
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2015-10-16 10:56:57 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2016-09-15 08:27:39 +0200
commit587e0cfdad34aa76d6bafa9151e4afabadbdbfbd (patch)
tree8453ca05af48cca1ec67d371929ce7c9dc69bc07 /tools
parent031d16e75c5dbc96cdbfcb1ebd5c60d95d33786d (diff)
fm10k: reset max_queues on init_hw_vf failure
[ Upstream commit 0e8d5b5975401c83641efd5d4595e6cdbe9e9e2f ] VF drivers must detect how many queues are available. Previously, the driver assumed that each VF has at minimum 1 queue. This assumption is incorrect, since it is possible that the PF has not yet assigned the queues to the VF by the time the VF checks. To resolve this, we added a check first to ensure that the first queue is infact owned by the VF at init_hw_vf time. However, the code flow did not reset hw->mac.max_queues to 0. In some cases, such as during reinit flows, we call init_hw_vf without clearing the previous value of hw->mac.max_queues. Due to this, when init_hw_vf errors out, if its error code is not properly handled the VF driver may still believe it has queues which no longer belong to it. Fix this by clearing the hw->mac.max_queues on exit due to errors. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@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>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions