1. 01 3月, 2012 1 次提交
  2. 22 11月, 2011 1 次提交
  3. 01 11月, 2011 1 次提交
  4. 01 10月, 2011 1 次提交
    • J
      mac80211: implement uAPSD · 47086fc5
      Johannes Berg 提交于
      Add uAPSD support to mac80211. This is probably not
      possible with all devices, so advertising it with
      the cfg80211 flag will be left up to drivers that
      want it.
      
      Due to my previous patches it is now a fairly
      straight-forward extension. Drivers need to have
      accurate TX status reporting for the EOSP frame.
      For drivers that buffer themselves, the provided
      APIs allow releasing the right number of frames,
      but then drivers need to set EOSP and more-data
      themselves. This is documented in more detail in
      the new code itself.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      47086fc5
  5. 30 8月, 2011 1 次提交
  6. 25 8月, 2011 1 次提交
    • C
      p54: improve site survey · 0d78156e
      Christian Lamparter 提交于
      The firmware keeps track of channel usage. This data can
      be used by the automatic channel selection to find the best
      channel.
      
      Survey data from wlan4
      	frequency:				5200 MHz [in use]
      	noise:					-91 dBm
      	channel active time:			811909 ms
      	channel busy time:			63395 ms
      	channel transmit time:			59636 ms
      Survey data from wlan4
      	frequency:				5210 MHz
      	noise:					-91 dBm
      	channel active time:			121 ms
      	channel busy time:			119 ms
      	channel transmit time:			0 ms
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0d78156e
  7. 09 4月, 2011 1 次提交
  8. 26 2月, 2011 1 次提交
    • J
      mac80211: make tx() operation return void · 7bb45683
      Johannes Berg 提交于
      The return value of the tx operation is commonly
      misused by drivers, leading to errors. All drivers
      will drop frames if they fail to TX the frame, and
      they must also properly manage the queues (if they
      didn't, mac80211 would already warn).
      
      Removing the ability for drivers to return a BUSY
      value also allows significant cleanups of the TX
      TX handling code in mac80211.
      
      Note that this also fixes a bug in ath9k_htc, the
      old "return -1" there was wrong.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k]
      Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00]
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi]
      Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bb45683
  9. 24 2月, 2011 1 次提交
  10. 15 2月, 2011 1 次提交
  11. 11 1月, 2011 1 次提交
  12. 31 8月, 2010 1 次提交
  13. 26 8月, 2010 1 次提交
  14. 19 8月, 2010 1 次提交
  15. 17 8月, 2010 1 次提交
  16. 28 7月, 2010 1 次提交
  17. 29 4月, 2010 1 次提交
  18. 01 4月, 2010 1 次提交
  19. 20 2月, 2010 1 次提交
  20. 09 2月, 2010 1 次提交
  21. 29 8月, 2009 1 次提交
    • C
      p54: fix broadcast buffering in AP mode · 90d6f928
      Christian Lamparter 提交于
      The patch "mac80211: fix PS-poll response race" somehow broke
      broadcast buffering in a funny way.
      
      During normal operation - stations are awake - the firmware refused
      to transmit broadcast frames and reported P54_TX_PSM_CANCELLED.
      But everything worked as soon as one station entered PSM.
      
      The reason:
      The stack sets IEEE80211_TX_CTL_SEND_AFTER_DTIM for outgoing
      broadcast frames as soon as a station is marked as sleeping.
      This flag triggers a path which will reroute these frames
      into p54's "content after beacon" queue, which is designed
      to cope with the demands for psm.
      
      This patch restores the old behavior.
      
      IEEE80211_TX_CTL_CLEAR_PS_FILT will once again be used to signalize
      the firmware to ignore the ps canceling for certain frames.
      Signed-off-by: NChristian Lamparter <chunkeey@web.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      90d6f928
  22. 14 8月, 2009 1 次提交
  23. 05 8月, 2009 1 次提交
    • L
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      Luis R. Rodriguez 提交于
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42935eca
  24. 28 7月, 2009 1 次提交
  25. 25 7月, 2009 3 次提交
  26. 11 7月, 2009 2 次提交