- 21 Sep, 2010 3 commits
-
-
Ohad Ben-Cohen authored
Add a simple mechanism to pass platform data to the SDIO instances of wl12xx. This way there is no confusion over who owns the 'embedded data', typechecking is preserved, and no possibility for the wrong driver to pick up the data. Originally proposed by Russell King. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ohad Ben-Cohen authored
Make it possible for the set power method to indicate a success/failure return value. This is needed to support more complex power on/off operations such as SDIO power manipulations. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ohad Ben-Cohen authored
Move wl12xx.h outside of the spi-specific location, so it can be shared with both spi and sdio solutions. Update all users of spi/wl12xx.h accordingly Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Acked-by: Luciano Coelho <luciano.coelho@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 17 Sep, 2010 10 commits
-
-
Wey-Yi Guy authored
For config bt command, initialize both tx_prio_boost and rx_prio_boost to "0". Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Adding two new parameters in config bt API. these two parameters use the 3 reserved bytes, so there is no structure size changes. Make sure set both parameters to "zero" in order to preserve previous behavior. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
For failure tx status 0x90 and 0x91, give the correct name to reflect the errors. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Jay Sternberg authored
remove duplicate header and clean up format so it is defined once making changes consolicated ensuring consistancy of output. no function change to date displayed. Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Addition to standard tx frame failure report, adding aggregated frame failure report to debugfs Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
When uCode completed the aggregated frames transmission attempt, it will send tx command response with aggregated frame status. Keep track of the failure counter which help indicate any transmission error condition. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
For aggregated frames with block ack, different status flag will be used as part of tx command response. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Tx command response sent to host by uCode after completed the transmission attempt. The status parameter indicates whether the transmission was successful, or else why if failed. Here we keep the counters to help understand the different failure cases. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
If uCode fail to transmit frame, it will send reply tx back to driver with failure status; keep the counters of each failure cases for debugging. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Include bt_status_read function pointer for 5150 device Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 16 Sep, 2010 27 commits
-
-
Luis R. Rodriguez authored
The patch titled "ath9k: Add new file init.c" shuffled some code around but in dong so for some reason also removed the revision check for disablign power save. Add this revision check again so we can get power save re-enabled again by default on cards newer than AR5416 and AR5418. $ git describe --contains 55624204 v2.6.34-rc1~233^2~49^2~343 This patch has fixes for stable kernels [2.6.34+]. 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>
-
Senthil Balasubramanian authored
The patch: commit 293dc5df Author: Gabor Juhos <juhosg@openwrt.org> Date: Fri Jun 19 12:17:48 2009 +0200 ath9k: remove ath_rx_ps_back_to_sleep helper This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags. Remove it and clear these flags directly in the approptiate places instead. Changes-licensed-under: ISC Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> introduced a regression which forgot to lift the beacon flag after we received all broadcast and multicast data. This meant we never went to sleep consuming about ~650mW on idle. This pretty much broke power save completely. This patch has fixes for stable kernels [2.6.32+]. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Sameer Nanda <snanda@google.com> Cc: Gabor Juhos <juhosg@openwrt.org> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Some buggy APs do not respond to unicast probe requests or send unicast probe requests very delayed so in the worst case we should try to send broadcast probe requests, otherwise we can get disconnected from these APs. Even if drivers do not have filters to disregard probe responses from foreign APs mac80211 will only process probe responses from our associated AP for re-arming connection monitoring. We need to do this since the beacon monitor does not push back the connection monitor by design so even if we are getting beacons from these type of APs our connection monitor currently relies heavily on the way the probe requests are received on the AP. An example of an AP affected by this is the Nexus One, but this has also been observed with random APs. We can probably optimize this later by using null funcs instead of probe requests. For more details refer to: http://code.google.com/p/chromium-os/issues/detail?id=5715 This patch has fixes for stable kernels [2.6.35+]. 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>
-
Luis R. Rodriguez authored
The beacon monitor should be disabled when going off channel to prevent spurious warnings and triggering connection deterioration work such as sending probe requests. Re-enable the beacon monitor once we come back to the home channel. This patch has fixes for stable kernels [2.6.34+]. 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>
-
Luis R. Rodriguez authored
This will be used by other components next. The beacon monitor was added as of 2.6.34 so these fixes are applicable only to kernels >= 2.6.34. 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>
-
Luis R. Rodriguez authored
When we go offchannel mac80211 currently leaves alive the connection idle monitor. This should be instead postponed until we come back to our home channel, otherwise by the time we get back to the home channel we could be triggering unecesary probe requests. For APs that do not respond to unicast probe requests (Nexus One is a simple example) this means we essentially get disconnected after the probes fails. This patch has stable fixes for kernels [2.6.35+] 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>
-
Luis R. Rodriguez authored
Upon beacon loss we send probe requests after 30 seconds of idle time and we wait for each probe response 1/2 second. We send a total of 3 probe requests before giving up on the AP. In the case that we reset the connection idle monitor we should reset the probe requests count to 0. Right now this won't help in any way but the next patch will. This patch has fixes for stable kernel [2.6.35+]. 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>
-
Luis R. Rodriguez authored
This will be used in another place later. The connection monitor was added as of 2.6.35 so these fixes will be applicable to >= 2.6.35. 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>
-
Luis R. Rodriguez authored
ath9k's entire logic with SC_OP_SCANNING is incorrect due to the way mac80211 currently implements the scan complete callback and we handle it in ath9k. This patch removes the flag completely in preference for the SC_OP_OFFCHANNEL which is really what we wanted. The scanning flag was used to ensure we reset ANI to the old values when we go back to the home channel, but if we are offchannel we use some defaults. The flag was also used to re-enable the TX monitor. Without this patch we simply never re-enabled ANI and the TX monitor after going offchannel. This means that after one background scan we are prone to noise issues and if we had a TX hang we would not recover. To get this to work properly we must enable ANI after we have configured the beacon timers, otherwise hardware acts really oddly. This patch has stable fixes which apply down to [2.6.36+], there *may* be a to fix this on older kernels but requires a bit of work since this patch relies on the new mac80211 flag IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36. 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>
-
Luis R. Rodriguez authored
When we return to the home channel we were never reseting our beacon timers, this was casued by the fact that the scanning flag was still on even after we returned to our home channel. There are also other reasons why we would get a reset and if we are not off channel we always need to resynch our beacon timers, because a reset will clear them. This bug is a regression introduced on 2.6.36. The order of the changes are as follows: 5ee08656 - Sat Jul 31 - ath9k: prevent calibration during off-channel activity a0daa0e7 - Tue Jul 27 - Revert "mac80211: fix sw scan bracketing" 543708be - Fri Jun 18 - mac80211: fix sw scan bracketing mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \ --contains 5ee08656 v2.6.36-rc1~43^2~34^2~22 mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \ --contains a0daa0e7 v2.6.36-rc1~571^2~64^2~13 mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \ --contains 543708be v2.6.36-rc1~571^2~107^2~187 So 5ee08656 would have worked if a0daa0e7 was not committed but it was so this means 5ee08656 was broken since it assumed that when we were in the channel change routine the scan flag would be lifted. As it turns out the scan flag will be set when we are already on the home channel. For more details refer to: http://code.google.com/p/chromium-os/issues/detail?id=5715 These issues will need to be considered for our solution on reshifting the scan complete callback location on mac80211 on current development kernel work. This patch has stable fixes which apply down to [2.6.36+] 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>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <linville@tuxdriver.com>
-
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 <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: John W. Linville <linville@tuxdriver.com>
-
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 <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
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 <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-