carl9170: fix spurious restart due to high latency

RX Stress tests of unidirectional bulk traffic with
bitrates of up to 220Mbit/s have revealed that the
fatal-event recovery logic [which was solely triggered
by an out-of-rx-buffer situation] is too aggressive.

The new method now "pings" the device and then
decides - based on the response - whenever
a restart is needed or not.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

1 files changed, 2 insertions, 1 deletions

diff --git a/drivers/net/wireless/ath/carl9170/carl9170.h b/drivers/net/wireless/ath/carl9170/carl9170.h
index b69d31972c77..d07ff7f2fd92 100644
--- a/drivers/net/wireless/ath/carl9170/carl9170.h
+++ b/drivers/net/wireless/ath/carl9170/carl9170.h
@@ -215,7 +215,7 @@ enum carl9170_restart_reasons {
         CARL9170_RR_TOO_MANY_FIRMWARE_ERRORS,
         CARL9170_RR_WATCHDOG,
         CARL9170_RR_STUCK_TX,
-        CARL9170_RR_SLOW_SYSTEM,
+        CARL9170_RR_UNRESPONSIVE_DEVICE,
         CARL9170_RR_COMMAND_TIMEOUT,
         CARL9170_RR_TOO_MANY_PHY_ERRORS,
         CARL9170_RR_LOST_RSP,
@@ -287,6 +287,7 @@ struct ar9170 {
 
         /* reset / stuck frames/queue detection */
         struct work_struct restart_work;
+        struct work_struct ping_work;
         unsigned int restart_counter;
         unsigned long queue_stop_timeout[__AR9170_NUM_TXQ];
         unsigned long max_queue_stop_timeout[__AR9170_NUM_TXQ];