1. 10 Jan, 2011 1 commit
  2. 05 Jan, 2011 1 commit
  3. 22 Dec, 2010 2 commits
  4. 20 Dec, 2010 1 commit
  5. 15 Dec, 2010 1 commit
  6. 30 Nov, 2010 1 commit
  7. 24 Nov, 2010 2 commits
  8. 17 Nov, 2010 1 commit
  9. 16 Nov, 2010 4 commits
  10. 13 Oct, 2010 1 commit
  11. 06 Oct, 2010 1 commit
  12. 05 Oct, 2010 1 commit
  13. 27 Sep, 2010 2 commits
    • Johannes Berg's avatar
      mac80211: move packet flags into packet · 554891e6
      Johannes Berg authored
      commit 8c0c709e
      Author: Johannes Berg <johannes@sipsolutions.net>
      Date:   Wed Nov 25 17:46:15 2009 +0100
      
          mac80211: move cmntr flag out of rx flags
      
      moved the CMNTR flag into the skb RX flags for
      some aggregation cleanups, but this was wrong
      since the optimisation this flag tried to make
      requires that it is kept across the processing
      of multiple interfaces -- which isn't true for
      flags in the skb. The patch not only broke the
      optimisation, it also introduced a bug: under
      some (common!) circumstances the flag will be
      set on an already freed skb!
      
      However, investigating this in more detail, I
      found that most of the flags that we set should
      be per packet, _except_ for this one, due to
      a-MPDU processing. Additionally, the flags used
      for processing (currently just this one) need
      to be reset before processing a new packet.
      
      Since we haven't actually seen bugs reported as
      a result of the wrong flags handling (which is
      not too surprising -- the only real bug case I
      can come up with is an a-MSDU contained in an
      a-MPDU), I'll make a different fix for rc.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      554891e6
    • Ben Greear's avatar
      mac80211/ath9k: Support AMPDU with multiple VIFs. · 686b9cb9
      Ben Greear authored
      The old ieee80211_find_sta_by_hw method didn't properly
      find VIFS when there was more than one per AP.  This caused
      AMPDU logic in ath9k to get the wrong VIF when trying to
      account for transmitted SKBs.
      
      This patch changes ieee80211_find_sta_by_hw to take a
      localaddr argument to distinguish between VIFs with the
      same AP but different local addresses.  The method name
      is changed to ieee80211_find_sta_by_ifaddr.
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      686b9cb9
  14. 24 Sep, 2010 1 commit
  15. 16 Sep, 2010 1 commit
  16. 14 Sep, 2010 1 commit
  17. 27 Aug, 2010 2 commits
  18. 25 Aug, 2010 1 commit
  19. 24 Aug, 2010 1 commit
  20. 16 Aug, 2010 4 commits
  21. 29 Jul, 2010 1 commit
  22. 28 Jul, 2010 1 commit
  23. 21 Jul, 2010 1 commit
  24. 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
      send.
      
      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>
      4ced3f74
  25. 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>
      f90754c1
  26. 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>
      ff616381
  27. 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 #85
      [   92.030507] -------------------------------------------------------
      [   92.030507] modprobe/5225 is trying to acquire lock:
      [   92.030507]  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
      ueue+0x0/0xb0
      [   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>
      68542962
    • 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>
      85ad181e
    • 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>
      5d22c89b
  28. 08 Jun, 2010 1 commit