1. 21 Jun, 2012 1 commit
  2. 06 Jun, 2012 2 commits
    • Johannes Berg's avatar
      mac80211: unify SW/offload remain-on-channel · 2eb278e0
      Johannes Berg authored
      
      
      Redesign all the off-channel code, getting rid of
      the generic off-channel work concept, replacing
      it with a simple remain-on-channel list.
      
      This fixes a number of small issues with the ROC
      implementation:
       * offloaded remain-on-channel couldn't be queued,
         now we can queue it as well, if needed
       * in iwlwifi (the only user) offloaded ROC is
         mutually exclusive with scanning, use the new
         queue to handle that case -- I expect that it
         will later depend on a HW flag
      
      The bigger issue though is that there's a bad bug
      in the current implementation: if we get a mgmt
      TX request while HW roc is active, and this new
      request has a wait time, we actually schedule a
      software ROC instead since we can't guarantee the
      existing offloaded ROC will still be that long.
      To fix this, the queuing mechanism was needed.
      
      The queuing mechanism for offloaded ROC isn't yet
      optimal, ideally we should add API to have the HW
      extend the ROC if needed. We could add that later
      but for now use a software implementation.
      
      Overall, this unifies the behaviour between the
      offloaded and software-implemented case as much
      as possible.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2eb278e0
    • Johannes Berg's avatar
      mac80211: do remain-on-channel while idle · 196ac1c1
      Johannes Berg authored
      
      
      The IDLE handling in HW off-channel is broken right
      now since we turn off IDLE only when the off-channel
      period already started. Therefore, all drivers that
      use it today (only iwlwifi!) must support off-channel
      while idle, so playing with idle isn't needed at all.
      
      Off-channel in general, since it's no longer used for
      authentication/association, shouldn't affect PS, so
      also remove that logic.
      
      Also document a small caveat for reporting TX status
      from off-channel frames in HW remain-on-channel.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      196ac1c1
  3. 05 Jun, 2012 4 commits
  4. 16 May, 2012 2 commits
  5. 08 May, 2012 1 commit
  6. 23 Apr, 2012 1 commit
  7. 16 Apr, 2012 1 commit
  8. 13 Apr, 2012 1 commit
  9. 11 Apr, 2012 4 commits
    • Johannes Berg's avatar
      cfg80211/mac80211: enable proper device_set_wakeup_enable handling · 6d52563f
      Johannes Berg authored
      
      
      In WoWLAN, we only get the triggers when we actually get
      to suspend. As a consequence, drivers currently don't
      know that the device should enable wakeup. However, the
      device_set_wakeup_enable() API is intended to be called
      when the wakeup is enabled, not later when needed.
      
      Add a new set_wakeup() call to cfg80211 and mac80211 to
      allow drivers to properly call device_set_wakeup_enable.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6d52563f
    • Johannes Berg's avatar
      mac80211: add improved HW queue control · 3a25a8c8
      Johannes Berg authored
      
      
      mac80211 currently only supports one hardware queue
      per AC. This is already problematic for off-channel
      uses since if we go off channel while the BE queue
      is full and then try to send an off-channel frame
      the frame will never go out. This will become worse
      when we support multi-channel since then a queue on
      one channel might be full, but we have to stop the
      software queue for all channels. That is obviously
      not desirable.
      
      To address this problem allow drivers to register
      more hardware queues, and allow them to map them to
      virtual interfaces. When they stop a hardware queue
      the corresponding AC software queues on the correct
      interfaces will be stopped as well. Additionally,
      there's an off-channel queue to solve that problem
      and a per-interface after-DTIM beacon queue. This
      allows drivers to manage software queues closer to
      how the hardware works.
      
      Currently, there's a limit of 16 hardware queues.
      This may or may not be sufficient, we can adjust it
      as needed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3a25a8c8
    • Johannes Berg's avatar
      mac80211: add explicit monitor interface if needed · 4b6f1dd6
      Johannes Berg authored
      
      
      The queue mapping redesign that I'm planning to do
      will break pure injection unless we handle monitor
      interfaces explicitly. One possible option would
      be to have the driver tell mac80211 about monitor
      mode queues etc., but that would duplicate the API
      since we already need to have queue assignments
      handled per virtual interface.
      
      So in order to solve this, have a virtual monitor
      interface that is added whenever all active vifs
      are monitors. We could also use the state of one
      of the monitor interfaces, but managing that would
      be complicated, so allocate separate state.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4b6f1dd6
    • Ashok Nagarajan's avatar
      mac80211: Indicate basic rates when adding rate IEs · 657c3e0c
      Ashok Nagarajan authored
      
      
      Basic rates are added with supported rates IE and extended supported
      rates IE.
      Signed-off-by: default avatarAshok Nagarajan <ashok@cozybit.com>
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      657c3e0c
  10. 10 Apr, 2012 4 commits
  11. 09 Apr, 2012 2 commits
  12. 16 Mar, 2012 1 commit
    • Paul Gortmaker's avatar
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker authored
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in de...
      313162d0
  13. 13 Mar, 2012 1 commit
  14. 12 Mar, 2012 1 commit
  15. 08 Mar, 2012 1 commit
  16. 05 Mar, 2012 1 commit
  17. 04 Mar, 2012 1 commit
    • Paul Gortmaker's avatar
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker authored
      
      
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  18. 29 Feb, 2012 1 commit
  19. 06 Feb, 2012 2 commits
    • Eliad Peller's avatar
      mac80211: support hw scan while idle · 885bd8ec
      Eliad Peller authored
      
      
      Currently, mac80211 goes to idle-off before starting a scan.
      However, some devices that implement hw scan might not
      need going idle-off in order to perform a hw scan, and
      thus saving some energy and simplifying their state machine.
      
      (Note that this is also the case for sched scan - it
      currently doesn't make mac80211 go idle-off)
      
      Add a new flag to indicate support for hw scan while idle.
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      885bd8ec
    • Johannes Berg's avatar
      mac80211: add sta_state callback · f09603a2
      Johannes Berg authored
      
      
      (based on Eliad's patch)
      
      Add a callback to notify the low-level driver whenever
      the state of a station changes. The driver is only
      notified when the station is actually in the mac80211
      hash table, not for pre-insert state transitions.
      
      To allow the driver to replace sta_add/remove calls
      with this, call extra transitions with the NOTEXIST
      state.
      
      This callback can fail, so we need to be careful in
      handling it when a station is inserted, particularly
      in the IBSS case where we still keep the station entry
      around for mac80211 purposes.
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f09603a2
  20. 30 Jan, 2012 1 commit
  21. 27 Jan, 2012 2 commits
  22. 19 Dec, 2011 1 commit
  23. 02 Dec, 2011 1 commit
  24. 21 Nov, 2011 1 commit
  25. 11 Nov, 2011 1 commit
  26. 09 Nov, 2011 1 commit