1. 05 1月, 2011 1 次提交
  2. 23 12月, 2010 1 次提交
  3. 21 12月, 2010 1 次提交
  4. 16 12月, 2010 1 次提交
  5. 14 12月, 2010 2 次提交
  6. 08 12月, 2010 1 次提交
  7. 07 12月, 2010 1 次提交
    • J
      cfg80211/mac80211: add mesh join/leave commands · 29cbe68c
      Johannes Berg 提交于
      Instead of tying mesh activity to interface up,
      add join and leave commands for mesh. Since we
      must be backward compatible, let cfg80211 handle
      joining a mesh if a mesh ID was pre-configured
      when the device goes up.
      
      Note that this therefore must modify mac80211 as
      well since mac80211 needs to lose the logic to
      start the mesh on interface up.
      
      We now allow querying mesh parameters before the
      mesh is connected, which simply returns defaults.
      Setting them (internally renamed to "update") is
      only allowed while connected. Specify them with
      the new mesh join command instead where needed.
      
      In mac80211, beaconing must now also follow the
      mesh enabled/not enabled state, which is done
      by testing the mesh ID.
      Signed-off-by: NJavier Cardona <javier@cozybit.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      29cbe68c
  8. 28 10月, 2010 1 次提交
  9. 26 10月, 2010 1 次提交
  10. 14 10月, 2010 1 次提交
  11. 07 10月, 2010 1 次提交
  12. 06 10月, 2010 4 次提交
  13. 29 9月, 2010 1 次提交
    • L
      mac80211: fix offchannel assumption upon association · 8d4780eb
      Luis R. Rodriguez 提交于
      Association is dealt with as an atomic offchannel operation,
      we do this because we don't know we are associated until we
      get the associatin response from the AP. When we do get the
      associatin response though we were never clearing the offchannel
      state. This has a few implications, we told drivers we were
      still offchannel, and the first configured TX power for the
      channel does not take into account any power constraints.
      
      For ath9k this meant ANI calibration would not start upon
      association, and we'd have to wait until the first bgscan
      to be triggered. There may be other issues this resolves
      but I'm too lazy to comb the code to check.
      
      Cc: stable@kernel.org
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Cc: Vasanth Thiagarajan <vasanth.thiagarajan@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8d4780eb
  14. 17 9月, 2010 1 次提交
  15. 16 9月, 2010 1 次提交
  16. 15 9月, 2010 1 次提交
  17. 01 9月, 2010 1 次提交
  18. 31 8月, 2010 1 次提交
    • J
      mac80211: delete work timer · 071249b1
      Johannes Berg 提交于
      The new workqueue changes helped me find this bug
      that's been lingering since the changes to the work
      processing in mac80211 -- the work timer is never
      deleted properly. Do that to avoid having it fire
      after all data structures have been freed. It can't
      be re-armed because all it will do, if running, is
      schedule the work, but that gets flushed later and
      won't have anything to do since all work items are
      gone by now (by way of interface removal).
      
      Cc: stable@kernel.org [2.6.34+]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      071249b1
  19. 28 8月, 2010 3 次提交
  20. 26 8月, 2010 3 次提交
  21. 25 8月, 2010 1 次提交
  22. 17 8月, 2010 4 次提交
  23. 05 8月, 2010 1 次提交
  24. 29 7月, 2010 1 次提交
  25. 09 7月, 2010 1 次提交
    • J
      mac80211: remove wep dependency · 3473187d
      John W. Linville 提交于
      The current mac80211 code assumes that WEP is always available.  If WEP
      fails to initialize, ieee80211_register_hw will always fail.
      
      In some cases (e.g. FIPS certification), the cryptography used by WEP is
      unavailable.  However, in such cases there is no good reason why CCMP
      encryption (or even no link level encryption) cannot be used.  So, this
      patch removes mac80211's assumption that WEP (and TKIP) will always be
      available for use.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3473187d
  26. 16 6月, 2010 1 次提交
    • J
      mac80211: Fix ps-qos network latency handling · ff616381
      Juuso Oikarinen 提交于
      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: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ff616381
  27. 15 6月, 2010 3 次提交
    • J
      mac80211: Fix circular locking dependency in ARP filter handling · 68542962
      Juuso Oikarinen 提交于
      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: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      68542962
    • J
      mac80211: refcount aggregation queue stop · a6a67db2
      Johannes Berg 提交于
      mac80211 currently maintains the ampdu_lock to
      avoid starting a queue due to one aggregation
      session while another aggregation session needs
      the queue stopped.
      
      We can do better, however, and instead refcount
      the queue stops for this particular purpose,
      thus removing the need for the lock. This will
      help making ampdu_action able to sleep.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a6a67db2
    • J
      mac80211: move aggregation callback processing · c1475ca9
      Johannes Berg 提交于
      This moves the aggregation callback processing
      to the per-sdata skb queue and a work function
      rather than the tasklet.
      
      Unfortunately, this means that it extends the
      pkt_type hack to that skb queue. However, it
      will enable making ampdu_action API changes
      gradually, my current plan is to get rid of
      this again by forcing drivers to only return
      from ampdu_action() when everything is done,
      thus removing the callbacks completely.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c1475ca9