1. 20 4月, 2017 1 次提交
  2. 11 4月, 2017 2 次提交
    • 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: 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
  3. 24 3月, 2017 1 次提交
  4. 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
  5. 08 2月, 2017 2 次提交
    • E
      iwlwifi: mvm: use the PROBE_RESP_QUEUE to send deauth to unknown station · d45cb20e
      Emmanuel Grumbach 提交于
      When we send a deauth to a station we don't know about, we
      need to use the PROBE_RESP queue. This can happen when we
      send a deauth to a station that is not associated to us.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      d45cb20e
    • S
      iwlwifi: mvm: fix references to first_agg_queue in DQA mode · c56108b5
      Sara Sharon 提交于
      In DQA mode, first_agg_queue is initialized to
      IWL_MVM_DQA_MIN_DATA_QUEUE. This causes two bugs in the tx response
      flow:
      
      1. When TX fails, we set IEEE80211_TX_STAT_AMPDU_NO_BACK regardless
         if we actually have aggregation open on the queue. This causes
         mac80211 to send a BAR frame even though there is no aggregation
         open.
         Fix that by simply checking the AMPDU flag that is set on by
         mac80211 for AMPDU packets.
      
      2. When reclaiming frames in aggregation mode, we reclaim based on
         scheduler ssn and not the SN.
         The reason is that scheduler ssn may be ahead of SN due to a hole
         in the BA window that was filled.
         However, if we have aggregations open on IWL_MVM_DQA_BSS_CLIENT_QUEUE
         the reclaim flow will still go to the code of non-aggregation
         instead of the aggregation code since IWL_MVM_DQA_BSS_CLIENT_QUEUE
         is smaller than IWL_MVM_DQA_MIN_DATA_QUEUE, although it is a valid
         aggregation queue.
         Fix that by always using the aggregation reclaim code by default in
         DQA mode (currently it is implicitly used by default for all queues
         except the reserved BSS queue).
      
      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>
      c56108b5
  6. 07 2月, 2017 4 次提交
    • S
      iwlwifi: mvm: cleanup iwl_mvm_tx_mpdu a bit · 0d7f1b99
      Sara Sharon 提交于
      Unify code, remove redundant assignments.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      0d7f1b99
    • 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
    • J
      iwlwifi: mvm/pcie: adjust A-MSDU tx_cmd length in PCIe · 05e5a7e5
      Johannes Berg 提交于
      Instead of setting the tx_cmd length in the mvm code, which is
      complicated by the fact that DQA may want to temporarily store
      the SKB on the side, adjust the length in the PCIe code which
      also knows about this since it's responsible for duplicating
      all those headers that are account for in this code.
      
      As the PCIe code already relies on the tx_cmd->len field, this
      doesn't really introduce any new dependencies.
      
      To make this possible we need to move the memcpy() of the TX
      command until after it was updated.
      
      This does even simplify the code though, since the PCIe code
      already does a lot of manipulations to build A-MSDUs correctly
      and changing the length becomes a simple operation to see how
      much was added/removed, rather than predicting it.
      
      Fixes: 24afba76 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      05e5a7e5
    • J
      iwlwifi: mvm: overwrite skb info later · bd05a5bd
      Johannes Berg 提交于
      We don't really need clear the skb's status area nor store the
      dev_cmd into it until we really commit to the frame by handing
      it to the transport - defer those operations until just before
      we do that.
      
      This doesn't entirely fix the bug with frames not getting sent
      out after having been deferred due to DQA, because it doesn't
      restore the info->driver_data[0] place that was already set to
      zero (or another value) by the A-MSDU logic.
      
      Fixes: 24afba76 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of queues")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      bd05a5bd
  7. 03 2月, 2017 2 次提交
  8. 26 1月, 2017 2 次提交
  9. 27 9月, 2016 1 次提交
  10. 23 9月, 2016 1 次提交
  11. 19 9月, 2016 1 次提交
    • S
      iwlwifi: mvm: fix DQA AP mode station assumption · 3ee0f0e2
      Sara Sharon 提交于
      There was recently a Full AP mode feature added where hostap adds
      the station at auth stage, and not assoc.
      However, when running with legacy hostapd, we get the auth response
      before station was added, and tx_skb_non_sta fails to allocate
      a queue, resulting in a complete failure of association.
      Take care of this situation as well.
      Add a warning when no valid queue is returned at all and make mvm
      drop the packet instead of passing it on.
      Refactor the function a bit while at it.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      3ee0f0e2
  12. 16 9月, 2016 3 次提交
  13. 15 9月, 2016 1 次提交
    • B
      iwlwifi: mvm: update TX queue before making a copy of the skb · 54c5ef2e
      Beni Lev 提交于
      Off-channel action frames (such as ANQP frames) must be sent either on
      the AUX queue or on the offchannel queue, otherwise the firmware will
      cause a SYSASSERT.
      
      In the current implementation, the queue to be used is correctly set in
      the original skb, but this is done after it is copied.  Thus the copy
      remains with the original, incorrect queue.
      
      Fix this by setting the queue in the original skb before copying it.
      
      Fixes: commit 5c08b0f5 ("iwlwifi: mvm: don't override the rate with the AMSDU len")
      Cc: stable@vger.kernel.org # v4.6+
      Signed-off-by: NBeni Lev <beni.lev@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      54c5ef2e
  14. 30 8月, 2016 1 次提交
  15. 06 7月, 2016 6 次提交
  16. 19 5月, 2016 1 次提交
    • L
      iwlwifi: fix mis-merge that breaks the driver · 0e034f5c
      Linus Torvalds 提交于
      My laptop that uses the intel 7680 iwlwifi module would no longer
      connects to the network.  It would fail with a "Microcode SW error
      detected." and spew out register state over and over again without ever
      connecting to the network.
      
      The cause is mis-merge in commit 909b27f7, where David seems to have
      lost some of the changes to iwl_mvm_set_tx_cmd() from commit
      5c08b0f5 ("iwlwifi: mvm: don't override the rate with the AMSDU
      len").
      
      The reason seems to be a conflict with commit d8fe4844 ("iwlwifi:
      mvm: add support for new TX CMD API"), which touched a line adjacent to
      the changes in 909b27f7.
      
      David missed the fact that "info->driver_data[0]" had become
      "skb_info->driver_data[0]".  Then he removed the skb_info because it was
      unused.
      
      This just re-updates iwl_mvm_set_tx_cmd() with the lost two lines.
      Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: NReinoud Koornstra <reinoudkoornstra@gmail.com>
      Cc: Luciano Coelho <luciano.coelho@intel.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0e034f5c
  17. 11 5月, 2016 3 次提交
  18. 10 5月, 2016 2 次提交
  19. 05 5月, 2016 1 次提交
    • E
      iwlwifi: mvm: don't override the rate with the AMSDU len · 5c08b0f5
      Emmanuel Grumbach 提交于
      The TSO code creates A-MSDUs from a single large send. Each
      A-MSDU is an skb and skb->len doesn't include the number of
      bytes which need to be added for the headers being added
      (subframe header, TCP header, IP header, SNAP, padding).
      
      To be able to set the right value in the Tx command, we
      put the number of bytes added by those headers in
      driver_data in iwl_mvm_tx_tso and use this value in
      iwl_mvm_set_tx_cmd.
      
      The problem by setting this value in driver_data is that
      it overrides the ieee80211_tx_info. The bug manifested
      itself when we send P2P related frames in CCK since the
      rate in ieee80211_tx_info is zero-ed. This of course is
      a violation of the P2P specification.
      
      To fix this, copy the original ieee80211_tx_info to the
      stack and pass it to the functions which need it.
      Assign the number of bytes added by the headers to the
      driver_data inside the skb itself.
      
      Fixes: a6d5e32f ("iwlwifi: mvm: send large SKBs to the transport")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      5c08b0f5
  20. 12 4月, 2016 1 次提交
  21. 30 3月, 2016 3 次提交