1. 08 6月, 2010 1 次提交
  2. 05 6月, 2010 1 次提交
  3. 04 6月, 2010 2 次提交
  4. 03 6月, 2010 1 次提交
  5. 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
  6. 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
  7. 28 4月, 2010 1 次提交
  8. 09 4月, 2010 1 次提交
  9. 07 4月, 2010 1 次提交
  10. 06 4月, 2010 1 次提交
  11. 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
  12. 27 2月, 2010 1 次提交
  13. 13 1月, 2010 2 次提交
  14. 06 1月, 2010 1 次提交
  15. 29 12月, 2009 4 次提交
  16. 23 12月, 2009 2 次提交
  17. 22 12月, 2009 2 次提交
  18. 15 12月, 2009 1 次提交
  19. 30 11月, 2009 1 次提交
  20. 20 11月, 2009 2 次提交
  21. 19 11月, 2009 3 次提交
  22. 07 11月, 2009 1 次提交
    • J
      mac80211: async station powersave handling · af818581
      Johannes Berg 提交于
      Some devices require that all frames to a station
      are flushed when that station goes into powersave
      mode before being able to send frames to that
      station again when it wakes up or polls -- all in
      order to avoid reordering and too many or too few
      frames being sent to the station when it polls.
      
      Normally, this is the case unless the station
      goes to sleep and wakes up very quickly again.
      But in that case, frames for it may be pending
      on the hardware queues, and thus races could
      happen in the case of multiple hardware queues
      used for QoS/WMM. Normally this isn't a problem,
      but with the iwlwifi mechanism we need to make
      sure the race doesn't happen.
      
      This makes mac80211 able to cope with the race
      with driver help by a new WLAN_STA_PS_DRIVER
      per-station flag that can be controlled by the
      driver and tells mac80211 whether it can transmit
      frames or not. This flag must be set according to
      very specific rules outlined in the documentation
      for the function that controls it.
      
      When we buffer new frames for the station, we
      normally set the TIM bit right away, but while
      the driver has blocked transmission to that sta
      we need to avoid that as well since we cannot
      respond to the station if it wakes up due to the
      TIM bit. Once the driver unblocks, we can set
      the TIM bit.
      
      Similarly, when the station just wakes up, we
      need to wait until all other frames are flushed
      before we can transmit frames to that station,
      so the same applies here, we need to wait for
      the driver to give the OK.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af818581
  23. 05 11月, 2009 1 次提交
  24. 31 10月, 2009 1 次提交
    • J
      cfg80211/mac80211: use debugfs_remove_recursive · 7bcfaf2f
      Johannes Berg 提交于
      We can save a lot of code and pointers in the structs
      by using debugfs_remove_recursive().
      
      First, change cfg80211 to use debugfs_remove_recursive()
      so that drivers do not need to clean up any files they
      added to the per-wiphy debugfs (if and only if they are
      ok to be accessed until after wiphy_unregister!).
      
      Then also make mac80211 use debugfs_remove_recursive()
      where necessary -- it need not remove per-wiphy files
      as cfg80211 now removes those, but netdev etc. files
      still need to be handled but can now be removed without
      needing struct dentry pointers to all of them.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bcfaf2f
  25. 29 8月, 2009 1 次提交
    • J
      mac80211: remove tasklet enable/disable · ea77f12f
      Johannes Berg 提交于
      Due to the way the tasklets work in mac80211 there's
      no need to ever disable them.
      
      However, we need to clear the pending packets when
      taking down the last interface because otherwise
      the tx_pending_tasklet might be queued if the
      driver mucks with the queues (which it shouldn't).
      
      I've had a situation occasionally with ar9170 in
      which ksoftirq was using 100% CPU time because
      a disabled tasklet was scheduled, and I think that
      was due to ar9170 receiving a packet while the
      tasklet was disabled. That's strange and it really
      should not do that for other reasons, but there's
      no need to waste that much CPU time over it, it
      should just warn instead.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ea77f12f
  26. 20 8月, 2009 4 次提交
  27. 14 8月, 2009 1 次提交