1. 21 7月, 2017 2 次提交
  2. 29 6月, 2017 3 次提交
  3. 23 6月, 2017 5 次提交
  4. 06 6月, 2017 2 次提交
  5. 02 6月, 2017 3 次提交
  6. 26 4月, 2017 7 次提交
  7. 25 4月, 2017 1 次提交
  8. 20 4月, 2017 7 次提交
    • E
      iwlwifi: mvm: provide the actual number of frames for the SP len · e71ca5ea
      Emmanuel Grumbach 提交于
      In the end, the firmware doesn't want the SP len as present
      in the WMM IE, but rather the actual number of frames.
      
      Fixes: bd3c6cf901a8 ("iwlwifi: mvm: tell the firmware about the U-APSD parameters")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      e71ca5ea
    • S
      iwlwifi: mvm: ignore BAID for SN smaller than SSN · 5d43eab6
      Sara Sharon 提交于
      When we get SN that is smaller than SSN of the aggregation,
      we shouldn't apply any reordering on them.
      Further more, HW NSSN will be zeroed, which can cause us
      to make some invalid decisions.
      Detect the situation and invalidate the BAID.
      
      Fixes: b915c101 ("iwlwifi: mvm: add reorder buffer per queue")
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      5d43eab6
    • S
      iwlwifi: move to TVQM mode · 310181ec
      Sara Sharon 提交于
      In TVQM firmware returns the value of the queue ID and code
      should accept it.
      The TX queue config API was changed. Move to new API.
      This has to be done in parallel in mvm and pcie.
      Do not move yet to 512 queues since there are some opens
      with enabling it.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      310181ec
    • E
      iwlwifi: mvm: tell the firmware about the U-APSD parameters · c80eb570
      Emmanuel Grumbach 提交于
      Newer firmware versions will be able to handle all the
      WMM-PS flows internally when we act as a GO. The firwmare
      relies on the fact that the drivers puts frames for
      different peers in different queues (DQA) to achieve this.
      The driver will not be aware of the power state of the peers
      anymore.
      
      Tell the firmware about the WMM-PS parameters of earch peer
      that connects to us so that it can know what are the
      trigger-enabled ACs, the delivery-enableds ACs and the
      Service Period length.
      
      This API change is backward compatible since older firmware
      versions will simply ignore the newly added values.
      
      Since we don't support ieee80211 TSPECs for now, just copy
      the trigger-enabled ACs to the delivery enabled ones.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c80eb570
    • S
      iwlwifi: mvm: support a000 SCD queue configuration · bb49701b
      Sara Sharon 提交于
      a000 devices queue management is going to change significantly.
      We will have 512 queues. Those queues will be assigned number
      by the firmware and not by the driver.
      
      In addition, due to SN offload having TX queue shared between TIDs
      is impossible
      
      Also, the ADD_STA command no longer updates queues status.
      The only point of changing queue in the SCD queue config API.
      
      From driver perspective we have here a new design:
      
      Queue sharing and inactivity checks are disabled.
      
      Once this is done, the only paths that call scd_queue_cfg command
      are paths that alloc and release TX queues - which will make future
      accommodation to queue number assignment by FW easier.
      Since allocating 512 queues statically is not advisable, transport
      will allocate the queue on demand, fill the command with DRAM data
      and send it. This is reflected in the new transport API.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      bb49701b
    • S
      iwlwifi: mvm: prepare for station count change · 0ae98812
      Sara Sharon 提交于
      In a000 devices we will support up to 32 stations.
      The max station define is used also for invalid station marking
      which makes finding usages of actual maximum station pretty hard
      to sort through - change it to be a different define in order
      to make future changes easier.
      Use also ARRAY_SIZE intead of define when possible.
      Do not move yet to 32 stations until firmware do it though.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      0ae98812
    • S
      iwlwifi: mvm: add queues after adding station · c5a719ee
      Sara Sharon 提交于
      Currently aux & broadcast queues are added before calling add
      station, which results with a SCD_QUEUE_CFG command sent with
      a station id unknown yet to fw.
      While this works for pre-a000 firmware, the a000 fw requires
      the order to be reversed.
      The reason the change is only for a000 devices and not for
      previous devices is that we cannot reverse the order since
      the tfd_queue_mask containing the aux queue will cause FW to
      assert on adding a queue mask with a queue that is not enabled.
      This is not a problem in a000 fw since the tfd_queue_mask was
      removed from the add sta API.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c5a719ee
  9. 11 4月, 2017 4 次提交
    • S
      iwlwifi: mvm: don't assume static queue numbers · 49f71713
      Sara Sharon 提交于
      In a000 devices FW will assign the queue number. Prepare for
      that by getting rid of static defines and store them in variables.
      Enlarge to u16 since we may have up to 512 queues.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      49f71713
    • S
      iwlwifi: mvm: support new ADD_MODIFY_STA_KEY command · 45c458b4
      Sara Sharon 提交于
      The command was changed to support PN offload and TKIP offload.
      The FW will do TKIP calculations in D0 only for a000 devices,
      but API is aligned anyway.
      However, for all devices we can stop sending the wowlan tkip
      command.
      Firmware will fetch the keys from the station key command.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      45c458b4
    • 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
  10. 24 3月, 2017 1 次提交
  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. 08 2月, 2017 1 次提交
  13. 07 2月, 2017 2 次提交
    • S
      iwlwifi: mvm: fix pending frame counter calculation · 94c3e614
      Sara Sharon 提交于
      In DQA mode the check whether to decrement the pending frames
      counter relies on the tid status and not on the txq id.
      This may result in an inconsistent state of the pending frames
      counter in case frame is queued on a non aggregation queue but
      with this TID, and will be followed by a failure to remove the
      station and later on SYSASSERT 0x3421 when trying to remove the
      MAC.
      Such frames are for example bar and qos NDPs.
      Fix it by aligning the condition of incrementing the counter
      with the condition of decrementing it - rely on TID state for
      DQA mode.
      Also, avoid internal error like this affecting station removal
      for DQA mode - since we can know for sure it is an internal
      error.
      
      Fixes: cf961e16 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      94c3e614
    • L
      iwlwifi: mvm: release static queues on bcast release · df88c08d
      Liad Kaufman 提交于
      A few of the static queues are enabled along with the bcast
      STA. Make sure they are removed along with it, rather than
      waiting for the mac ctxt release.
      
      This is needed because we sometimes have a STA being removed
      and then added again (either with the same sta_id or a
      different one). If we wait for the mac ctxt release we will
      try to allocate the queues again (as this is currently done
      in the STA allocation and not in the MAC init) although
      they weren't freed, and even if the sta_id of the STA has
      changed.
      Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      df88c08d
  14. 03 2月, 2017 1 次提交