kernel/linux.git/drivers/net/wireless/ath, branch v3.4.52

ath9k: Use minstrel rate control by default

2013-06-20T18:58:44+00:00

commit 5efac94999ff218e0101f67a059e44abb4b0b523 upstream. The ath9k rate control algorithm has various architectural issues that make it a poor fit in scenarios like congested environments etc. An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191 Change the default to minstrel which is more robust in such cases. The ath9k RC code is left in the driver for now, maybe it can be removed altogether later on. Signed-off-by: Sujith Manoharan Cc: Jouni Malinen Cc: Linus Torvalds Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: Disable PowerSave by default

2013-06-20T18:58:44+00:00

commit 531671cb17af07281e6f28c1425f754346e65c41 upstream. Almost all the DMA issues which have plagued ath9k (in station mode) for years are related to PS. Disabling PS usually "fixes" the user's connection stablility. Reports of DMA problems are still trickling in and are sitting in the kernel bugzilla. Until the PS code in ath9k is given a thorough review, disbale it by default. The slight increase in chip power consumption is a small price to pay for improved link stability. Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: fix key allocation error handling for powersave keys

2013-05-19T17:54:40+00:00

commit 4ef69d0394cba8caa9f75d3f2e53429bfb8b3045 upstream. If no keycache slots are available, ath_key_config can return -ENOSPC. If the key index is not checked for errors, it can lead to logspam that looks like this: "ath: wiphy0: keyreset: keycache entry 228 out of range" This can cause follow-up errors if the invalid keycache index gets used for tx. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_hw: change AR9580 initvals to fix a stability issue

2013-04-26T04:19:55+00:00

commit f09a878511997c25a76bf111a32f6b8345a701a5 upstream. The hardware parsing of Control Wrapper Frames needs to be disabled, as it has been causing spurious decryption error reports. The initvals for other chips have been updated to disable it, but AR9580 was left out for some reason. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_htc: accept 1.x firmware newer than 1.3

2013-04-26T04:19:55+00:00

commit 319e7bd96aca64a478f3aad40711c928405b8b77 upstream. Since the firmware has been open sourced, the minor version has been bumped to 1.4 and the API/ABI will stay compatible across further 1.x releases. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_hw: revert chainmask to user configuration after calibration

2013-04-05T17:04:16+00:00

commit 74632d11a133b5baf6b9d622dd19d2f944d93d94 upstream. The commit 'ath9k_hw: fix calibration issues on chainmask that don't include chain 0' changed the hardware chainmask to the chip chainmask for the duration of the calibration, but the revert to user configuration in the reset path runs too early. That causes some issues with limiting the number of antennas (including spurious failure in hardware-generated packets). Fix this by reverting the chainmask after the essential parts of the calibration that need the workaround, and before NF calibration is run. Signed-off-by: Felix Fietkau Reported-by: Wojciech Dubowik Tested-by: Wojciech Dubowik Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_hw: improve reset reliability after errors

2013-03-14T18:29:43+00:00

commit 3412f2f086ea7531378fabe756bd4a1109994ae6 upstream. On many different chips, important aspects of the MAC state are not fully cleared by a warm reset. This can show up as tx/rx hangs, those annoying "DMA failed to stop in 10 ms..." messages or other quirks. On AR933x, the chip can occasionally get stuck in a way that only a driver unload/reload or a reboot would bring it back to life. With this patch, a full reset is issued when bringing the chip out of FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down properly. This makes the DMA related error messages disappear completely in my tests on AR933x, and the chip does not get stuck anymore. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: fix RSSI dummy marker value

2013-03-14T18:29:43+00:00

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 Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix calibration issues on chainmask that don't include chain 0

2013-03-03T22:06:43+00:00

commit 4a8f199508d79ff8a7d1e22f47b912baaf225336 upstream. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: CAI Qian Reviewed-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: fix double-free bug on beacon generate failure

2013-02-04T00:24:41+00:00

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->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 Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman