- 16 Sep, 2010 21 commits
-
-
Luis R. Rodriguez authored
ath9k has a race on putting the chip into network sleep and having registers read from hardware. The race occurs because although ath9k_ps_restore() locks its own callers it makes use of some variables which get altered in the driver at different code paths. The variables are the ps_enabled and ps_flags. This is easily reprodicible in large network environments when roaming with the wpa_supplicant simple bgscan. You'd get some 0xdeadbeef read out on certain registers such as: ath: timeout (100000 us) on reg 0x806c: 0xdeadbeef & 0x01f00000 != 0x00000000 ath: RX failed to go idle in 10 ms RXSM=0xdeadbeef ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef & 0x00000003 != 0x00000000 ath: Chip reset failed The fix is to protect the ath9k_config(hw, IEEE80211_CONF_CHANGE_PS) calls with a spin_lock_irqsave() which will disable contendors for these variables from interrupt context, timers, re-entry from mac80211 on the same callback, and most importantly from ath9k_ps_restore() which is the only call which will put the device into network sleep. There are quite a few threads and bug reports on these a few of them are: https://bugs.launchpad.net/ubuntu/karmic/+source/linux/+bug/407040 http://code.google.com/p/chromium-os/issues/detail?id=5709 http://code.google.com/p/chromium-os/issues/detail?id=5943 Stable fixes apply to [2.6.32+] Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
To optimize register read/write operations, the HTC firmwares were patched to change EP3 and EP4 pipe types from Interrupt to Bulk. So register writes are submitted as bulk urbs, but register reads are not. Also changing the register read endpoint pipe as bulk type when URBs are filled improves the register reads considerably which results in reduced scan time and CPU utilization. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
-
Johannes Berg authored
When a driver advertises p2p device support, mac80211 will handle it, but internally it will rewrite the interface type to STA/AP rather than P2P-STA/GO since otherwise a lot of paths need to be touched that are otherwise identical. A p2p boolean tells drivers whether or not a given interface will be used for p2p or not. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
This adds P2P-STA and P2P-GO as device types so we can distinguish between those and normal STA or AP (respectively) type interfaces. Signed-off-by:
-
Rajkumar Manoharan authored
This patch fixes following warning drivers/net/wireless/ath/ath9k/eeprom_def.c: In function 'ath9k_hw_def_get_num_ant_config' drivers/net/wireless/ath/ath9k/eeprom_def.c:1425:47: warning: comparison between 'enum ath9k_hal_freq_band' and 'enum ieee80211_band' Signed-off-by:
-
John W. Linville authored
CHECK drivers/net/wireless/libertas/cfg.c drivers/net/wireless/libertas/cfg.c:493:19: warning: cast to restricted __le16 CHECK drivers/net/wireless/libertas/mesh.c drivers/net/wireless/libertas/mesh.c:577:16: warning: incorrect type in assignment (different base types) drivers/net/wireless/libertas/mesh.c:577:16: expected restricted __le32 [addressable] [assigned] [usertype] id drivers/net/wireless/libertas/mesh.c:577:16: got bool Signed-off-by: -
John W. Linville authored
CHECK drivers/net/wireless/ath/ath9k/recv.c drivers/net/wireless/ath/ath9k/recv.c:1341:6: warning: symbol 'ath_ant_div_conf_fast_divbias' was not declared. Should it be static? Signed-off-by: -
John W. Linville authored
drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: warning: mixing different enum types drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: int enum nl80211_band versus drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: int enum ieee80211_band drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: warning: mixing different enum types drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: int enum ieee80211_band versus drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: int enum nl80211_band drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: warning: mixing different enum types drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: int enum ieee80211_band versus drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: int enum nl80211_band drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: warning: mixing different enum types drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: int enum ieee80211_band versus drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: int enum nl80211_band Signed-off-by: -
Johannes Berg authored
When an interface is brought up, the recent changes to allow changing type-while-up only set the running bit after everything was done. This broke a number of things, including idle calculation for monitor interfaces, and it also broke WDS station insertion (although nobody noticed yet). Thus, change the code to set the running bit earlier, but keep it after the driver's add_interface was called because otherwise drivers may iterate over interfaces they haven't fully set up yet. Reported-by:
-
Johannes Berg authored
Instead of using a WARN_ON(!mutex_is_locked()) use lockdep_assert_held() which compiles away completely when lockdep isn't enabled, and also is a more accurate assertion since it checks that the current thread is holding the mutex. Signed-off-by:
-
Johannes Berg authored
This code is modifying the station flags, and as such should hold the flags lock so it can do so atomically vs. other flags modifications and readers. This issue was introduced when this code was added in eccb8e8f, as it used the wrong lock (thus not fixing the race that was previously documented in a comment.) Cc: stable@kernel.org [2.6.31+] Signed-off-by:
-
Ben Greear authored
Print raw and decoded rxfilter in debufs 'wiphy' file. Also, move variable-length printouts to bottom of file to make bounds checking easier. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Ben Greear authored
When there is more than one VIF, listen for all beacons and ensure ATH9K_RX_FILTER_MCAST_BCAST_ALL is set. Signed-off-by:
-
Bruno Randolf authored
Use key management functions which have been moved to ath/key.c and remove ath9k copies of these functions and other now unused definitions. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
-
Bruno Randolf authored
Replace ah_aes_support and ah_combined_mic with common ath_crypt_caps ATH_CRYPT_CAP_CIPHER_AESCCM and ATH_CRYPT_CAP_MIC_COMBINED. Signed-off-by:
-
Bruno Randolf authored
Replace common->splitmic with ATH_CRYPT_CAP_MIC_COMBINED flag. splitmic has to be used when the ATH_CRYPT_CAP_MIC_COMBINED capability flag is not set. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Bruno Randolf authored
Remove the old ath5k key handling functions, since we now use the key management in ath common. Signed-off-by:
-
Bruno Randolf authored
Use common ath key management functions in ath5k. This fixes problems with HW encryption in AP mode, which was broken in the ath5k implementation. Before (with the ath5k implementation) only one client could connect to the AP using HW encryption and WPA. When a second client connected, the first client was not able to send/receive any more packets. Because of the problems with HW encryption, software encryption was always used in AP mode, which resulted in a high CPU load (and/or low thruput) on embedded devices. Instead of trying to fix the implementation in ath5k it makes more sense to share the code with ath9k. This also enables HW encryption for AP mode again. Signed-off-by:
-
Bruno Randolf authored
Copied the key cache management functions from ath9k (common.c and hw.c) to ath/key.c so we can use them from ath5k, later. Minor changes have been made: - renamed ath9k_* to ath_* - replaced ah->caps.keycache_size with common->keymax - removed ATH9K_IS_MIC_ENABLED since it is always true. - the AR_PCU_MIC_NEW_LOC_ENA flag is replaced with (splitmic == 0). Signed-off-by:
-
Bruno Randolf authored
This will be used later in this patch series. Signed-off-by:
-
Joe Perches authored
The output becomes: [ 41.261941] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
- 14 Sep, 2010 19 commits
-
-
John W. Linville authored
These were introduced in "wl1271: sdio: claim host only when doing IO" drivers/net/wireless/wl12xx/wl1271_sdio.c: In function ‘wl1271_sdio_set_power’: drivers/net/wireless/wl12xx/wl1271_sdio.c:193: warning: ‘return’ with a value, in function returning void drivers/net/wireless/wl12xx/wl1271_sdio.c:195: warning: ‘return’ with a value, in function returning void drivers/net/wireless/wl12xx/wl1271_sdio.c:186: warning: unused variable ‘func’ Signed-off-by: -
Johannes Berg authored
sta_info_get_bss() is used to match STA pointers for VLAN/AP interfaces, but if the same station is also added to multiple other interfaces it will erroneously match because both pointers are NULL, fix this by ignoring NULL pointers here. Reported-by:
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
If AR_KeyMiss is set in the rx descriptor and AR_RxFrameOK is unset, the hardware could not locate a valid key during a decryption attempt. In this case, the frame must not be reported as decrypted, otherwise mac80211 sees only random garbage. Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
At the time the .add_interface driver op is called, the interface has not been marked as running yet, so ieee80211_iterate_active_interfaces will not pass it to the iterator function. Because of this, the calculated BSSID mask is wrong, which breaks multi-BSS operation. Additionally, the current way of comparing all addresses against each other is pointless, as the hardware only uses the hardware MAC address and the BSSID mask for matching the destination address, so all the address array reallocation is completely unnecessary. This patch simplifies the logic by setting the initial mask bytes to 0xff and removing all bits in the iterator call that don't match the hardware MAC address. It also calls the iterator for the vif that was passed to add_interface() Signed-off-by:
-
Rajkumar Manoharan authored
The CPU consumption during the scan period is high, since the register write go over Interrupt endpoint. On downloading the firmware to the target, the USB descriptors are 'patched' to change the type of the endpoints from Interrupt to Bulk. With this fix, the CPU usage during a scan run comes down to acceptable levels. Signed-off-by:
-
Rajkumar Manoharan authored
ath9k_wmi_ctrl_rx is racy with ath9k_wmi_tasklet on event notification due to which the wmi_skb may be overwritten which leads to memory leak. Signed-off-by:
-
Stanislaw Gruszka authored
Even is someone else complete scanning in mac80211, apply rxon and tx power settings if gets scan complete notification from hardware. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Wey-Yi W Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
Replace IWL_DEBUG_{INFO,HC,RC} to IWL_DEBUG_SCAN in iwl-scan.c file. Add some more IWL_DEBUG_SCAN messages. This will allow to fully debug scanning using only IWL_DL_SCAN flag. Also start one message sentence with capital letter, since that convention in iwl-scan.c file. Signed-off-by: -
Stanislaw Gruszka authored
Remove redundant checks and use iwl_is_ready_rf(). Signed-off-by:
-
Stanislaw Gruszka authored
This is needed to avoid warning in ieee80211_restart_hw about hardware scan in progress. Signed-off-by:
-
Stanislaw Gruszka authored
Currently we force scan complete at the end of iwl_scan_cancel_timeout function. This cause race condition when we can get a new scan request from mac80211 and complete it by iwl_bg_complete from older scan. Change code to force scan complete only when really needed: device goes down, interface is removed or scan timeout occurs. Signed-off-by:
-
Stanislaw Gruszka authored
Assure we complete scan in mac80211 when we abort scanning (scan_abort work) or scan timeout occurs (scan_check work). Currently iwl_scan_cancel_timeout() procedure force scan finish in mac80211 at the end of timeout loop, so we can use it in proper work functions. Signed-off-by:
-
Stanislaw Gruszka authored
If we do not get notification from hardware about scan complete, after timeout do mac80211 scan completion anyway. This assure we end scan in case of firmware hung. Patch fix one of the causes of wdev_cleanup_work warning reported at https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by:
-
Stanislaw Gruszka authored
Assure (partially) we call ieee80211_scan_completed() only once when scan was requested from mac80211. Code path that first clear STATUS_SCANNING bit is responsible to call ieee80211_scan_completed(). Before the call, we check if mac80211 really request the scan. Still persist some cases when we behave wrong, that will be addressed in the next patches. Signed-off-by:
-
Stanislaw Gruszka authored
Since on timeout version of iwl_scan_cancel procedure we can sleep, do not have to schedule abort_scan work to begin and perform scanning, can do this directly. Also now, as we do not queue abort_scan from restart work anymore, we can queue abort_scan to priv->workqueue. Don't drop mutex when waiting for scan complete. Use STATUS_HW_SCAN bit to check if scanning is currently pending, because STATUS_SCANNING will be cleared only with priv->mutex taken. Signed-off-by:
-
Stanislaw Gruszka authored
When we are not able to send abort command to firmware, notify mac80211 that we complete scan, as we will newer do it lately. Check for all possible errors that low level sending command procedure does not check, to assure we catch all failures cases. Patch fix one of the causes of wdev_cleanup_work warning reported at https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by:
-
Stanislaw Gruszka authored
Always cancel scan when stooping device and scan is currently pending, we should newer have scan running after down device. To assure we start scan cancel from restart work we have to schedule abort_scan to different workqueue than priv->workqueue. Patch fix not cancel scanning when restarting firmware, what is one of the causes of wdev_cleanup_work warning (together with permanent network connection lost) reported at https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by:
-
