1. 07 2月, 2017 1 次提交
    • 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
  2. 03 2月, 2017 2 次提交
  3. 26 1月, 2017 2 次提交
  4. 27 9月, 2016 1 次提交
  5. 23 9月, 2016 1 次提交
  6. 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
  7. 16 9月, 2016 3 次提交
  8. 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
  9. 30 8月, 2016 1 次提交
  10. 06 7月, 2016 6 次提交
  11. 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
  12. 11 5月, 2016 3 次提交
  13. 10 5月, 2016 2 次提交
  14. 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
  15. 12 4月, 2016 1 次提交
  16. 30 3月, 2016 4 次提交
  17. 10 3月, 2016 1 次提交
    • E
      iwlwifi: mvm: don't let NDPs mess the packet tracking · 532beba3
      Emmanuel Grumbach 提交于
      We need to track the next packet that we will reclaim in
      order to know when the Tx queues are empty. This is useful
      when we open or tear down an A-MPDU session which requires
      to switch queue.
      The next packet being reclaimed is identified by its WiFi
      sequence number and this is relevant only when we use QoS.
      QoS NDPs do have a TID but have a meaningless sequence
      number. The spec mandates the receiver to ignore the
      sequence number in this case, allowing the transmitter to
      put any sequence number. Our implementation leaves it 0.
      When we reclaim a QoS NDP, we can't update the next_relcaim
      counter since the sequence number of the QoS NDP itself is
      invalid.
      We used to update the next_reclaim based on the sequence
      number of the QoS NDP which reset it to 1 (0 + 1) and
      because of this, we never knew when the queue got empty.
      This had to sad consequence to stuck the A-MPDU state
      machine in a transient state.
      To fix this, don't update next_reclaim when we reclaim
      a QoS NDP.
      
      Alesya saw this bug when testing u-APSD. Because the
      A-MPDU state machine was stuck in EMPTYING_DELBA, we
      updated mac80211 that we still have frames for that
      station when it got back to sleep. mac80211 then wrongly
      set the TIM bit in the beacon and requested to release
      non-existent frames from the A-MPDU queue. This led to
      a situation where the client was trying to poll frames
      but we had no frames to send.
      Reported-by: NAlesya Shapira <alesya.shapira@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      532beba3
  18. 28 2月, 2016 5 次提交
  19. 24 2月, 2016 1 次提交
    • E
      iwlwifi: mvm: move TX PN assignment for TKIP to the driver · 1ad4f639
      Eliad Peller 提交于
      If protocol offloading is configured, the fw might generate some
      frames (e.g. arp response) on its own during d3/d0i3.
      
      On d3/d0i3 exit the driver queries the updated PN (if relevant),
      and updates its keys (for the d0i3 case, this is done by
      iwl_mvm_d0i3_exit_work(), which is scheduled on d0i3 exit)
      
      While in d0i3, iwlmvm defers tx frames until d0i3 exit, and
      then continues their processing.
      
      This is problematic with TKIP, since the frame's PN has already
      been set at this stage (in contrast to CCMP, where the PN is
      being set only later on), so both the frame's PN and the upcoming
      PN update (from d0i3 exit work) might be wrong.
      
      Fix it by moving the TX PN assignment (for TKIP) to the driver,
      similarly to CCMP.
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1ad4f639
  20. 16 2月, 2016 1 次提交
    • L
      iwlwifi: mvm: inc pending frames counter also when txing non-sta · fb896c44
      Liad Kaufman 提交于
      Until this patch, when TXing non-sta the pending_frames counter
      wasn't increased, but it WAS decreased in
      iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain
      conditions. This in turn caused much trouble when we need to
      remove the station since we won't be waiting forever until
      pending_frames gets 0. In certain cases, we were exhausting
      the station table even in BSS mode, because we had a lot of
      stale stations.
      
      Increase the counter also in iwl_mvm_tx_skb_non_sta() after a
      successful TX to avoid this outcome.
      
      CC: <stable@vger.kernel.org> [3.18+]
      Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      fb896c44
  21. 01 2月, 2016 1 次提交