b94177e10f
The radio would stop communicating completely. This issue was easiest to trigger on AR913x devices, e.g. the TP-Link TL-WR1043ND, but other hardware was occasionally affected as well. The most critical issue was a race condition in disabling/enabling IRQs between the IRQ handler and the IRQ processing tasklet Signed-off-by: Felix Fietkau <nbd@nbd.name>
30 lines
898 B
Diff
30 lines
898 B
Diff
From: Felix Fietkau <nbd@nbd.name>
|
|
Date: Wed, 25 Jan 2017 12:58:17 +0100
|
|
Subject: [PATCH] ath9k_hw: check if the chip failed to wake up
|
|
|
|
In an RFC patch, Sven Eckelmann and Simon Wunderlich reported:
|
|
|
|
"QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a
|
|
state in which a read of AR_CFG always returns 0xdeadbeef.
|
|
This should not happen when when the power_mode of the device is
|
|
ATH9K_PM_AWAKE."
|
|
|
|
Include the check for the default register state in the existing MAC
|
|
hang check.
|
|
|
|
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
---
|
|
|
|
--- a/drivers/net/wireless/ath/ath9k/hw.c
|
|
+++ b/drivers/net/wireless/ath/ath9k/hw.c
|
|
@@ -1624,6 +1624,10 @@ bool ath9k_hw_check_alive(struct ath_hw
|
|
int count = 50;
|
|
u32 reg, last_val;
|
|
|
|
+ /* Check if chip failed to wake up */
|
|
+ if (REG_READ(ah, AR_CFG) == 0xdeadbeef)
|
|
+ return false;
|
|
+
|
|
if (AR_SREV_9300(ah))
|
|
return !ath9k_hw_detect_mac_hang(ah);
|
|
|