1. 03 Jun, 2010 1 commit
  2. 02 Jun, 2010 1 commit
  3. 07 May, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
  4. 03 May, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: improve IBSS scanning · be4a4b6a
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      be4a4b6a
  5. 27 Apr, 2010 1 commit
  6. 08 Apr, 2010 1 commit
  7. 06 Apr, 2010 2 commits
  8. 03 Apr, 2010 1 commit
    • Jiri Pirko's avatar
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko authored
      
      
      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: default avatarJiri Pirko <jpirko@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22bedad3
  9. 26 Feb, 2010 1 commit
  10. 12 Jan, 2010 2 commits
  11. 05 Jan, 2010 1 commit
  12. 28 Dec, 2009 4 commits
  13. 22 Dec, 2009 2 commits
  14. 21 Dec, 2009 2 commits
  15. 14 Dec, 2009 1 commit
  16. 29 Nov, 2009 1 commit
  17. 19 Nov, 2009 2 commits
  18. 18 Nov, 2009 3 commits
  19. 06 Nov, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: async station powersave handling · af818581
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      af818581
  20. 04 Nov, 2009 1 commit
  21. 30 Oct, 2009 1 commit
    • Johannes Berg's avatar
      cfg80211/mac80211: use debugfs_remove_recursive · 7bcfaf2f
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7bcfaf2f
  22. 28 Aug, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: remove tasklet enable/disable · ea77f12f
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ea77f12f
  23. 20 Aug, 2009 4 commits
  24. 14 Aug, 2009 1 commit
  25. 04 Aug, 2009 3 commits
    • Igor Perminov's avatar
      mac80211: FIF_PSPOLL filter flag · e3b90ca2
      Igor Perminov authored
      
      
      When an interface is configured in the AP mode, the mac80211
      implementation doesn't inform the driver to receive PS Poll frames.
      It leads to inability to communicate with power-saving stations
      reliably.
      The FIF_CONTROL flag isn't passed by mac80211 to
      ieee80211_ops.configure_filter when an interface is in the AP mode.
      And it's ok, because we don't want to receive ACK frames and other
      control ones, but only PS Poll ones.
      
      This patch introduces the FIF_PSPOLL filter flag in addition to
      FIF_CONTROL, which means for the driver "pass PS Poll frames".
      
      This flag is passed to the driver:
      A) When an interface is configured in the AP mode.
      B) In all cases, when the FIF_CONTROL flag was passed earlier (in
      addition to it).
      Signed-off-by: default avatarIgor Perminov <igor.perminov@inbox.ru>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e3b90ca2
    • Luis R. Rodriguez's avatar
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      Luis R. Rodriguez authored
      
      
      The mac80211 workqueue exists to enable mac80211 and drivers
      to queue their own work on a single threaded workqueue. mac80211
      takes care to flush the workqueue during suspend but we never
      really had requirements on drivers for how they should use
      the workqueue in consideration for suspend.
      
      We extend mac80211 to document how the mac80211 workqueue should
      be used, how it should not be used and finally move raw access to
      the workqueue to mac80211 only. Drivers and mac80211 use helpers
      to queue work onto the mac80211 workqueue:
      
        * ieee80211_queue_work()
        * ieee80211_queue_delayed_work()
      
      These helpers will now warn if mac80211 already completed its
      suspend cycle and someone is trying to queue work. mac80211
      flushes the mac80211 workqueue prior to suspend a few times,
      but we haven't taken the care to ensure drivers won't add more
      work after suspend. To help with this we add a warning when
      someone tries to add work and mac80211 already completed the
      suspend cycle.
      
      Drivers should ensure they cancel any work or delayed work
      in the mac80211 stop() callback.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      42935eca
    • Bob Copeland's avatar
      mac80211: disable beacons before removing the associated interface · 97af7432
      Bob Copeland authored
      
      
      When downing interfaces, it's a good idea to tell the driver to
      stop sending beacons; that way the driver doesn't need special
      code in ops->remove_interface() when it should already handle the
      case in bss_info_changed().
      
      This fixes a potential crash with at least ath5k since the vif
      pointer will be nullified while beacon interrupts are still active.
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      97af7432