1. 05 Apr, 2016 3 commits
  2. 05 Mar, 2016 1 commit
  3. 24 Feb, 2016 4 commits
  4. 04 Dec, 2015 1 commit
  5. 21 Oct, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: move station statistics into sub-structs · e5a9f8d0
      Johannes Berg authored
      Group station statistics by where they're (mostly) updated
      (TX, RX and TX-status) and group them into sub-structs of
      the struct sta_info.
      Also rename the variables since the grouping now makes it
      obvious where they belong.
      This makes it easier to identify where the statistics are
      updated in the code, and thus easier to think about them.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  6. 29 Sep, 2015 2 commits
  7. 24 Sep, 2015 1 commit
  8. 14 Aug, 2015 1 commit
  9. 17 Jul, 2015 5 commits
    • Johannes Berg's avatar
      mac80211: account TX MSDUs properly with segmentation offload · ccc6bb96
      Johannes Berg authored
      If an SKB will be segmented by the driver, count it for multiple
      MSDUs that are being transmitted rather than just a single.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Bob Copeland's avatar
      mac80211: enable assoc check for mesh interfaces · 3633ebeb
      Bob Copeland authored
      We already set a station to be associated when peering completes, both
      in user space and in the kernel.  Thus we should always have an
      associated sta before sending data frames to that station.
      Failure to check assoc state can cause crashes in the lower-level driver
      due to transmitting unicast data frames before driver sta structures
      (e.g. ampdu state in ath9k) are initialized.  This occurred when
      forwarding in the presence of fixed mesh paths: frames were transmitted
      to stations with whom we hadn't yet completed peering.
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAlexis Green <agreen@cococorp.com>
      Tested-by: default avatarJesse Jones <jjones@cococorp.com>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Wojciech Dubowik's avatar
      mac80211: avoid unnecessary beacon deref on CSA counter update · e996ec2a
      Wojciech Dubowik authored
      The beacon struct is already available in many contexts that
      are also already in an RCU read-locked section. Avoid that by
      using the existing beacon struct pointer directly.
      Signed-off-by: default avatarWojciech Dubowik <Wojciech.Dubowik@neratec.com>
      [rewrite subject/add commit message]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: remove key TX/RX counter · 77c96404
      Johannes Berg authored
      This counter is inherently racy (since it can be incremented by RX
      as well as by concurrent TX) and only available in debugfs. Instead
      of fixing it to be per-CPU or similar, remove it for now. If needed
      it should be added without races and with proper nl80211, perhaps
      even addressing the threshold reporting TODO item that's been there
      since the code was originally added.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Michal Kazior's avatar
      mac80211: don't clear all tx flags when requeing · e9de0190
      Michal Kazior authored
      When acting as AP and a PS-Poll frame is received
      associated station is marked as one in a Service
      Period. This state is kept until Tx status for
      released frame is reported. While a station is in
      Service Period PS-Poll frames are ignored.
      However if PS-Poll was received during A-MPDU
      teardown it was possible to have the to-be
      released frame re-queued back to pending queue.
      In such case the frame was stripped of 2 important
       (a) IEEE80211_TX_CTL_NO_PS_BUFFER
       (b) IEEE80211_TX_STATUS_EOSP
      Stripping of (a) led to the frame that was to be
      released to be queued back to ps_tx_buf queue. If
      station remained to use only PS-Poll frames the
      re-queued frame (and new ones) was never actually
      transmitted because mac80211 would ignore
      subsequent PS-Poll frames due to station being in
      Service Period. There was nothing left to clear
      the Service Period bit (no xmit -> no tx status ->
      no SP end), i.e. the AP would have the station
      stuck in Service Period. Beacon TIM would
      repeatedly prompt station to poll for frames but
      it would get none.
      Once (a) is not stripped (b) becomes important
      because it's the main condition to clear the
      Service Period bit of the station when Tx status
      for the released frame is reported back.
      This problem was observed with ath9k acting as P2P
      GO in some testing scenarios but isn't limited to
      it. AP operation with mac80211 based Tx A-MPDU
      control combined with clients using PS-Poll frames
      is subject to this race.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  10. 10 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg authored
      As we're running out of hardware capability flags pretty quickly,
      convert them to use the regular test_bit() style unsigned long
      This introduces a number of helper functions/macros to set and to
      test the bits, along with new debugfs code.
      The occurrences of an explicit __clear_bit() are intentional, the
      drivers were never supposed to change their supported bits on the
      fly. We should investigate changing this to be a per-frame flag.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  11. 09 Jun, 2015 1 commit
  12. 02 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg authored
      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: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  13. 05 May, 2015 2 commits
  14. 24 Apr, 2015 2 commits
  15. 22 Apr, 2015 7 commits
    • Johannes Berg's avatar
      mac80211: allow segmentation offloads · 80616c0d
      Johannes Berg authored
      Implement the necessary software segmentation on the normal
      TX path so that fast-xmit can use segmentation offload if
      the hardware (or driver) supports it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: allow drivers to support S/G · 680a0dab
      Johannes Berg authored
      If drivers want to support S/G (really just gather DMA on TX) then
      we can now easily support this on the fast-xmit path since it just
      needs to write to the ethernet header (and already has a check for
      that being possible.)
      However, disallow this on the regular TX path (which has to handle
      fragmentation, software crypto, etc.) by calling skb_linearize().
      Also allow the related HIGHDMA since that's not interesting to the
      code in mac80211 at all anyway.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: allow checksum offload only in fast-xmit · 2d981fdd
      Johannes Berg authored
      When we go through the complete TX processing, there are a number
      of things like fragmentation and software crypto that require the
      checksum to be calculated already.
      In favour of maintainability, instead of adding the necessary call
      to skb_checksum_help() in all the places that need it, just do it
      once before the regular TX processing.
      Right now this only affects the TI wlcore and QCA ath10k drivers
      since they're the only ones using checksum offload. The previous
      commits enabled fast-xmit for them in almost all cases.
      For wlcore this even fixes a corner case: when a key fails to be
      programmed to hardware software encryption gets used, encrypting
      frames with a bad checksum.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: extend fast-xmit to cover IBSS · 3ffd8840
      Johannes Berg authored
      IBSS can be supported very easily since it uses the standard station
      authorization state etc. so it just needs to be covered by the header
      building switch statement.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: extend fast-xmit for more ciphers · e495c247
      Johannes Berg authored
      When crypto is offloaded then in some cases it's all handled
      by the device, and in others only some space for the IV must
      be reserved in the frame. Handle both of these cases in the
      fast-xmit path, up to a limit of 18 bytes of space for IVs.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: extend fast-xmit to driver fragmentation · 725b812c
      Johannes Berg authored
      If the driver handles fragmentation then it wouldn't
      be done in software so we can still use the fast-xmit
      path in that case.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: add TX fastpath · 17c18bf8
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
  16. 01 Apr, 2015 1 commit
    • Felix Fietkau's avatar
      mac80211: add an intermediate software queue implementation · ba8c3d6f
      Felix Fietkau authored
      This allows drivers to request per-vif and per-sta-tid queues from which
      they can pull frames. This makes it easier to keep the hardware queues
      short, and to improve fairness between clients and vifs.
      The task of scheduling packet transmission is left up to the driver -
      queueing is controlled by mac80211. Drivers can only dequeue packets by
      calling ieee80211_tx_dequeue. This makes it possible to add active queue
      management later without changing drivers using this code.
      This can also be used as a starting point to implement A-MSDU
      aggregation in a way that does not add artificially induced latency.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      [resolved minor context conflict, minor changes, endian annotations]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  17. 30 Mar, 2015 2 commits
  18. 20 Mar, 2015 4 commits
    • Johannes Berg's avatar
      mac80211: avoid duplicate TX path station lookup · 7c10770f
      Johannes Berg authored
      Instead of looking up the destination station twice in the TX path
      (first to build the header, and then for control processing), save
      it when building the header and use it later in the TX path.
      To avoid having to look up the station in the many callers, allow
      those to pass %NULL which keeps the existing lookup.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: mesh: avoid pointless station lookup · e33f5569
      Johannes Berg authored
      In ieee80211_build_hdr(), the station is looked up to build the
      header correctly (QoS field) and to check for authorization. For
      mesh, authorization isn't checked here, and QoS capability is
      mandatory, so the station lookup can be avoided.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: drop 4-addr VLAN frames earlier if not connected · a8d15ff0
      Johannes Berg authored
      If there's no station on the 4-addr VLAN interface, then frames
      cannot be transmitted. Drop such frames earlier, before setting
      up all the information for them.
      We should keep the old check though since that code might be used
      for other internally-generated frames.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: don't look up destination station twice · 5041006c
      Johannes Berg authored
      There's no need to look up the destination station twice while
      building the 802.11 header for a given frame if the frame will
      actually be transmitted to the station we initially looked up.
      This happens for 4-addr VLAN interfaces and TDLS connections, which
      both directly send the frame to the station they looked up, though
      in the case of TDLS some station conditions need to be checked.
      To avoid that, add a variable indicating that we've looked up the
      station that the frame is going to be transmitted to, and avoid the
      lookup/flag checking if it already has been done.
      In the TDLS case, also move the authorized/wme_sta flag assignment
      to the correct place, i.e. only when that station is really used.
      Before this change, the new lookup should always have succeeded so
      that the potentially erroneous data would be overwritten.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>