<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless, branch v3.2.23</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mwifiex: fix wrong return values in add_virtual_intf() error cases</title>
<updated>2012-07-12T03:32:09+00:00</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2012-07-04T03:43:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=83744791d4f628e83a6aa8fd2d3d694daa547204'/>
<id>83744791d4f628e83a6aa8fd2d3d694daa547204</id>
<content type='text'>
commit 858faa57dd9e2b91f3f870fbb1185982e42f5a2b upstream

backported for linux-3.2.y, linux-3.3.y, linux-3.4.y

add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
on errors, otherwise cfg80211 will crash.

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 858faa57dd9e2b91f3f870fbb1185982e42f5a2b upstream

backported for linux-3.2.y, linux-3.3.y, linux-3.4.y

add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
on errors, otherwise cfg80211 will crash.

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: enable serialize_regmode for non-PCIE AR9287</title>
<updated>2012-07-12T03:32:02+00:00</updated>
<author>
<name>Panayiotis Karabassis</name>
<email>panayk@gmail.com</email>
</author>
<published>2012-06-26T20:37:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8055d02bb133e222610f3eb494a4641f95683c8c'/>
<id>8055d02bb133e222610f3eb494a4641f95683c8c</id>
<content type='text'>
commit 7508b657967cf664b5aa0f6367d05016e7e3bc2a upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=42903

Based on the work of &lt;fynivx@gmail.com&gt;

Signed-off-by: Panayiotis Karabassis &lt;panayk@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7508b657967cf664b5aa0f6367d05016e7e3bc2a upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=42903

Based on the work of &lt;fynivx@gmail.com&gt;

Signed-off-by: Panayiotis Karabassis &lt;panayk@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtlwifi: rtl8192cu: New USB IDs</title>
<updated>2012-07-12T03:32:02+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2012-06-25T23:01:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9eec182c06a3d48667526d080b5ee3481f762302'/>
<id>9eec182c06a3d48667526d080b5ee3481f762302</id>
<content type='text'>
commit f63d7dabd5da9ef41f28f6d69b29bc084db0ca5a upstream.

The latest Realtek driver for the RTL8188CU and RTL8192CU chips adds three
new USB IDs.

Reported-by: Xose Vazquez Perez &lt;xose.vazquez@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f63d7dabd5da9ef41f28f6d69b29bc084db0ca5a upstream.

The latest Realtek driver for the RTL8188CU and RTL8192CU chips adds three
new USB IDs.

Reported-by: Xose Vazquez Perez &lt;xose.vazquez@gmail.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix dynamic WEP related regression</title>
<updated>2012-07-12T03:32:01+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-06-23T17:23:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e087c0136ef1d53213a5cbdc4187c15a88f55996'/>
<id>e087c0136ef1d53213a5cbdc4187c15a88f55996</id>
<content type='text'>
commit bed3d9c0b71f9afbfec905cb6db3b9f16be29d4d upstream.

commit 7a532fe7131216a02c81a6c1b1f8632da1195a58
ath9k_hw: fix interpretation of the rx KeyMiss flag

This commit used the rx key miss indication to detect packets that were
passed from the hardware without being decrypted, however it seems that
this bit is not only undefined in the static WEP case, but also for
dynamically allocated WEP keys. This caused a regression when using
WEP-LEAP.

This patch fixes the regression by keeping track of which key indexes
refer to CCMP keys and only using the key miss indication for those.

Reported-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bed3d9c0b71f9afbfec905cb6db3b9f16be29d4d upstream.

commit 7a532fe7131216a02c81a6c1b1f8632da1195a58
ath9k_hw: fix interpretation of the rx KeyMiss flag

This commit used the rx key miss indication to detect packets that were
passed from the hardware without being decrypted, however it seems that
this bit is not only undefined in the static WEP case, but also for
dynamically allocated WEP keys. This caused a regression when using
WEP-LEAP.

This patch fixes the regression by keeping track of which key indexes
refer to CCMP keys and only using the key miss indication for those.

Reported-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: fix WPS eapol handshake failure</title>
<updated>2012-07-12T03:32:00+00:00</updated>
<author>
<name>Stone Piao</name>
<email>piaoyun@marvell.com</email>
</author>
<published>2012-06-21T03:21:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a49edd1239c7940218aad7366d0dbd5a61bae556'/>
<id>a49edd1239c7940218aad7366d0dbd5a61bae556</id>
<content type='text'>
commit f03ba7e9a24e5e9efaad56bd1713b994ea556b16 upstream.

After association, STA will go through eapol handshake with WPS
enabled AP. It's observed that WPS handshake fails with some 11n
AP. The reason for the failure is that the eapol packet is sent
via 11n frame aggregation.

The eapol packet should be sent directly without 11n aggregation.

This patch fixes the problem by adding WPS session control while
dequeuing Tx packets for transmission.

Signed-off-by: Stone Piao &lt;piaoyun@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: reformat the if-statement per earlier
 upstream commit c65a30f35f938b421ac67c34a9e70b0e49e6019a]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f03ba7e9a24e5e9efaad56bd1713b994ea556b16 upstream.

After association, STA will go through eapol handshake with WPS
enabled AP. It's observed that WPS handshake fails with some 11n
AP. The reason for the failure is that the eapol packet is sent
via 11n frame aggregation.

The eapol packet should be sent directly without 11n aggregation.

This patch fixes the problem by adding WPS session control while
dequeuing Tx packets for transmission.

Signed-off-by: Stone Piao &lt;piaoyun@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: reformat the if-statement per earlier
 upstream commit c65a30f35f938b421ac67c34a9e70b0e49e6019a]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mwifiex: fix 11n rx packet drop issue</title>
<updated>2012-07-12T03:32:00+00:00</updated>
<author>
<name>Stone Piao</name>
<email>piaoyun@marvell.com</email>
</author>
<published>2012-06-21T03:21:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b6d20c196b397562cb9ebee6291c8010aeece78'/>
<id>7b6d20c196b397562cb9ebee6291c8010aeece78</id>
<content type='text'>
commit 925839243dc9aa4ef25305f5afd10ed18258a4ac upstream.

Currently we check the sequence number of last packet received
against start_win. If a sequence hole is detected, start_win is
updated to next sequence number.

Since the rx sequence number is initialized to 0, a corner case
exists when BA setup happens immediately after association. As
0 is a valid sequence number, start_win gets increased to 1
incorrectly. This causes the first packet with sequence number 0
being dropped.

Initialize rx sequence number as 0xffff and skip adjusting
start_win if the sequence number remains 0xffff. The sequence
number will be updated once the first packet is received.

Signed-off-by: Stone Piao &lt;piaoyun@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Kiran Divekar &lt;dkiran@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 925839243dc9aa4ef25305f5afd10ed18258a4ac upstream.

Currently we check the sequence number of last packet received
against start_win. If a sequence hole is detected, start_win is
updated to next sequence number.

Since the rx sequence number is initialized to 0, a corner case
exists when BA setup happens immediately after association. As
0 is a valid sequence number, start_win gets increased to 1
incorrectly. This causes the first packet with sequence number 0
being dropped.

Initialize rx sequence number as 0xffff and skip adjusting
start_win if the sequence number remains 0xffff. The sequence
number will be updated once the first packet is received.

Signed-off-by: Stone Piao &lt;piaoyun@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Kiran Divekar &lt;dkiran@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: remove log_event debugfs file debugging is disabled</title>
<updated>2012-07-04T04:44:23+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-06-20T06:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=468267529e13b35307410c8e7bd09bc41d063c79'/>
<id>468267529e13b35307410c8e7bd09bc41d063c79</id>
<content type='text'>
commit 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream.

When debugging is disabled, the event log functions aren't
functional in the way that the debugfs file expects. This
leads to the debugfs access crashing. Since the event log
functions aren't functional then, remove the debugfs file
when CONFIG_IWLWIFI_DEBUG is not set.

Reported-by: Lekensteyn &lt;lekensteyn@gmail.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream.

When debugging is disabled, the event log functions aren't
functional in the way that the debugfs file expects. This
leads to the debugfs access crashing. Since the event log
functions aren't functional then, remove the debugfs file
when CONFIG_IWLWIFI_DEBUG is not set.

Reported-by: Lekensteyn &lt;lekensteyn@gmail.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc</title>
<updated>2012-07-04T04:44:23+00:00</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-06-18T07:43:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8ec8fdb5e62e6a7ff9956217b32dae6bc46328ec'/>
<id>8ec8fdb5e62e6a7ff9956217b32dae6bc46328ec</id>
<content type='text'>
commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream.

"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintainers.
http://www.spinics.net/lists/linux-wireless/msg92126.html.
Based on my testing PLL's locking measurement is done in
~200us (2 iterations).

Cc: Rolf Offermanns &lt;rolf.offermanns@gmx.net&gt;
Cc: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Cc: Senthil Balasubramanian &lt;senthilb@qca.qualcomm.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream.

"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintainers.
http://www.spinics.net/lists/linux-wireless/msg92126.html.
Based on my testing PLL's locking measurement is done in
~200us (2 iterations).

Cc: Rolf Offermanns &lt;rolf.offermanns@gmx.net&gt;
Cc: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Cc: Senthil Balasubramanian &lt;senthilb@qca.qualcomm.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix a tx rate duration calculation bug</title>
<updated>2012-07-04T04:44:21+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-06-15T01:04:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4c42ad8fcf33fee7b949a6355b71a773843131b9'/>
<id>4c42ad8fcf33fee7b949a6355b71a773843131b9</id>
<content type='text'>
commit 76591bea9714a58d8924154068c78d702eb2cb17 upstream.

The rate pointer variable for a rate series is used in a loop before it is
initialized. This went unnoticed because it was used earlier for the RTS/CTS
rate. This bug can lead to the wrong PHY type being passed to the
duration calculation function.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 76591bea9714a58d8924154068c78d702eb2cb17 upstream.

The rate pointer variable for a rate series is used in a loop before it is
initialized. This went unnoticed because it was used earlier for the RTS/CTS
rate. This bug can lead to the wrong PHY type being passed to the
duration calculation function.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: Fix softlockup in AR9485</title>
<updated>2012-07-04T04:44:19+00:00</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-06-13T15:58:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bc623ac31d51f12113e40085f08fbccf585220bd'/>
<id>bc623ac31d51f12113e40085f08fbccf585220bd</id>
<content type='text'>
commit bcb7ad7bcbef030e6ba71ede1f9866368aca7c99 upstream.

steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

	Call Trace:
	[&lt;ffffffffa0517490&gt;] ? ath_hw_check+0xe0/0xe0 [ath9k]
	[&lt;ffffffff812cd1e8&gt;] __const_udelay+0x28/0x30
	[&lt;ffffffffa03bae7a&gt;] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
	[&lt;ffffffffa05174eb&gt;] ath_hw_pll_work+0x5b/0xe0 [ath9k]
	[&lt;ffffffff810744fe&gt;] process_one_work+0x11e/0x470
	[&lt;ffffffff8107530f&gt;] worker_thread+0x15f/0x360
	[&lt;ffffffff810751b0&gt;] ? manage_workers+0x230/0x230
	[&lt;ffffffff81079af3&gt;] kthread+0x93/0xa0
	[&lt;ffffffff815fd3a4&gt;] kernel_thread_helper+0x4/0x10
	[&lt;ffffffff81079a60&gt;] ? kthread_freezable_should_stop+0x70/0x70
	[&lt;ffffffff815fd3a0&gt;] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142

Reported-by: Rolf Offermanns &lt;rolf.offermanns@gmx.net&gt;
Tested-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bcb7ad7bcbef030e6ba71ede1f9866368aca7c99 upstream.

steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

	Call Trace:
	[&lt;ffffffffa0517490&gt;] ? ath_hw_check+0xe0/0xe0 [ath9k]
	[&lt;ffffffff812cd1e8&gt;] __const_udelay+0x28/0x30
	[&lt;ffffffffa03bae7a&gt;] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
	[&lt;ffffffffa05174eb&gt;] ath_hw_pll_work+0x5b/0xe0 [ath9k]
	[&lt;ffffffff810744fe&gt;] process_one_work+0x11e/0x470
	[&lt;ffffffff8107530f&gt;] worker_thread+0x15f/0x360
	[&lt;ffffffff810751b0&gt;] ? manage_workers+0x230/0x230
	[&lt;ffffffff81079af3&gt;] kthread+0x93/0xa0
	[&lt;ffffffff815fd3a4&gt;] kernel_thread_helper+0x4/0x10
	[&lt;ffffffff81079a60&gt;] ? kthread_freezable_should_stop+0x70/0x70
	[&lt;ffffffff815fd3a0&gt;] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142

Reported-by: Rolf Offermanns &lt;rolf.offermanns@gmx.net&gt;
Tested-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
