1. 01 10月, 2011 8 次提交
    • 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
    • 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
    • J
      mac80211: allow releasing driver-buffered frames · 4049e09a
      Johannes Berg 提交于
      If there are frames for a station buffered in
      the driver, mac80211 announces those in the TIM
      IE but there's no way to release them. Add new
      API to release such frames and use it when the
      station polls for a frame.
      
      Since the API will soon also be used for uAPSD
      it is easily extensible.
      
      Note that before this change drivers announcing
      driver-buffered frames in the TIM bit actually
      will respond to a PS-Poll with a potentially
      lower priority frame (if there are any frames
      buffered in mac80211), after this patch a driver
      that hasn't been changed will no longer respond
      at all. This only affects ath9k, which will need
      to be fixed to implement the new API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4049e09a
    • J
      mac80211: split PS buffers into ACs · 948d887d
      Johannes Berg 提交于
      For uAPSD support we'll need to have per-AC PS
      buffers. As this is a major undertaking, split
      the buffers before really adding support for
      uAPSD. This already makes some reference to the
      uapsd_queues variable, but for now that will
      never be non-zero.
      
      Since book-keeping is complicated, also change
      the logic for keeping a maximum of frames only
      and allow 64 frames per AC (up from 128 for a
      station).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      948d887d
    • J
      mac80211: let drivers inform it about per TID buffered frames · 042ec453
      Johannes Berg 提交于
      For uAPSD implementation, it is necessary to know on
      which ACs frames are buffered. mac80211 obviously
      knows about the frames it has buffered itself, but
      with aggregation many drivers buffer frames. Thus,
      mac80211 needs to be informed about this.
      
      For now, since we don't have APSD in any form, this
      will unconditionally set the TIM bit for the station
      but later with uAPSD only some ACs might cause the
      TIM bit to be set.
      
      ath9k is the only driver using this API and I only
      modify it in the most basic way, it won't be able
      to implement uAPSD with this yet. But it can't do
      that anyway since there's no way to selectively
      release frames to the peer yet.
      
      Since drivers will buffer frames per TID, let them
      inform mac80211 on a per TID basis, mac80211 will
      then sort out the AC mapping itself.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      042ec453
    • A
      mac80211: standardize adding supported rates IEs · 768db343
      Arik Nemtsov 提交于
      Relocate the mesh implementation of adding the (extended) supported
      rates IE to util.c, anticipating its use by other parts of mac80211.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Cc: Kalyan C Gaddam <chakkal@iit.edu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      768db343
  2. 28 9月, 2011 2 次提交
  3. 21 9月, 2011 1 次提交
  4. 17 9月, 2011 1 次提交
  5. 15 9月, 2011 2 次提交
  6. 14 9月, 2011 1 次提交
  7. 26 8月, 2011 1 次提交
  8. 09 8月, 2011 2 次提交
  9. 21 7月, 2011 1 次提交
  10. 16 7月, 2011 2 次提交
  11. 14 7月, 2011 1 次提交
    • J
      mac80211: allow driver to disconnect after resume · 95acac61
      Johannes Berg 提交于
      In WoWLAN, devices may use crypto keys for TX/RX
      and could also implement GTK rekeying. If the
      driver isn't able to retrieve replay counters and
      similar information from the device upon resume,
      or if the device isn't responsive due to platform
      issues, it isn't safe to keep the connection up
      as GTK rekey messages from during the sleep time
      could be replayed against it.
      
      The only protection against that is disconnecting
      from the AP. Modifying mac80211 to do that while
      it is resuming would be very complex and invasive
      in the case that the driver requires a reconfig,
      so do it after it has resumed completely. In that
      case, however, packets might be replayed since it
      can then only happen after TX/RX are up again, so
      mark keys for interfaces that need to disconnect
      as "tainted" and drop all packets that are sent
      or received with those keys.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      95acac61
  12. 12 7月, 2011 1 次提交
  13. 08 7月, 2011 3 次提交
    • J
      mac80211: allow driver to generate P1K for IV32 · 42d98795
      Johannes Berg 提交于
      In order to support pre-populating the P1K cache in
      iwlwifi hardware for WoWLAN, we need to calculate
      the P1K for the current IV32. Allow drivers to get
      the P1K for any given IV32 instead of for a given
      packet, but keep the packet-based version around as
      an inline.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42d98795
    • J
      mac80211: allow drivers to access key sequence counter · 3ea542d3
      Johannes Berg 提交于
      In order to implement GTK rekeying, the device needs
      to be able to encrypt frames with the right PN/IV and
      check the PN/IV in RX frames. To be able to tell it
      about all those counters, we need to be able to get
      them from mac80211, this adds the required API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ea542d3
    • 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
  14. 07 7月, 2011 2 次提交
  15. 06 7月, 2011 1 次提交
  16. 30 6月, 2011 1 次提交
  17. 18 6月, 2011 1 次提交
  18. 11 6月, 2011 1 次提交
  19. 08 6月, 2011 1 次提交
    • S
      mac80211: Stop BA session event from device · f41ccd71
      Shahar Levi 提交于
      Some devices support BT/WLAN co-existence algorigthms.
      In order not to harm the system performance and user experience, the device
      requests not to allow any RX BA session and tear down existing RX BA sessions
      based on system constraints such as periodic BT activity that needs to limit
      WLAN activity (eg.SCO or A2DP).
      In such cases, the intention is to limit the duration of the RX PPDU and
      therefore prevent the peer device to use A-MPDU aggregation.
      
      Adding ieee80211_stop_rx_ba_session() callback
      that can be used by the driver to stop existing BA sessions.
      Signed-off-by: NShahar Levi <shahar_levi@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f41ccd71
  20. 02 6月, 2011 1 次提交
  21. 25 5月, 2011 1 次提交
  22. 23 5月, 2011 1 次提交
  23. 12 5月, 2011 1 次提交
  24. 06 5月, 2011 1 次提交
  25. 29 4月, 2011 2 次提交