1. 20 4月, 2018 1 次提交
  2. 06 12月, 2017 1 次提交
    • G
      iwlwifi: mvm: rs: introduce new API for rate scaling · ecaf71de
      Gregory Greenman 提交于
      New devices will have rate scaling algorithm running in the firmware.
      With this feature, the driver's responsiblity is to provide an initial
      configuration and to handle notifications regarding recent rates and
      some other parameters. Debugfs hooks will be still available for
      reading the current rate/statistics and setting a fixed rate.
      The old API is supported so far, though both APIs cannot be used
      simultaneously.
      
      This is the first patch in the series. It adds a new TLV specifying
      FW support for the new API and updates lq_sta to support two types
      of rate scaling.
      Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      ecaf71de
  3. 08 9月, 2017 1 次提交
  4. 18 8月, 2017 1 次提交
  5. 01 8月, 2017 2 次提交
  6. 23 6月, 2017 1 次提交
  7. 06 6月, 2017 1 次提交
    • G
      iwlwifi: mvm: rs: start using LQ command color · ea42d1cb
      Gregory Greenman 提交于
      Up until now, the driver was comparing the rate reported by the FW and
      the rate of the latest LQ command to avoid processing data belonging
      to the old LQ command. Recently, FW changed the meaning of the initial
      rate field in tx response and it holds the actual rate (which is not
      necessarily the initial rate of LQ's rate table). Use instead LQ cmd
      color to be able to filter out tx responses/BA notifications which
      where sent during earlier LQ commands' time frame.
      
      This fixes some throughput degradation in noisy environments.
      Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      ea42d1cb
  8. 02 6月, 2017 1 次提交
  9. 26 4月, 2017 1 次提交
    • S
      iwlwifi: mvm: support station type API · ced19f26
      Sara Sharon 提交于
      Support change to ADD_STA API to support station types.
      Each station is assigned its type.
      This simplifies FW handling of the broadcast and multicast
      stations:
      * broadcast station is identified by its type and not the mac
        address.
      * multicast queue is no longer treated differently. The opening
        and closing of it is done by referring to its station.
        There is no need to specify it in the MAC command.
      * When disabling TX to all station driver can disable the traffic
        on multicast station, so FW doesn't have to do it.
      Change is backward compatible.
      Change the order of adding and removing the stations according to
      FW requirements.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      ced19f26
  10. 11 4月, 2017 2 次提交
    • S
      iwlwifi: mvm: add multicast station · 26d6c16b
      Sara Sharon 提交于
      Currently multicast queue is associated with the broadcast
      station.
      
      This raises quite a few issues:
      
      The multicast queue has a special treatment:
      - It is sent in the MAC context command
      - It is excluded from tfd_queue_mask
      
      In DQA mode we end up enabling two queues - the probe response
      queue and the multicast queue - with the same station (broadcast)
      and TID while in DQA mode it should be unique RA-TID.
      Firmware will enforce it for a000 devices, so this allocation
      will fail.
      
      In addition, in a000 devices the FW will set the FIFO and not
      the driver. So there is a need for FW to know when we enable
      the queue that it is multicast queue so it will be bound to
      the multicast FIFO. There is no such way in current design.
      
      In order to simplify driver and firmware handling of this queue
      create a multicast station.
      This solves the unique RA-TID issue in the short term and serves
      as preparation for the long term.
      
      In the long term we will also add a flag marking this station for
      the FW as the multicast station.
      Once we will do that the FW will know this is the multicast queue
      immediately when it is added and bind it to the correct FIFO.
      It will also enable removing the special treatment of the
      queue in the MAC context command.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      26d6c16b
    • S
      iwlwifi: mvm: cleanup pending frames in DQA mode · 1c17627b
      Sara Sharon 提交于
      When a station is asleep, the fw will set it as "asleep".
      All queues that are used only by one station will be stopped by
      the fw.
      
      In pre-DQA mode this was relevant for aggregation queues. However,
      in DQA mode a queue is owned by one station only, so all queues
      will be stopped.
      As a result, we don't expect to get filtered frames back to
      mac80211 and don't have to maintain the entire pending_frames
      state logic, the same way as we do in aggregations.
      
      The correct behavior is to align DQA behavior with the aggregation
      queue behaviour pre-DQA:
      - Don't count pending frames.
      - Let mac80211 know we have frames in these queues so that it can
      properly handle trigger frames.
      
      When a trigger frame is received, mac80211 tells the driver to send
      frames from the queues using release_buffered_frames.
      The driver will tell the fw to let frames out even if the station
      is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      1c17627b
  11. 16 3月, 2017 1 次提交
    • S
      iwlwifi: mvm: cleanup pending frames in DQA mode · 9a3fcf91
      Sara Sharon 提交于
      When a station is asleep, the fw will set it as "asleep".
      All queues that are used only by one station will be stopped by
      the fw.
      
      In pre-DQA mode this was relevant for aggregation queues. However,
      in DQA mode a queue is owned by one station only, so all queues
      will be stopped.
      As a result, we don't expect to get filtered frames back to
      mac80211 and don't have to maintain the entire pending_frames
      state logic, the same way as we do in aggregations.
      
      The correct behavior is to align DQA behavior with the aggregation
      queue behaviour pre-DQA:
      - Don't count pending frames.
      - Let mac80211 know we have frames in these queues so that it can
      properly handle trigger frames.
      
      When a trigger frame is received, mac80211 tells the driver to send
      frames from the queues using release_buffered_frames.
      The driver will tell the fw to let frames out even if the station
      is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
      Reported-and-tested-by: NJens Axboe <axboe@kernel.dk>
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      9a3fcf91
  12. 03 2月, 2017 1 次提交
  13. 19 10月, 2016 1 次提交
  14. 19 9月, 2016 1 次提交
  15. 30 8月, 2016 1 次提交
  16. 06 7月, 2016 2 次提交
  17. 11 5月, 2016 2 次提交
    • S
      iwlwifi: mvm: add reorder buffer per queue · b915c101
      Sara Sharon 提交于
      Next hardware will direct packets to core based on the TCP/UDP
      streams.
      This logic can create holes in reorder buffer since packets that
      belong to other stream were directed to a different core.
      However, those are valid holes and the packets can be indicated
      in L3 order.
      
      The hardware will utilize a mechanism of informing the driver of
      the normalized ssn and the driver shall release all packets that
      SN is lower than the nssn.
      This enables managing the reorder across the queues without sharing
      any data between them.
      
      The reorder buffer is allocated and released directly in the RX path
      in order to avoid various races between control path and rx path.
      The code utilizes the internal messaging to notify rx queues of when
      to delete the reorder buffer.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      b915c101
    • S
      iwlwifi: mvm: add infrastructure for tracking BA session in driver · 10b2b201
      Sara Sharon 提交于
      According to the spec when a BA session is started there
      is a timeout set for the session in the ADDBA request.
      If there is not activity on the TA/TID then the session
      expires and a DELBA is sent.
      In order to check for the timeout, data must be shared
      among the rx queues.
      Add a timer that runs as long as BA session is active
      for the station and stops aggregation session if needed.
      This patch also lays the infrastructure for the reordering
      buffer which will be enabled in the next patches.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      10b2b201
  18. 30 3月, 2016 1 次提交
    • L
      iwlwifi: mvm: support bss dynamic alloc/dealloc of queues · 24afba76
      Liad Kaufman 提交于
      "DQA" is shorthand for "dynamic queue allocation". This
      enables on-demand allocation of queues per RA/TID rather than
      statically allocating per vif, thus allowing a potential
      benefit of various factors.
      
      Please refer to the DOC section this patch adds to sta.h to
      see a more in-depth explanation of this feature.
      
      There are many things to take into consideration when working
      in DQA mode, and this patch is only one in a series. Note that
      default operation mode is non-DQA mode, unless the FW
      indicates that it supports DQA mode.
      
      This patch enables support of DQA for a station connected to
      an AP, and works in a non-aggregated mode.
      
      When a frame for an unused RA/TID arrives at the driver, it
      isn't TXed immediately, but deferred first until a suitable
      queue is first allocated for it, and then TXed by a worker
      that both allocates the queues and TXes deferred traffic.
      
      When a STA is removed, its queues goes back into the queue
      pools for reuse as needed.
      Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      24afba76
  19. 28 2月, 2016 4 次提交
  20. 01 2月, 2016 1 次提交
  21. 08 1月, 2016 1 次提交
    • J
      iwlwifi: mvm: check PN for CCMP/GCMP in the driver · f5e28eac
      Johannes Berg 提交于
      As we're working on multi-queue RX, we want to parallelise checking
      the PN in order to avoid having to serialise the RX processing.
      
      It may seem that doing parallel PN checking is insecure, but it turns
      out to be OK because queue assignment is done based on the data in the
      frame (IP/TCP) and thus cannot be manipulated by an attacker, since
      the data is encrypted and must first have been decrypted successfully.
      
      There are some corner cases, in particular when the peer starts using
      fragmentation which redirects the packet to the default queue. However
      this redirection is remembered (for the STA, per TID) and thus cannot
      be exploited by an attacker either.
      
      Leave checking on the default queue (queue 0) to mac80211, since we
      get fragmented packets there and those are subject to stricter checks
      during reassembly.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      f5e28eac
  22. 21 12月, 2015 1 次提交
  23. 20 12月, 2015 1 次提交
  24. 13 12月, 2015 1 次提交
  25. 18 11月, 2015 1 次提交
  26. 16 11月, 2015 1 次提交
    • L
      iwlwifi: mvm: don't overwrite the key indices in D3 entry · d6ee54a9
      Luca Coelho 提交于
      When entering D3, we need to use hardcoded key indices because the
      firmware requires that.  To do so, we are overwriting the HW key index
      in the keyconf structure, which makes it impossible to reuse the
      indices that were used before entering D3.  Additionally, we overwrite
      all the non-PTK keys with index 1, because the firmware only allows
      one non-PTK key to be set.  This is bad, because when we resume, we
      may try to set more than one key with index 1, which will obviously
      fail.
      
      To fix this, allow the callers to set a pre-defined index to use in
      iwl_mvm_set_sta_key() instead of relying on the hw_key_idx value from
      the keyconf struct (which requires overwriting it).  In normal cases,
      the caller can pass STA_KEY_IDX_INVALID, which will cause a new key
      offset to be chosen.  During HW_RESTART, we pass the offset that is in
      use.  And during D3 entry, we pass the hardcoded indices we need to
      use.
      
      Additionally, don't clear the fw_key_table in D3 entry, so that the
      flags are still set with the pre-D3 values when exiting D3.
      
      fixes=I3165c22362483f0152d9ec1d2a987fb5529727c1
      
      Fixes: b546dcd6 ("iwlwifi: mvm: don't reset key index on HW restart")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      d6ee54a9
  27. 04 8月, 2015 1 次提交
  28. 02 4月, 2015 1 次提交
  29. 24 11月, 2014 3 次提交
  30. 21 9月, 2014 1 次提交
  31. 04 9月, 2014 1 次提交