summaryrefslogtreecommitdiff
path: root/drivers/net/can/grcan.c
diff options
context:
space:
mode:
authorJacob Keller <jacob.e.keller@intel.com>2016-06-08 02:08:51 +0300
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2016-07-21 01:22:12 +0300
commit94877768cfaa99f7b3757f29632faa5945f18872 (patch)
tree37e9aa4651febb2ff39f9a5b2487d195edfc459a /drivers/net/can/grcan.c
parent106ca42356b49a1ae6199e6630ec40df82ff7421 (diff)
downloadlinux-94877768cfaa99f7b3757f29632faa5945f18872.tar.xz
fm10k: wait for queues to drain if stop_hw() fails once
It turns out that sometimes during a reset the Tx queues will be temporarily stuck longer than .stop_hw() expects. Work around this issue by attempting to .stop_hw() first. If it tails, wait a number of attempts until the Tx queues appear to be drained. After this, attempt stop_hw() again. This ensures that we avoid waiting if we don't need to, such as during the first initialization of a VF, and give the proper amount of time necessary to recover from most situations. It is possible that the hardware is actually stuck. For PFs, this is usually fixed by a datapath reset. Unfortunately the VF cannot request a similar reset for itself. 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/can/grcan.c')
0 files changed, 0 insertions, 0 deletions