1. 14 4月, 2012 1 次提交
  2. 12 4月, 2012 4 次提交
  3. 11 4月, 2012 4 次提交
  4. 10 4月, 2012 2 次提交
  5. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      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 device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  6. 14 3月, 2012 1 次提交
  7. 13 3月, 2012 1 次提交
  8. 09 3月, 2012 1 次提交
  9. 06 3月, 2012 1 次提交
  10. 05 3月, 2012 1 次提交
    • P
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker 提交于
      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: NPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  11. 01 3月, 2012 1 次提交
  12. 07 2月, 2012 2 次提交
    • E
      mac80211: support hw scan while idle · 885bd8ec
      Eliad Peller 提交于
      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: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      885bd8ec
    • J
      mac80211: add sta_state callback · f09603a2
      Johannes Berg 提交于
      (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: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f09603a2
  13. 31 1月, 2012 1 次提交
  14. 28 1月, 2012 2 次提交
  15. 20 12月, 2011 1 次提交
  16. 02 12月, 2011 1 次提交
  17. 22 11月, 2011 1 次提交
  18. 12 11月, 2011 1 次提交
  19. 10 11月, 2011 2 次提交
  20. 09 11月, 2011 1 次提交
  21. 05 11月, 2011 1 次提交
  22. 15 10月, 2011 1 次提交
  23. 12 10月, 2011 2 次提交
  24. 04 10月, 2011 2 次提交
  25. 01 10月, 2011 4 次提交
    • J
      mac80211: document client powersave · 4b801bc9
      Johannes Berg 提交于
      With the addition of uAPSD and driver buffering
      the powersave handling has gotten quite complex.
      Add a section to the documentation to explain it
      for anyone wanting to implement it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b801bc9
    • J
      mac80211: allow out-of-band EOSP notification · 37fbd908
      Johannes Berg 提交于
      iwlwifi has a separate EOSP notification from
      the device, and to make use of that properly
      it needs to be passed to mac80211. To be able
      to mix with tx_status_irqsafe and rx_irqsafe
      it also needs to be an "_irqsafe" version in
      the sense that it goes through the tasklet,
      the actual flag clearing would be IRQ-safe
      but doing it directly would cause reordering
      issues.
      
      This is needed in the case of a P2P GO going
      into an absence period without transmitting
      any frames that should be driver-released as
      in this case there's no other way to inform
      mac80211 that the service period ended. Note
      that for drivers that don't use the _irqsafe
      functions another version of this function
      will be required.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37fbd908
    • J
      mac80211: explicitly notify drivers of frame release · 40b96408
      Johannes Berg 提交于
      iwlwifi needs to know the number of frames that are
      going to be sent to a station while it is asleep so
      it can properly handle the uCode blocking of that
      station.
      
      Before uAPSD, we got by by telling the device that
      a single frame was going to be released whenever we
      encountered IEEE80211_TX_CTL_POLL_RESPONSE. With
      uAPSD, however, that is no longer possible since
      there could be more than a single frame.
      
      To support this model, add a new callback to notify
      drivers when frames are going to be released.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b96408
    • J
      mac80211: reply only once to each PS-poll · deeaee19
      Johannes Berg 提交于
      If a PS-poll frame is retried (but was received)
      there is no way to detect that since it has no
      sequence number. As a consequence, the standard
      asks us to not react to PS-poll frames until the
      response to one made it out (was ACKed or lost).
      
      Implement this by using the WLAN_STA_SP flags to
      also indicate a PS-Poll "service period" and the
      IEEE80211_TX_STATUS_EOSP flag for the response
      packet to indicate the end of the "SP" as usual.
      
      We could use separate flags, but that will most
      likely completely confuse drivers, and while the
      standard doesn't exclude simultaneously polling
      using uAPSD and PS-Poll, doing that seems quite
      problematic.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      deeaee19