1. 26 Jul, 2019 2 commits
  2. 19 Jun, 2019 1 commit
  3. 14 Jun, 2019 4 commits
  4. 26 Apr, 2019 3 commits
  5. 08 Apr, 2019 1 commit
    • Felix Fietkau's avatar
      mac80211: make ieee80211_schedule_txq schedule empty TXQs · 2b4a6698
      Felix Fietkau authored
      Currently there is no way for the driver to signal to mac80211 that it should
      schedule a TXQ even if there are no packets on the mac80211 part of that queue.
      This is problematic if the driver has an internal retry queue to deal with
      software A-MPDU retry.
      This patch changes the behavior of ieee80211_schedule_txq to always schedule
      the queue, as its only user (ath9k) seems to expect such behavior already:
      it calls this function on tx status and on powersave wakeup whenever its
      internal retry queue is not empty.
      Also add an extra argument to ieee80211_return_txq to get the same behavior.
      This fixes an issue on ath9k where tx queues with packets to retry (and no
      new packets in mac80211) would not get serviced.
      Fixes: 89cea749 ("ath9k: Switch to mac80211 TXQ scheduling and airtime APIs")
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Acked-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  6. 29 Mar, 2019 1 commit
  7. 22 Feb, 2019 3 commits
  8. 08 Feb, 2019 2 commits
  9. 01 Feb, 2019 2 commits
  10. 25 Jan, 2019 1 commit
  11. 19 Jan, 2019 3 commits
    • Felix Fietkau's avatar
      mac80211: minstrel_ht: add flag to indicate missing/inaccurate tx A-MPDU length · 77f7ffdc
      Felix Fietkau authored
      Some hardware (e.g. MediaTek MT7603) cannot report A-MPDU length in tx status
      information. Add support for a flag to indicate that, to allow minstrel_ht
      to use a fixed value in its internal calculation (which gives better results
      than just defaulting to 1).
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Toke Høiland-Jørgensen's avatar
      mac80211: Add airtime accounting and scheduling to TXQs · b4809e94
      Toke Høiland-Jørgensen authored
      This adds airtime accounting and scheduling to the mac80211 TXQ
      scheduler. A new callback, ieee80211_sta_register_airtime(), is added
      that drivers can call to report airtime usage for stations.
      When airtime information is present, mac80211 will schedule TXQs
      (through ieee80211_next_txq()) in a way that enforces airtime fairness
      between active stations. This scheduling works the same way as the ath9k
      in-driver airtime fairness scheduling. If no airtime usage is reported
      by the driver, the scheduler will default to round-robin scheduling.
      For drivers that don't control TXQ scheduling in software, a new API
      function, ieee80211_txq_may_transmit(), is added which the driver can use
      to check if the TXQ is eligible for transmission, or should be throttled to
      enforce fairness. Calls to this function must also be enclosed in
      ieee80211_txq_schedule_{start,end}() calls to ensure proper locking.
      The API ieee80211_txq_may_transmit() also ensures that TXQ list will be
      aligned aginst driver's own round-robin scheduler list. i.e it rotates
      the TXQ list till it makes the requested node becomes the first entry
      in TXQ list. Thus both the TXQ list and driver's list are in sync.
      Co-developed-by: default avatarRajkumar Manoharan <rmanohar@codeaurora.org>
      Signed-off-by: default avatarLouie Lu <git@louie.lu>
      [added debugfs write op to reset airtime counter]
      Signed-off-by: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Toke Høiland-Jørgensen's avatar
      mac80211: Add TXQ scheduling API · 18667600
      Toke Høiland-Jørgensen authored
      This adds an API to mac80211 to handle scheduling of TXQs. The interface
      between driver and mac80211 for TXQ handling is changed by adding two new
      functions: ieee80211_next_txq(), which will return the next TXQ to schedule
      in the current round-robin rotation, and ieee80211_return_txq(), which the
      driver uses to indicate that it has finished scheduling a TXQ (which will
      then be put back in the scheduling rotation if it isn't empty).
      The driver must call ieee80211_txq_schedule_start() at the start of each
      scheduling session, and ieee80211_txq_schedule_end() at the end. The API
      then guarantees that the same TXQ is not returned twice in the same
      session (so a driver can loop on ieee80211_next_txq() without worrying
      about breaking the loop.
      Usage of the new API is optional, so drivers can be ported one at a time.
      In this patch, the actual scheduling performed by mac80211 is simple
      round-robin, but a subsequent commit adds airtime fairness awareness to the
      Signed-off-by: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      [minor kernel-doc fix, propagate sparse locking checks out]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  12. 18 Dec, 2018 3 commits
  13. 09 Nov, 2018 2 commits
  14. 12 Oct, 2018 2 commits
  15. 05 Sep, 2018 9 commits
    • Sara Sharon's avatar
      mac80211: add an option for drivers to check if packets can be aggregated · 9739fe29
      Sara Sharon authored
      Some hardwares have limitations on the packets' type in AMSDU.
      Add an optional driver callback to determine if two skbs can
      be used in the same AMSDU or not.
      Signed-off-by: default avatarSara Sharon <sara.sharon@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Sara Sharon's avatar
      mac80211: allow AMSDU size limitation per-TID · edba6bda
      Sara Sharon authored
      Some drivers may have AMSDU size limitation per TID, due to
      HW constrains. Add an option to set this limit.
      Signed-off-by: default avatarSara Sharon <sara.sharon@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Sara Sharon's avatar
      mac80211: add an option for station management TXQ · 0eeb2b67
      Sara Sharon authored
      We have a TXQ abstraction for non-data packets that need
      powersave buffering. Since the AP cannot sleep, in case
      of station we can use this TXQ for all management frames,
      regardless if they are bufferable. Add HW flag to allow
      Signed-off-by: default avatarSara Sharon <sara.sharon@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Shaul Triebitz's avatar
      mac80211: support reporting 0-length PSDU in radiotap · c3d1f875
      Shaul Triebitz authored
      For certain sounding frames, it may be useful to report them
      to userspace even though they don't have a PSDU in order to
      determine the PHY parameters (e.g. VHT rate/stream config.)
      Add support for this to mac80211.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Alexander Wetzel's avatar
      mac80211: Fix PTK rekey freezes and clear text leak · 62872a9b
      Alexander Wetzel authored
      Rekeying PTK keys without "Extended Key ID for Individually Addressed
      Frames" did use a procedure not suitable to replace in-use keys and
      could caused the following issues:
       1) Freeze caused by incoming frames:
          If the local STA installed the key prior to the remote STA we still
          had the old key active in the hardware when mac80211 switched over
          to the new key.
          Therefore there was a window where the card could hand over frames
          decoded with the old key to mac80211 and bump the new PN (IV) value
          to an incorrect high number. When it happened the local replay
          detection silently started to drop all frames sent with the new key.
       2) Freeze caused by outgoing frames:
          If mac80211 was providing the PN (IV) and handed over a clear text
          frame for encryption to the hardware prior to a key change the
          driver/card could have processed the queued frame after switching
          to the new key. This bumped the PN value on the remote STA to an
          incorrect high number, tricking the remote STA to discard all frames
          we sent later.
       3) Freeze caused by RX aggregation reorder buffer:
          An aggregation session started with the old key and ending after the
          switch to the new key also bumped the PN to an incorrect high number,
          freezing the connection quite similar to 1).
       4) Freeze caused by repeating lost frames in an aggregation session:
          A driver could repeat a lost frame and encrypt it with the new key
          while in a TX aggregation session without updating the PN for the
          new key. This also could freeze connections similar to 2).
       5) Clear text leak:
          Removing encryption offload from the card cleared the encryption
          offload flag only after the card had deleted the key and we did not
          stop TX during the rekey. The driver/card could therefore get
          unencrypted frames from mac80211 while no longer be instructed to
          encrypt them.
      To prevent those issues the key install logic has been changed:
       - Mac80211 divers known to be able to rekey PTK0 keys have to set
       - mac80211 stops queuing frames depending on the key during the replace
       - the key is first replaced in the hardware and after that in mac80211
       - and mac80211 stops/blocks new aggregation sessions during the rekey.
      For drivers not setting
      @NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 the user space must avoid PTK
      rekeys if "Extended Key ID for Individually Addressed Frames" is not
      being used. Rekeys for mac80211 drivers without this flag will generate a
      warning and use an extra call to ieee80211_flush_queues() to both
      highlight and try to prevent the issues with not updated drivers.
      The core of the fix changes the key install procedure from:
       - atomic switch over to the new key in mac80211
       - remove the old key in the hardware (stops encryption offloading, fall
         back to software encryption with a potential clear text packet leak
         in between)
       - delete the inactive old key in mac80211
       - enable hardware encryption offloading for the new key
       - if it's a PTK mark the old key as tainted to drop TX frames with the
         outgoing key
       - replace the key in hardware with the new one
       - atomic switch over to the new (not marked as tainted) key in
         mac80211 (which also resumes TX)
       - delete the inactive old key in mac80211
      With the new sequence the hardware will be unable to decrypt frames
      encrypted with the old key prior to switching to the new key in mac80211
      and thus prevent PNs from packets decrypted with the old key to be
      accounted against the new key.
      For that to work the drivers have to provide a clear boundary.
      Mac80211 drivers setting @NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 confirm
      to provide it and mac80211 will then be able to correctly rekey in-use
      PTK keys with those drivers.
      The mac80211 requirements for drivers to set the flag have been added to
      the "Hardware crypto acceleration" documentation section. It drills down
      The drivers must not hand over frames decrypted with the old key to
      mac80211 once the call to set_key() with %DISABLE_KEY has been
      completed. It's allowed to either drop or continue to use the old key
      for any outgoing frames which are already in the queues, but it must not
      send out any of them unencrypted or encrypted with the new key.
      Even with the new boundary in place aggregation sessions with the
      reorder buffer are problematic:
      RX aggregation session started prior and completed after the rekey could
      still dump frames received with the old key at mac80211 after it
      switched over to the new key. This is side stepped by stopping all (RX
      and TX) aggregation sessions when replacing a PTK key and hardware key
      Stopping TX aggregation sessions avoids the need to get
      the PNs (IVs) updated in frames prepared for the old key and
      (re)transmitted after the switch to the new key. As a bonus it improves
      the compatibility when the remote STA is not handling rekeys as it
      When using software crypto aggregation sessions are not stopped.
      Mac80211 won't be able to decode the dangerous frames and discard them
      without special handling.
      Signed-off-by: default avatarAlexander Wetzel <alexander@wetzel-home.de>
      [trim overly long rekey warning]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Shaul Triebitz's avatar
      mac80211: support radiotap L-SIG data · d1332e7b
      Shaul Triebitz authored
      As before with HE, the data needs to be provided by the
      driver in the skb head, since there's not enough space
      in the skb CB.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Wen Gong's avatar
      mac80211: Store sk_pacing_shift in ieee80211_hw · 70e53669
      Wen Gong authored
      Make it possibly for drivers to adjust the default skb_pacing_shift
      by storing it in the hardware struct.
      Signed-off-by: default avatarWen Gong <wgong@codeaurora.org>
      [adjust commit log, move & adjust comment]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: introduce capability flags for VHT EXT NSS support · 09b4a4fa
      Johannes Berg authored
      Depending on whether or not rate control supports selecting
      rates depending on the bandwidth, we can use VHT extended
      NSS support. In essence, this is dot11VHTExtendedNSSBWCapable
      from the spec, since depending on that we'll need to parse
      the bandwidth.
      If needed, also set/clear the VHT Capability Element bit for
      this capability so that we don't advertise it erroneously or
      don't advertise it when we actually use it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: add an optional TXQ for other PS-buffered frames · adf8ed01
      Johannes Berg authored
      Some drivers may want to also use the TXQ abstraction with
      non-data packets that need powersave buffering, so add a
      hardware flag to allow this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  16. 28 Aug, 2018 1 commit
    • Manikanta Pubbisetty's avatar
      mac80211: add stop/start logic for software TXQs · 21a5d4c3
      Manikanta Pubbisetty authored
      Sometimes, it is required to stop the transmissions momentarily and
      resume it later; stopping the txqs becomes very critical in scenarios where
      the packet transmission has to be ceased completely. For example, during
      the hardware restart, during off channel operations,
      when initiating CSA(upon detecting a radar on the DFS channel), etc.
      The TX queue stop/start logic in mac80211 works well in stopping the TX
      when drivers make use of netdev queues, i.e, when Qdiscs in network layer
      take care of traffic scheduling. Since the devices implementing
      wake_tx_queue can run without Qdiscs, packets will be handed to mac80211
      directly without queueing them in the netdev queues.
      Also, mac80211 does not invoke any of the
      netif_stop_*/netif_wake_* APIs if wake_tx_queue is implemented.
      Since the queues are not stopped in this case, transmissions can continue
      and this will impact negatively on the operation of the wireless device.
      For example,
      During hardware restart, we stop the netdev queues so that packets are
      not sent to the driver. Since ath10k implements wake_tx_queue,
      TX queues will not be stopped and packets might reach the hardware while
      it is restarting; this can make hardware unresponsive and the only
      possible option for recovery is to reboot the entire system.
      There is another problem to this, it is observed that the packets
      were sent on the DFS channel for a prolonged duration after radar
      detection impacting the channel closing time.
      We can still invoke netif stop/wake APIs when wake_tx_queue is implemented
      but this could lead to packet drops in network layer; adding stop/start
      logic for software TXQs in mac80211 instead makes more sense; the change
      proposed adds the same in mac80211.
      Signed-off-by: default avatarManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>