1. 21 Sep, 2010 11 commits
  2. 17 Sep, 2010 10 commits
  3. 16 Sep, 2010 19 commits
    • Luis R. Rodriguez's avatar
      ath9k: fix regression which disabled ps on ath9k · 008443de
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      008443de
    • Senthil Balasubramanian's avatar
      ath9k: fix regression which prevents chip sleep after CAB data · 3fac6dfd
      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: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarJohn 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: default avatarSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3fac6dfd
    • Luis R. Rodriguez's avatar
      mac80211: send last 3/5 probe requests as unicast · f01a067d
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f01a067d
    • Luis R. Rodriguez's avatar
      mac80211: disable beacon monitor while going offchannel · 3bc3c0d7
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3bc3c0d7
    • Luis R. Rodriguez's avatar
      mac80211: make the beacon monitor available externally · d3a910a8
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d3a910a8
    • Luis R. Rodriguez's avatar
      mac80211: reset connection idle when going offchannel · 4730d597
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4730d597
    • Luis R. Rodriguez's avatar
      mac80211: reset probe send counter upon connection timer reset · 0c699c3a
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0c699c3a
    • Luis R. Rodriguez's avatar
      mac80211: add helper for reseting the connection monitor · be099e82
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      be099e82
    • Luis R. Rodriguez's avatar
      ath9k: fix enabling ANI / tx monitor after bg scan · 48a6a468
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      48a6a468
    • Luis R. Rodriguez's avatar
      ath9k: fix regression on beacon loss after bgscan · 52b8ac92
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      52b8ac92
    • Luis R. Rodriguez's avatar
      ath9k: fix power save race conditions · 8ab2cd09
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8ab2cd09
    • Rajkumar Manoharan's avatar
      ath9k_htc: Fix register read through bulk pipe · 0f529e98
      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: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0f529e98
    • Johannes Berg's avatar
      mac80211: add p2p device type support · 2ca27bcf
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2ca27bcf
    • Johannes Berg's avatar
      cfg80211/nl80211: introduce p2p device types · 074ac8df
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      074ac8df
    • Rajkumar Manoharan's avatar
      ath9k_hw: remove warning in ath9k_hw_def_get_num_ant_config · f799a301
      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: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f799a301
    • John W. Linville's avatar
      libertas: correct sparse warnings · 65a602dd
      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: default avatarJohn W. Linville <linville@tuxdriver.com>
      65a602dd
    • John W. Linville's avatar
      ath9k: make ath_ant_div_conf_fast_divbias static · 9bad82b8
      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: default avatarJohn W. Linville <linville@tuxdriver.com>
      9bad82b8
    • John W. Linville's avatar
      iwlwifi: fix sparse warning about wrong enum for band parameter · 20c956df
      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: default avatarJohn W. Linville <linville@tuxdriver.com>
      20c956df
    • Johannes Berg's avatar
      mac80211: set running state earlier · 2d2080c3
      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: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2d2080c3