kernel.git/drivers/net/wireless/ath, branch linux-2.6.34.y

ath5k: fix memory leak when fewer than N_PD_CURVES are in use

2012-05-17T15:20:58Z

commit a0b8de350be458b33248e48b2174d9af8a4c4798 upstream. We would free the proper number of curves, but in the wrong slots, due to a missing level of indirection through the pdgain_idx table. It's simpler just to try to free all four slots, so do that. Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath: add missing regdomain pair 0x5c mapping

2012-03-14T14:57:21Z

commit bd39a274fb7b43374c797bafdb7f506598f36f77 upstream. Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Reported-by: Joe Culler Acked-by: Luis R. Rodriguez Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath9k: fix a chip wakeup related crash in ath9k_start

2012-03-14T14:56:59Z

commit f62d816fc4324afbb7cf90110c70b6a14139b225 upstream. When the chip is still asleep when ath9k_start is called, ath9k_hw_configpcipowersave can trigger a data bus error. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath9k_hw: Fix incorrect macversion and macrev checks

2011-06-26T16:47:04Z

commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream. There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Signed-off-by: Senthil Balasubramanian Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath9k: Fix bug in delimiter padding computation

2011-06-26T16:46:23Z

commit 39ec2997c374b528cdbf65099b6d6b8593a67f7f upstream. There is a roundng error in delimiter padding computation which causes severe throughput drop with some of AR9003. signed-off-by: Felix Fietkau Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath9k_hw: fix antenna diversity on AR9285

2011-04-17T20:15:32Z

commit 601e0cb165e65dc185b31fe7ebd2c0169ea47306 upstream. On AR9285, the antenna switch configuration register uses more than just 16 bits. Because of an arbitrary mask applied to the EEPROM value that stores this configuration, diversity was broken in some cases, leading to a significant degradation in signal strength. Fix this by changing the callback to return a 32 bit value and remove the arbitrary mask. [PG: drop ar9003_eeprom.c change; v2.6.34 doesn't have it yet] Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath9k: fix retry count for A-MPDU rate control status reports

2011-04-17T20:15:32Z

commit 78c4653a2274479547e259e1f416d2b3d04c42a8 upstream. The 'bf_retries' field of the ath_buf structure was used for both software retries (AMPDU subframes) and hardware retries (legacy frames). This led to a wrong retry count being reported for the A-MPDU rate control stats. This patch changes the code to no longer use bf_retries for reporting retry counts, but instead always using the real on-chip retry count from the ath_tx_status. Additionally, if the first subframe of an A-MPDU was not acked, the tx status report is submitted along with the first acked subframe, which may not contain the correct rates in the tx info. This is easily corrected by saving the tx rate info before looping over subframes, and then copying it back once the A-MPDU status report is submitted. In my tests this change improves throughput visibly. [PG: 34 doesnt have ts as an alias for ds->ds_txstat, so change accordingly] Signed-off-by: Felix Fietkau Reported-by: Björn Smedman Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath5k: check return value of ieee80211_get_tx_rate

2011-01-06T23:07:48Z

commit d8e1ba76d619dbc0be8fbeee4e6c683b5c812d3a upstream. This avoids a NULL pointer dereference as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=625889 When the WARN condition is hit in ieee80211_get_tx_rate, it will return NULL. So, we need to check the return value and avoid dereferencing it in that case. Signed-off-by: John W. Linville Acked-by: Bob Copeland Signed-off-by: Paul Gortmaker

ath9k_hw: fix parsing of HT40 5 GHz CTLs

2011-01-06T23:07:41Z

commit 904879748d7439a6dabdc6be9aad983e216b027d upstream. The 5 GHz CTL indexes were not being read for all hardware devices due to the masking out through the CTL_MODE_M mask being one bit too short. Without this the calibrated regulatory maximum values were not being picked up when devices operate on 5 GHz in HT40 mode. The final output power used for Atheros devices is the minimum between the calibrated CTL values and what CRDA provides. Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker

ath5k: drop warning on jumbo frames

2011-01-06T23:07:33Z

commit 9637e516d16a58b13f6098cfe899e22963132be3 upstream. Jumbo frames are not supported, and if they are seen it is likely a bogus frame so just silently discard them instead of warning on them all time. Also, instead of dropping them immediately though move the check *after* we check for all sort of frame errors. This should enable us to discard these frames if the hardware picks other bogus items first. Lets see if we still get those jumbo counters increasing still with this. Jumbo frames would happen if we tell hardware we can support a small 802.11 chunks of DMA'd frame, hardware would split RX'd frames into parts and we'd have to reconstruct them in software. This is done with USB due to the bulk size but with ath5k we already provide a good limit to hardware and this should not be happening. This is reported quite often and if it fills the logs then this needs to be addressed and to avoid spurious reports. Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Paul Gortmaker