1. 01 9月, 2010 1 次提交
  2. 28 8月, 2010 3 次提交
  3. 26 8月, 2010 3 次提交
  4. 25 8月, 2010 1 次提交
  5. 17 8月, 2010 4 次提交
  6. 05 8月, 2010 1 次提交
  7. 29 7月, 2010 1 次提交
  8. 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
  9. 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
  10. 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
  11. 08 6月, 2010 1 次提交
  12. 05 6月, 2010 1 次提交
  13. 04 6月, 2010 2 次提交
  14. 03 6月, 2010 1 次提交
  15. 08 5月, 2010 1 次提交
    • J
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg 提交于
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
  16. 04 5月, 2010 1 次提交
    • J
      mac80211: improve IBSS scanning · be4a4b6a
      Johannes Berg 提交于
      When IBSS is fixed to a frequency, it can still
      scan to try to find the right BSSID. This makes
      sense if the BSSID isn't also fixed, but it need
      not scan all channels -- just one is sufficient.
      Make it do that by moving the scan setup code to
      ieee80211_request_internal_scan() and include
      a channel variable setting.
      
      Note that this can be further improved to start
      the IBSS right away if both frequency and BSSID
      are fixed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      be4a4b6a
  17. 28 4月, 2010 1 次提交
  18. 09 4月, 2010 1 次提交
  19. 07 4月, 2010 1 次提交
  20. 06 4月, 2010 1 次提交
  21. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  22. 27 2月, 2010 1 次提交
  23. 13 1月, 2010 2 次提交
  24. 06 1月, 2010 1 次提交
  25. 29 12月, 2009 4 次提交
  26. 23 12月, 2009 1 次提交