1. 29 1月, 2019 9 次提交
  2. 26 1月, 2019 2 次提交
    • S
      iwlwifi: mvm: support mac80211 AMSDU · 438af969
      Sara Sharon 提交于
      Support getting mac80211 building AMSDUs for us. Remove GSO
      support from mvm - we don't need it anymore.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      438af969
    • S
      iwlwifi: mvm: support mac80211 TXQs model · cfbc6c4c
      Sara Sharon 提交于
      Move to use the new mac80211 TXQs implementation. This has
      quite a few benefits for us. We can get rid of the awkward
      mapping of DQA to mac80211 queues. We can stop buffering
      traffic while waiting for the queue to be allocated. We can
      also use mac80211 AMSDUs instead of building it ourselves.
      
      The usage is pretty simple:
      Each ieee80211_txq contains iwl_mvm_txq. There is such a
      queue for each TID, and one for management frames. We keep
      having static AP queues for probes and non-bufferable MMPDUs,
      along with broadcast and multicast queues. Those are being
      used from the "old" TX invocation path - iwl_mvm_mac_tx.
      
      When there is a new frame in a TXQ, iwl_mvm_mac_wake_tx is
      being called, and either invokes the TX path, or allocates
      the queue if it does not exist.
      
      Most of the TX path is left untouched, although we can consider
      cleaning it up some more, for example get rid of the duplication
      of txq_id in both iwl_mvm_txq and iwl_mvm_dqa_txq_info.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      cfbc6c4c
  3. 20 12月, 2018 1 次提交
  4. 11 11月, 2018 3 次提交
  5. 08 10月, 2018 7 次提交
  6. 28 9月, 2018 2 次提交
  7. 31 8月, 2018 6 次提交
  8. 26 7月, 2018 1 次提交
  9. 20 4月, 2018 5 次提交
  10. 29 3月, 2018 3 次提交
  11. 19 3月, 2018 1 次提交
    • A
      iwlwifi: mvm: Increase session protection time after CS · 19125cb0
      Andrei Otcheretianski 提交于
      After switching to a new channel, driver schedules session protection
      time event in order to hear the beacon on the new channel.
      The duration of the protection is two beacon intervals.
      However, since we start to switch slightly before beacon with count 1, in
      case we don't hear (or AP doesn't transmit) the very first beacon on the
      new channel the protection ends without hearing any beacon at all.
      At this stage the switch is not complete, the queues are closed and the
      interface doesn't have quota yet or TBTT events. As the result, we are
      stuck forever waiting for iwl_mvm_post_channel_switch() to be called.
      
      Fix this by increasing the protection time to be 3 beacon intervals and
      in addition drop the connection if the time event ends before we got any
      beacon.
      Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      19125cb0