<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net/wireless/ath, branch v3.0.70</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/net/wireless/ath?h=v3.0.70</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/net/wireless/ath?h=v3.0.70'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-03-14T18:32:05Z</updated>
<entry>
<title>ath9k: fix RSSI dummy marker value</title>
<updated>2013-03-14T18:32:05Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-02-22T20:09:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b77a7b64bd40be69cf9e4476640349f9ad98fb88'/>
<id>urn:sha1:b77a7b64bd40be69cf9e4476640349f9ad98fb88</id>
<content type='text'>
commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream.

RSSI is being stored internally as s8 in several places. The indication
of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
set to 127, but ended up being set to 0x127 because of a code cleanup
mistake. This could lead to invalid signal strength values in a few
places.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: fix double-free bug on beacon generate failure</title>
<updated>2013-02-04T00:21:37Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-01-09T15:16:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bed37001b6919a386dab95dc42084d755233ea60'/>
<id>urn:sha1:bed37001b6919a386dab95dc42084d755233ea60</id>
<content type='text'>
commit 1adb2e2b5f85023d17eb4f95386a57029df27c88 upstream.

When the next beacon is sent, the ath_buf from the previous run is reused.
If getting a new beacon from mac80211 fails, bf-&gt;bf_mpdu is not reset, yet
the skb is freed, leading to a double-free on the next beacon tx attempt,
resulting in a system crash.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k_htc: Fix memory leak</title>
<updated>2013-02-04T00:21:37Z</updated>
<author>
<name>Sujith Manoharan</name>
<email>c_manoha@qca.qualcomm.com</email>
</author>
<published>2013-01-09T10:37:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a2e1c3918e77ad6a13b43cb04e3cfe19f55d8cd0'/>
<id>urn:sha1:a2e1c3918e77ad6a13b43cb04e3cfe19f55d8cd0</id>
<content type='text'>
commit 0981c3b24ef664f5611008a6e6d0622fac6d892b upstream.

SKBs that are allocated in the HTC layer do not have callbacks
registered and hence ended up not being freed, Fix this by freeing
them properly in the TX completion routine.

Reported-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: ar9003: fix OTP register offsets for AR9340</title>
<updated>2013-01-17T16:43:53Z</updated>
<author>
<name>Gabor Juhos</name>
<email>juhosg@openwrt.org</email>
</author>
<published>2012-12-09T22:57:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=46bea30a01949caf8143be4a88038cbe1003b10e'/>
<id>urn:sha1:46bea30a01949caf8143be4a88038cbe1003b10e</id>
<content type='text'>
commit b3cd8021379306c0be6932e4d3b4b01efc681769 upstream.

Trying to access the OTP memory on the AR9340
causes a data bus error like this:

  Data bus error, epc == 86e84164, ra == 86e84164
  Oops[#1]:
  Cpu 0
  $ 0   : 00000000 00000061 deadc0de 00000000
  $ 4   : b8115f18 00015f18 00000007 00000004
  $ 8   : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
  $12   : 7c7c3c7c 001f0041 00000000 7c7c7c3c
  $16   : 86ee0000 00015f18 00000000 00000007
  $20   : 00000004 00000064 00000004 86d71c44
  $24   : 00000000 86e6ca00
  $28   : 86d70000 86d71b20 86ece0c0 86e84164
  Hi    : 00000000
  Lo    : 00000064
  epc   : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw]
      Tainted: G           O
  ra    : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw]
  Status: 1100d403    KERNEL EXL IE
  Cause : 4080801c
  PrId  : 0001974c (MIPS 74Kc)
  Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc
  mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids
  crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr
  aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio
  Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440)
  Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88
          86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20
          000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938
          fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000
          99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000
          ...
  Call Trace:
  [&lt;86e84164&gt;] ath9k_hw_wait+0x58/0xb0 [ath9k_hw]
  [&lt;86e9fcd0&gt;] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw]

  Code: 0000a812  0040f809  00000000 &lt;00531024&gt; 1054000b  24020001  0c05b5dc  2404000a  26520001

The cause of the error is that the OTP register
offsets are different on the AR9340 than the
actually used values.

Signed-off-by: Gabor Juhos &lt;juhosg@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "ath9k_hw: Update AR9003 high_power tx gain table"</title>
<updated>2013-01-17T16:43:53Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-12-06T17:40:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ae172f61ff5d599fe56d2eec814e8310fda7cd43'/>
<id>urn:sha1:ae172f61ff5d599fe56d2eec814e8310fda7cd43</id>
<content type='text'>
commit 9c170e068636deb3e3f96114034bb711675f0faa upstream.

This reverts commit f74b9d365ddd33a375802b064f96a5d0e99af7c0.

Turns out reverting commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd
"ath9k_hw: Updated AR9003 tx gain table for 5GHz" was not enough to
bring the tx power back to normal levels on devices like the
Buffalo WZR-HP-G450H, this one needs to be reverted as well.

This revert improves tx power by ~10 db on that device

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: fix stale pointers potentially causing access to free'd skbs</title>
<updated>2012-11-17T21:14:20Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-10-25T22:31:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a699cd395b19aa262fbffcbe79aec1c57238e489'/>
<id>urn:sha1:a699cd395b19aa262fbffcbe79aec1c57238e489</id>
<content type='text'>
commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.

bf-&gt;bf_next is only while buffers are chained as part of an A-MPDU
in the tx queue. When a tid queue is flushed (e.g. on tearing down
an aggregation session), frames can be enqueued again as normal
transmission, without bf_next being cleared. This can lead to the
old pointer being dereferenced again later.

This patch might fix crashes and "Failed to stop TX DMA!" messages.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: fix decrypt_error initialization in ath_rx_tasklet()</title>
<updated>2012-09-14T17:00:39Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo.bianconi83@gmail.com</email>
</author>
<published>2012-08-10T09:00:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c227ece753e0c8a31f0618e8edb4897d77f8fb0d'/>
<id>urn:sha1:c227ece753e0c8a31f0618e8edb4897d77f8fb0d</id>
<content type='text'>
commit e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 upstream.

ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
in a loop over the received frames. The decrypt_error flag is
initialized to false
just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
ath9k_rx_skb_preprocess(),
only sets decrypt_error to true and never to false.
Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
decrypt_error to it.
So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
have a leftover value
from another processed frame. In that case, the frame will not be marked with
RX_FLAG_DECRYPTED even if it is decrypted correctly.
When using CCMP encryption this issue can lead to connection stuck
because of CCMP
PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
deciphered frame with ieee80211_aes_ccm_decrypt.
Fix the issue initializing decrypt_error flag at the begging of the
ath_rx_tasklet() loop.

Signed-off-by: Lorenzo Bianconi &lt;lorenzo.bianconi83@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: enable serialize_regmode for non-PCIE AR9287</title>
<updated>2012-07-16T15:47:39Z</updated>
<author>
<name>Panayiotis Karabassis</name>
<email>panayk@gmail.com</email>
</author>
<published>2012-06-26T20:37:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5fe4d12cfbf9ca994640a487439a2ef2f633336c'/>
<id>urn:sha1:5fe4d12cfbf9ca994640a487439a2ef2f633336c</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc</title>
<updated>2012-07-16T15:47:39Z</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-06-18T07:43:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3a3ca923be330c3a8b0f391d8e92040f4987eb21'/>
<id>urn:sha1:3a3ca923be330c3a8b0f391d8e92040f4987eb21</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: Fix softlockup in AR9485</title>
<updated>2012-07-16T15:47:38Z</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-06-13T15:58:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=de39eed0da6d7afcf2d758dc0e99811988a3bd06'/>
<id>urn:sha1:de39eed0da6d7afcf2d758dc0e99811988a3bd06</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
