1. 04 9月, 2015 1 次提交
  2. 14 8月, 2015 1 次提交
  3. 17 7月, 2015 5 次提交
  4. 10 6月, 2015 2 次提交
  5. 02 6月, 2015 3 次提交
    • J
      mac80211: stop using pointers as userspace cookies · 3b79af97
      Johannes Berg 提交于
      Even if the pointers are really only accessible to root and used
      pretty much only by wpa_supplicant, this is still not great; even
      for debugging it'd be easier to have something that's easier to
      read and guaranteed to never get reused.
      
      With the recent change to make mac80211 create an ack_skb for the
      mgmt-tx path this becomes possible, only the client probe method
      needs to also allocate an ack_skb, and we can store the cookie in
      that skb.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3b79af97
    • J
      mac80211: copy nl80211 mgmt TX SKB for status · b2eb0ee6
      Johannes Berg 提交于
      When we return the TX status for an nl80211 mgmt TX SKB, we
      should also return the original frame with the status to
      allow userspace to match up the submission (it could also
      use the cookie but both ways are permissible.)
      
      As TX SKBs could be encrypted, at least in the case of ANQP
      while associated with the AP, copy the original SKB, store
      it with an ACK frame ID and restructure the status path to
      use that to return status with the original SKB. Otherwise,
      userspace (in particular wpa_supplicant) will get confused.
      Reported-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b2eb0ee6
    • J
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg 提交于
      For drivers supporting TSO or similar features, but that still have
      PN assignment in software, there's a need to have some memory to
      store the current PN value. As mac80211 already stores this and it's
      somewhat complicated to add a per-driver area to the key struct (due
      to the dynamic sizing thereof) it makes sense to just move the TX PN
      to the keyconf, i.e. the public part of the key struct.
      
      As TKIP is more complicated and we won't able to offload it in this
      way right now (fast-xmit is skipped for TKIP unless the HW does it
      all, and our hardware needs MMIC calculation in software) I've not
      moved that for now - it's possible but requires exposing a lot of
      the internal TKIP state.
      
      As an bonus side effect, we can remove a lot of code by assuming the
      keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.
      
      This might also improve performance, since now TX and RX no longer
      share a cacheline.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      db388a56
  6. 20 5月, 2015 2 次提交
    • J
      mac80211: don't split remain-on-channel for coalescing · 252ec2b3
      Johannes Berg 提交于
      Due to remain-on-channel scheduling delays, when we split an ROC
      while coalescing, we'll usually get a picture like this:
      
      existing ROC:  |------------------|
      current time:              ^
      new ROC:                   |------|              |-------|
      
      If the expected response frames are then transmitted by the peer
      in the hole between the two fragments of the new ROC, we miss
      them and the process (e.g. ANQP query) fails.
      
      mac80211 expects that the window to miss something is small:
      
      existing ROC:  |------------------|
      new ROC:                   |------||-------|
      
      but that's normally not the case.
      
      To avoid this problem, coalesce only if the new ROC's duration
      is <= the remaining time on the existing one:
      
      existing ROC:  |------------------|
      new ROC:                   |-----|
      
      and never split a new one but schedule it afterwards instead:
      
      existing ROC:  |------------------|
      new ROC:                                       |-------------|
      
      type=bugfix
      bug=not-tracked
      fixes=unknown
      Reported-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Reviewed-by: NEliadX Peller <eliad@wizery.com>
      Reviewed-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Tested-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      252ec2b3
    • M
      mac80211: check fast-xmit on station change · 464daaf0
      Michal Kazior 提交于
      Drivers with fast-xmit (e.g. ath10k) running in
      AP_VLAN setups would fail to communicate with
      connected 4addr stations.
      
      The reason was when new station associates it
      first goes into master AP interface. It is not
      until later that a dedicated AP_VLAN is created
      for it and the station itself is moved there.
      After that Tx directed at the station should use
      4addr header. However fast-xmit wasn't
      recalculated and 3addr header remained to be used.
      This in turn caused the connected 4addr stations
      to drop packets coming from the AP until some
      other event would cause fast-xmit to recalculate
      for that station (which could never come).
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      464daaf0
  7. 06 5月, 2015 2 次提交
  8. 24 4月, 2015 1 次提交
  9. 22 4月, 2015 1 次提交
    • J
      mac80211: add TX fastpath · 17c18bf8
      Johannes Berg 提交于
      In order to speed up mac80211's TX path, add the "fast-xmit" cache
      that will cache the data frame 802.11 header and other data to be
      able to build the frame more quickly. This cache is rebuilt when
      external triggers imply changes, but a lot of the checks done per
      packet today are simplified away to the check for the cache.
      
      There's also a more detailed description in the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17c18bf8
  10. 30 3月, 2015 4 次提交
  11. 20 3月, 2015 1 次提交
  12. 17 3月, 2015 1 次提交
  13. 04 3月, 2015 2 次提交
  14. 01 3月, 2015 1 次提交
  15. 27 1月, 2015 4 次提交
  16. 23 1月, 2015 1 次提交
  17. 16 1月, 2015 1 次提交
    • J
      cfg80211: change bandwidth reporting to explicit field · b51f3bee
      Johannes Berg 提交于
      For some reason, we made the bandwidth separate flags, which
      is rather confusing - a single rate cannot have different
      bandwidths at the same time.
      
      Change this to no longer be flags but use a separate field
      for the bandwidth ('bw') instead.
      
      While at it, add support for 5 and 10 MHz rates - these are
      reported as regular legacy rates with their real bitrate,
      but tagged as 5/10 now to make it easier to distinguish them.
      
      In the nl80211 API, the flags are preserved, but the code
      now can also clearly only set a single one of the flags.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b51f3bee
  18. 15 1月, 2015 1 次提交
  19. 14 1月, 2015 2 次提交
  20. 15 12月, 2014 1 次提交
  21. 20 11月, 2014 3 次提交