1. 30 9月, 2016 5 次提交
  2. 15 9月, 2016 1 次提交
  3. 12 9月, 2016 2 次提交
  4. 05 8月, 2016 1 次提交
  5. 06 7月, 2016 1 次提交
  6. 12 4月, 2016 1 次提交
  7. 06 4月, 2016 2 次提交
    • J
      mac80211: add fast-rx path · 49ddf8e6
      Johannes Berg 提交于
      The regular RX path has a lot of code, but with a few
      assumptions on the hardware it's possible to reduce the
      amount of code significantly. Currently the assumptions
      on the driver are the following:
       * hardware/driver reordering buffer (if supporting aggregation)
       * hardware/driver decryption & PN checking (if using encryption)
       * hardware/driver did de-duplication
       * hardware/driver did A-MSDU deaggregation
       * AP_LINK_PS is used (in AP mode)
       * no client powersave handling in mac80211 (in client mode)
      
      of which some are actually checked per packet:
       * de-duplication
       * PN checking
       * decryption
      and additionally packets must
       * not be A-MSDU (have been deaggregated by driver/device)
       * be data packets
       * not be fragmented
       * be unicast
       * have RFC 1042 header
      
      Additionally dynamically we assume:
       * no encryption or CCMP/GCMP, TKIP/WEP/other not allowed
       * station must be authorized
       * 4-addr format not enabled
      
      Some data needed for the RX path is cached in a new per-station
      "fast_rx" structure, so that we only need to look at this and
      the packet, no other memory when processing packets on the fast
      RX path.
      
      After doing the above per-packet checks, the data path collapses
      down to a pretty simple conversion function taking advantage of
      the data cached in the small fast_rx struct.
      
      This should speed up the RX processing, and will make it easier
      to reason about parallelizing RX (for which statistics will need
      to be per-CPU still.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      49ddf8e6
    • A
      mac80211: track and tell driver about GO client P2P PS abilities · 52cfa1d6
      Ayala Beker 提交于
      Legacy clients don't support P2P power save mechanism, and thus if a P2P GO
      has a legacy client connected to it, it should disable P2P PS mechanisms.
      Let the driver know about this with a new bss_conf parameter.
      Signed-off-by: NAyala Beker <ayala.beker@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      52cfa1d6
  8. 05 4月, 2016 1 次提交
    • B
      mac80211: mesh: move path tables into if_mesh · 2bdaf386
      Bob Copeland 提交于
      The mesh path and mesh gate hashtables are global, containing
      all of the mpaths for every mesh interface, but the paths are
      all tied logically to a single interface.  The common case is
      just a single mesh interface, so optimize for that by moving
      the global hashtable into the per-interface struct.
      
      Doing so allows us to drop sdata pointer comparisons inside
      the lookups and also saves a few bytes of BSS and data.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2bdaf386
  9. 24 2月, 2016 2 次提交
    • E
      mac80211: move TKIP TX IVs to public part of key struct · f8079d43
      Eliad Peller 提交于
      Some drivers/devices might want to set the IVs by
      themselves (and still let mac80211 generate MMIC).
      
      Specifically, this is needed when the device does
      offloading at certain times, and the driver has
      to make sure that the IVs of new tx frames (from
      the host) are synchronized with IVs that were
      potentially used during the offloading.
      
      Similarly to CCMP, move the TX IVs of TKIP keys to the
      public part of the key struct, and export a function
      to add the IV right into the crypto header.
      
      The public tx_pn field is defined as atomic64, so define
      TKIP_PN_TO_IV16/32 helper macros to convert it to iv16/32
      when needed.
      
      Since the iv32 used for the p1k cache is taken
      directly from the frame, we can safely remove
      iv16/32 from being protected by tkip.txlock.
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f8079d43
    • E
      mac80211: limit the A-MSDU Tx based on peer's capabilities · 506bcfa8
      Emmanuel Grumbach 提交于
      In VHT, the specification allows to limit the number of
      MSDUs in an A-MSDU in the Extended Capabilities IE. There
      is also a limitation on the byte size in the VHT IE.
      In HT, the only limitation is on the byte size.
      Parse the capabilities from the peer and make them
      available to the driver.
      
      In HT, there is another limitation when a BA agreement
      is active: the byte size can't be greater than 4095.
      This is not enforced here.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      506bcfa8
  10. 15 12月, 2015 1 次提交
  11. 04 12月, 2015 5 次提交
  12. 03 12月, 2015 1 次提交
    • J
      mac80211: fix off-channel mgmt-tx uninitialized variable usage · c1df932c
      Johannes Berg 提交于
      In the last change here, I neglected to update the cookie in one code
      path: when a mgmt-tx has no real cookie sent to userspace as it doesn't
      wait for a response, but is off-channel. The original code used the SKB
      pointer as the cookie and always assigned the cookie to the TX SKB in
      ieee80211_start_roc_work(), but my change turned this around and made
      the code rely on a valid cookie being passed in.
      
      Unfortunately, the off-channel no-wait TX path wasn't assigning one at
      all, resulting in an uninitialized stack value being used. This wasn't
      handed back to userspace as a cookie (since in the no-wait case there
      isn't a cookie), but it was tested for non-zero to distinguish between
      mgmt-tx and off-channel.
      
      Fix this by assigning a dummy non-zero cookie unconditionally, and get
      rid of a misleading comment and some dead code while at it. I'll clean
      up the ACK SKB handling separately later.
      
      Fixes: 3b79af97 ("mac80211: stop using pointers as userspace cookies")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c1df932c
  13. 03 11月, 2015 1 次提交
  14. 15 10月, 2015 3 次提交
  15. 13 10月, 2015 1 次提交
  16. 29 9月, 2015 1 次提交
  17. 22 9月, 2015 4 次提交
  18. 04 9月, 2015 1 次提交
  19. 14 8月, 2015 1 次提交
  20. 17 7月, 2015 5 次提交