1. 24 Sep, 2010 1 commit
  2. 16 Sep, 2010 1 commit
  3. 14 Sep, 2010 1 commit
  4. 27 Aug, 2010 2 commits
  5. 25 Aug, 2010 1 commit
  6. 24 Aug, 2010 1 commit
  7. 16 Aug, 2010 4 commits
  8. 29 Jul, 2010 1 commit
  9. 28 Jul, 2010 1 commit
  10. 21 Jul, 2010 1 commit
  11. 20 Jul, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: move QoS-enable to BSS info · 4ced3f74
      Johannes Berg authored
      Ever since
      commit e1b3ec1a
      Author: Stanislaw Gruszka <sgruszka@redhat.com>
      Date:   Mon Mar 29 12:18:34 2010 +0200
          mac80211: explicitly disable/enable QoS
      mac80211 is telling drivers, in particular
      iwlwifi, whether QoS is enabled or not.
      However, this is only relevant for station mode,
      since only then will any device send nullfunc
      frames and need to know whether they should be
      QoS frames or not. In other modes, there are
      (currently) no frames the device is supposed to
      When you now consider virtual interfaces, it
      becomes apparent that the current mechanism is
      inadequate since it enables/disables QoS on a
      global scale, where for nullfunc frames it has
      to be on a per-interface scale.
      Due to the above considerations, we can change
      the way mac80211 advertises the QoS state to
      drivers to only ever advertise it as "off" in
      station mode, and make it a per-BSS setting.
      Tested-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  12. 21 Jun, 2010 1 commit
    • Juuso Oikarinen's avatar
      mac80211: Add interface for driver to temporarily disable dynamic ps · f90754c1
      Juuso Oikarinen authored
      This mechanism introduced in this patch applies (at least) for hardware
      designs using a single shared antenna for both WLAN and BT. In these designs,
      the antenna must be toggled between WLAN and BT.
      In those hardware, managing WLAN co-existence with Bluetooth requires WLAN
      full power save whenever there is Bluetooth activity in order for WLAN to be
      able to periodically relinquish the antenna to be used for BT. This is because
      BT can only access the shared antenna when WLAN is idle or asleep.
      Some hardware, for instance the wl1271, are able to indicate to the host
      whenever there is BT traffic. In essence, the hardware will send an indication
      to the host whenever there is, for example, SCO traffic or A2DP traffic, and
      will send another indication when the traffic is over.
      The hardware gets information of Bluetooth traffic via hardware co-existence
      control lines - these lines are used to negotiate the shared antenna
      ownership. The hardware will give the antenna to BT whenever WLAN is sleeping.
      This patch adds the interface to mac80211 to facilitate temporarily disabling
      of dynamic power save as per request of the WLAN driver. This interface will
      immediately force WLAN to full powersave, hence allowing BT coexistence as
      described above.
      In these kind of shared antenna desings, when WLAN powersave is fully disabled,
      Bluetooth will not work simultaneously with WLAN at all. This patch does not
      address that problem. This interface will not change PSM state, so if PSM is
      disabled it will remain so. Solving this problem requires knowledge about BT
      state, and is best done in user-space.
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  13. 15 Jun, 2010 1 commit
    • Juuso Oikarinen's avatar
      mac80211: Fix ps-qos network latency handling · ff616381
      Juuso Oikarinen authored
      The ps-qos latency handling is broken. It uses predetermined latency values
      to select specific dynamic PS timeouts. With common AP configurations, these
      values overlap with beacon interval and are therefore essentially useless
      (for network latencies less than the beacon interval, PSM is disabled.)
      This patch remedies the problem by replacing the predetermined network latency
      values with one high value (1900ms) which is used to go trigger full psm. For
      backwards compatibility, the value 2000ms is still mapped to a dynamic ps
      timeout of 100ms.
      Currently also the mac80211 internal value for storing user space configured
      dynamic PSM values is incorrectly in the driver visible ieee80211_conf struct.
      Move it to the ieee80211_local struct.
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  14. 14 Jun, 2010 3 commits
    • Juuso Oikarinen's avatar
      mac80211: Fix circular locking dependency in ARP filter handling · 68542962
      Juuso Oikarinen authored
      There is a circular locking dependency when configuring the
      hardware ARP filters on association, occurring when flushing the mac80211
      workqueue. This is what happens:
      [   92.026800] =======================================================
      [   92.030507] [ INFO: possible circular locking dependency detected ]
      [   92.030507] 2.6.34-04781-g2b2c009e
      [   92.030507] -------------------------------------------------------
      [   92.030507] modprobe/5225 is trying to acquire lock:
      [   92.030507]  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
      [   92.030507]
      [   92.030507] but task is already holding lock:
      [   92.030507]  (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]
      [   92.030507] which lock already depends on the new lock.
      [   92.030507]
      [   92.030507]
      [   92.030507] the existing dependency chain (in reverse order) is:
      [   92.030507]
      [   92.030507] -> #2 (rtnl_mutex){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff81341754>] mutex_lock_nested+0x44/0x300
      [   92.030507]        [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]        [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
      [   92.030507]        [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211]
      [   92.030507] -> #1 ((&local->work_work)){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105a51a>] worker_thread+0x22a/0x370
      [   92.030507]        [<ffffffff8105ecc6>] kthread+0x96/0xb0
      [   92.030507]        [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
      [   92.030507]
      [   92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
      [   92.030507]        [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
      [   92.030507]        [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
      [   92.030507]        [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
      The locking in this case is quite complex. Fix the problem by rewriting the
      way the hardware ARP filter list is handled - i.e. make a copy of the address
      list to the bss_conf struct, and provide that list to the hardware driver
      when needed.
      The current patch will enable filtering also in promiscuous mode. This may need
      to be changed in the future.
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: allow drivers to sleep in ampdu_action · 85ad181e
      Johannes Berg authored
      Allow drivers to sleep, and indicate this in
      the documentation. ath9k has some locking I
      don't understand, so keep it safe and disable
      BHs in it, all other drivers look fine with
      the context change.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: remove non-irqsafe aggregation callbacks · 5d22c89b
      Johannes Berg authored
      The non-irqsafe aggregation start/stop done
      callbacks are currently only used by ath9k_htc,
      and can cause callbacks into the driver again.
      This might lead to locking issues, which will
      only get worse as we modify locking. To avoid
      trouble, remove the non-irqsafe versions and
      change ath9k_htc to use those instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  15. 08 Jun, 2010 1 commit
  16. 04 Jun, 2010 1 commit
  17. 03 Jun, 2010 3 commits
  18. 24 May, 2010 3 commits
  19. 12 May, 2010 1 commit
  20. 07 May, 2010 2 commits
  21. 30 Apr, 2010 1 commit
  22. 28 Apr, 2010 1 commit
  23. 27 Apr, 2010 2 commits
  24. 20 Apr, 2010 4 commits
  25. 19 Apr, 2010 1 commit