aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/intel/fm10k/fm10k_main.c
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2016-06-07 16:08:48 -0700
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2016-07-20 15:22:11 -0700
commit892c9e0872bea23ac2dc774ea950e6526f157bd5 (patch)
tree8020021c4047d6c09c9f19c06fc77ced8d30e310 /drivers/net/ethernet/intel/fm10k/fm10k_main.c
parentfm10k: don't stop reset due to FM10K_ERR_REQUESTS_PENDING (diff)
downloadlinux-dev-892c9e0872bea23ac2dc774ea950e6526f157bd5.tar.xz
linux-dev-892c9e0872bea23ac2dc774ea950e6526f157bd5.zip
fm10k: perform data path reset even when switch is not ready
A while ago, an additional check for the switch being ready was added to reset_hw. A recent refactor accidentally made this check return an error code on failure which caused fm10k_probe to fail when the switch wasn't brought up first. The original reasoning for the check was to prevent additional data path reset when the fabric wasn't ready yet. However, there isn't a compelling reason to keep the check, as the data path reset will restore hardware to a known good state. Remove the check and perform the data path reset regardless of the switch manager state. An alternative fix is to return FM10K_SUCCESS instead, and bypass the actual data path reset. This should be fine as we will perform a reset_hw once the switch is active. However, since data path reset will reset many parts of the hardware it seems better to just perform the reset regardless of switch state. 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>
Diffstat (limited to 'drivers/net/ethernet/intel/fm10k/fm10k_main.c')
0 files changed, 0 insertions, 0 deletions