1. 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
  2. 28 9月, 2011 2 次提交
  3. 22 9月, 2011 3 次提交
  4. 20 9月, 2011 1 次提交
  5. 15 9月, 2011 1 次提交
  6. 30 8月, 2011 18 次提交
  7. 09 8月, 2011 1 次提交
  8. 21 7月, 2011 3 次提交
  9. 16 7月, 2011 3 次提交
  10. 12 7月, 2011 5 次提交
  11. 08 7月, 2011 1 次提交
    • J
      mac80211: fix TKIP races, make API easier to use · 523b02ea
      Johannes Berg 提交于
      Our current TKIP code races against itself on TX
      since we can process multiple packets at the same
      time on different ACs, but they all share the TX
      context for TKIP. This can lead to bad IVs etc.
      
      Also, the crypto offload helper code just obtains
      the P1K/P2K from the cache, and can update it as
      well, but there's no guarantee that packets are
      really processed in order.
      
      To fix these issues, first introduce a spinlock
      that will protect the IV16/IV32 values in the TX
      context. This first step makes sure that we don't
      assign the same IV multiple times or get confused
      in other ways.
      
      Secondly, change the way the P1K cache works. I
      add a field "p1k_iv32" that stores the value of
      the IV32 when the P1K was last recomputed, and
      if different from the last time, then a new P1K
      is recomputed. This can cause the P1K computation
      to flip back and forth if packets are processed
      out of order. All this also happens under the new
      spinlock.
      
      Finally, because there are argument differences,
      split up the ieee80211_get_tkip_key() API into
      ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
      and give them the correct arguments.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      523b02ea
  12. 01 7月, 2011 1 次提交