1. 30 6月, 2017 9 次提交
    • J
      iwlwifi: mvm: remove DQA non-STA client mode special case · 6e464963
      Johannes Berg 提交于
      When we get a non-STA frame to transmit in client mode, we try to use
      the IWL_MVM_DQA_BSS_CLIENT_QUEUE queue (queue #4). However, at this
      point, the queue might not be allocated at all, causing warnings. The
      scenario on which this happened was a race condition between mac80211
      and our queue allocation work:
       * mac80211 sends auth
       * we stop mac80211 queues to allocate a hw queue
       * authentication is aborted
       * we allocate HW queue and start mac80211 queues
       * mac80211 removes station
       * mac80211 hands us the auth frame from the pending queue
      
      At this point, since mac80211 has already removed the station, we try
      to transmit the frame through this special non-station case on queue
      4 anyway.
      
      In order to really use it properly, we'd have to again go through the
      hw queue allocation work, and attach it to a station, etc. In this
      case that isn't possible (there's no station anymore), but if this
      special case were needed, then we'd have to do it this way.
      
      However, the special case is documented to exist for TDLS, but can't
      trigger there because the TDLS setup frames etc. are normal to-DS
      frames going to the peer through the AP. Testing also confirms that
      this code path isn't triggered in TDLS.
      
      Therefore, remove the code path to avoid using an unused queue. The
      erroneous frame described above will still be transmitted on the AUX
      queue, but arguably that's a mac80211 problem, which will eventually
      be fixed by moving everything there to TXQs.
      
      Fixes: e3118ad7 ("iwlwifi: mvm: support tdls in dqa mode")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      6e464963
    • E
      iwlwifi: mvm: don't mess the SNAP header in TSO for non-QoS packets · 6344436e
      Emmanuel Grumbach 提交于
      When we get large sends on non-QoS association, we had a
      bug that mangled the SNAP header. Fix that.
      
      Fixes: a6d5e32f ("iwlwifi: mvm: send large SKBs to the transport")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      6344436e
    • J
      iwlwifi: pcie: reconfigure MSI-X HW on resume · 52848a79
      Johannes Berg 提交于
      When going into suspend, the HW configuration for MSI-X will
      likely be lost. As a consequence, after waking up, all IRQ
      causes will be mapped to interrupt 0, and as a consequence we
      don't notice the interrupt because in most cases this is an
      interrupt for a queue, and getting it doesn't read the other
      cause registers.
      
      Fixes: 2e5d4a8f ("iwlwifi: pcie: Add new configuration to enable MSIX")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      52848a79
    • E
      iwlwifi: mvm: don't send fetch the TID from a non-QoS packet in TSO · 4f555e60
      Emmanuel Grumbach 提交于
      Getting the TID of a packet before we know it is a QoS data
      packet isn't a good idea. Delay the TID retrieval until
      we know the packet is a QoS data packet.
      
      Fixes: bb81bb68 ("iwlwifi: mvm: add Tx A-MSDU inside A-MPDU")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      4f555e60
    • J
      iwlwifi: mvm: fix mac80211's hw_queue in DQA mode · 32026e8f
      Johannes Berg 提交于
      When in non-DQA mode, mac80211 actually gets a pretty much perfect
      idea (in vif->hw_queue/cab_queue) of which queues we're using. But
      in DQA mode, this isn't true - nonetheless, we were adding all the
      queues, even the ones stations are using, to the queue allocation
      bitmap.
      
      Fix this, we should only add the queues we really are using in DQA
      mode:
       * IWL_MVM_OFFCHANNEL_QUEUE, as we use this in both modes
       * mvm->aux_queue, as we use this in both modes - mac80211
         never really knows about it but we use it as a cookie
         internally, so can't reuse it
       * possibly the GCAST queue (cab_queue)
       * all the "queues" we told mac80211 about we were using on each
         interface (vif->hw_queue), these are entirely virtual in this
         mode
      
      Also add back the failure now when we can't allocate any more of
      these - now virtual - queues; this was skipped in DQA mode and
      would lead to having multiple ACs or even interfaces use the same
      queue number in mac80211 (10, since that's the limit), which would
      stop far too many queues if stopped.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      32026e8f
    • J
      iwlwifi: mvm: map cab_queue to real one earlier · b0129db4
      Johannes Berg 提交于
      There may be a difference between the mac80211 vif->cab_queue and
      mvmvif->cab_queue, particularly with TVQM. Make the code map this
      earlier, instead of first returning the mac80211 one again from
      iwl_mvm_get_ctrl_vif_queue().
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      b0129db4
    • J
      iwlwifi: mvm: fix mac80211 queue tracking · 37e474ac
      Johannes Berg 提交于
      In the driver, we track which hardware queue is associated with
      which mac80211 "hw_queue", in order to be able to stop and wake
      it. When moving these bitmaps out of the queue_info structures,
      the type of the bitmap was erroneously changed from u32 to u8,
      presumably in order to save memory.
      
      Turns out that u32 isn't needed, because the highest queue we
      can ever tell mac80211 is always < 16, but a u16 definitely is
      needed, queues >=8 do happen.
      
      While at it, throw a BUILD_BUG_ON() into the place where we set
      the limit (mvm->first_agg_queue) and a warning when it actually
      gets put into the bitmap.
      
      The consequence of this bug is that full HW queues associated
      with such a too-high mac80211 number never stop higher layer
      queues when full, and thus would simply drop all packets that
      couldn't be enqueued to the hardware queue.
      
      Fixes: 34e10860 ("iwlwifi: mvm: remove references to queue_info in new TX path")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      37e474ac
    • J
      iwlwifi: mvm: properly enable IP header checksumming · 275896ab
      Johannes Berg 提交于
      The code was intended to enable IP header checksumming on AMSDUs, but
      failed to really do so because the A-MSDU bit was set after all the
      checksumming bits, and thus checking for A-MSDU could never be true.
      
      Fix this by setting the A-MSDU bit before the offload bits.
      
      Fixes: 5e6a98dc ("iwlwifi: mvm: enable TCP/UDP checksum support for 9000 family")
      Reported-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      275896ab
    • J
      iwlwifi: pcie: add MSI-X interrupt tracing · c42ff65d
      Johannes Berg 提交于
      We have tracing for both pre-ICT and ICT interrupts, including all
      the data read there. Extend the tracing to MSI-X interrupts.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c42ff65d
  2. 29 6月, 2017 31 次提交