aboutsummaryrefslogtreecommitdiffstats
path: root/package
diff options
context:
space:
mode:
authorJohn Crispin <john@openwrt.org>2015-02-04 06:09:51 +0000
committerJohn Crispin <john@openwrt.org>2015-02-04 06:09:51 +0000
commitee445d7cb2c0f5d9d59bc320a52e218a60df1265 (patch)
tree8c291b3e99582e3440259d0cf32106390385bbfa /package
parentaf8b5977ad1c0c67cf1387c596bb0530b7d5cd57 (diff)
downloadupstream-ee445d7cb2c0f5d9d59bc320a52e218a60df1265.tar.gz
upstream-ee445d7cb2c0f5d9d59bc320a52e218a60df1265.tar.bz2
upstream-ee445d7cb2c0f5d9d59bc320a52e218a60df1265.zip
ath5k: fix spontaneus AR5312 freezes
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> SVN-Revision: 44252
Diffstat (limited to 'package')
-rw-r--r--package/kernel/mac80211/patches/330-ath5k-fix-spontaneus-AR5312-freezes.patch45
1 files changed, 45 insertions, 0 deletions
diff --git a/package/kernel/mac80211/patches/330-ath5k-fix-spontaneus-AR5312-freezes.patch b/package/kernel/mac80211/patches/330-ath5k-fix-spontaneus-AR5312-freezes.patch
new file mode 100644
index 0000000000..aacadbaf2f
--- /dev/null
+++ b/package/kernel/mac80211/patches/330-ath5k-fix-spontaneus-AR5312-freezes.patch
@@ -0,0 +1,45 @@
+From: Sergey Ryazanov <ryazanov.s.a@gmail.com>
+Date: Tue, 3 Feb 2015 22:37:26 +0300
+Subject: [PATCH] ath5k: fix spontaneus AR5312 freezes
+
+Sometimes while CPU have some load and ath5k doing the wireless
+interface reset the whole WiSoC completely freezes. Set of tests shows
+that using atomic delay function while we wait interface reset helps to
+avoid such freezes.
+
+The easiest way to reproduce this issue: create a station interface,
+start continous scan with wpa_supplicant and load CPU by something. Or
+just create multiple station interfaces and put them all in continous
+scan.
+
+This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
+usleep_range where possible"), which replaces initial udelay()
+by usleep_range().
+
+I do not know actual source of this issue, but all looks like that HW
+freeze is caused by transaction on internal SoC bus, while wireless
+block is in reset state.
+
+Also I should note that I do not know how many chips are affected, but I
+did not see this issue with chips, other than AR5312.
+
+CC: Jiri Slaby <jirislaby@gmail.com>
+CC: Nick Kossifidis <mickflemm@gmail.com>
+CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
+Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
+Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
+Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
+Tested-by: Eric Bree <ebree@nltinc.com>
+Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
+---
+--- a/drivers/net/wireless/ath/ath5k/reset.c
++++ b/drivers/net/wireless/ath/ath5k/reset.c
+@@ -478,7 +478,7 @@ ath5k_hw_wisoc_reset(struct ath5k_hw *ah
+ regval = ioread32(reg);
+ iowrite32(regval | val, reg);
+ regval = ioread32(reg);
+- usleep_range(100, 150);
++ udelay(100); /* NB: should be atomic */
+
+ /* Bring BB/MAC out of reset */
+ iowrite32(regval & ~val, reg);