1. 21 12月, 2015 4 次提交
  2. 20 12月, 2015 1 次提交
  3. 13 12月, 2015 3 次提交
  4. 18 11月, 2015 1 次提交
  5. 16 11月, 2015 2 次提交
    • A
      iwlwifi: mvm: Avoid dereferencing sta if it was already flushed · 9513c5e1
      Avri Altman 提交于
      Be a little bit more careful when dereferencing sta on key removal,
      As it might already get flushed on other thread.
      Signed-off-by: NAvri Altman <avri.altman@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      9513c5e1
    • L
      iwlwifi: mvm: don't overwrite the key indices in D3 entry · d6ee54a9
      Luca Coelho 提交于
      When entering D3, we need to use hardcoded key indices because the
      firmware requires that.  To do so, we are overwriting the HW key index
      in the keyconf structure, which makes it impossible to reuse the
      indices that were used before entering D3.  Additionally, we overwrite
      all the non-PTK keys with index 1, because the firmware only allows
      one non-PTK key to be set.  This is bad, because when we resume, we
      may try to set more than one key with index 1, which will obviously
      fail.
      
      To fix this, allow the callers to set a pre-defined index to use in
      iwl_mvm_set_sta_key() instead of relying on the hw_key_idx value from
      the keyconf struct (which requires overwriting it).  In normal cases,
      the caller can pass STA_KEY_IDX_INVALID, which will cause a new key
      offset to be chosen.  During HW_RESTART, we pass the offset that is in
      use.  And during D3 entry, we pass the hardcoded indices we need to
      use.
      
      Additionally, don't clear the fw_key_table in D3 entry, so that the
      flags are still set with the pre-D3 values when exiting D3.
      
      fixes=I3165c22362483f0152d9ec1d2a987fb5529727c1
      
      Fixes: b546dcd6 ("iwlwifi: mvm: don't reset key index on HW restart")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      d6ee54a9
  6. 25 10月, 2015 2 次提交
  7. 05 10月, 2015 4 次提交
  8. 28 8月, 2015 1 次提交
  9. 13 8月, 2015 1 次提交
  10. 04 8月, 2015 2 次提交
  11. 26 6月, 2015 1 次提交
  12. 28 5月, 2015 1 次提交
  13. 02 4月, 2015 1 次提交
  14. 30 3月, 2015 1 次提交
  15. 18 3月, 2015 1 次提交
    • E
      iwlwifi: mvm: properly flush the queues for buffering transport · fe92e32a
      Emmanuel Grumbach 提交于
      There are transport that must buffer frames in the driver.
      This means that we have frames that are not in the op_mode
      and not visible to the firwmare. This causes issues when we
      flush the queues: the op_mode flushes a queue, and the
      firmware flushes all the frames that are *currently* on the
      rings, but if the transport buffers frames, it can submit
      these while we are flushing. This leads to a situation
      where we still have frames on the queues after we flushed
      them.
      Preventing those buffered frame from getting into the
      firmware is possible, but then, we have to run the Tx
      response path on frames that didn't reach the firmware
      which is not desirable.
      The way I solve this here is to let these frames go to the
      firmware, but make sure the firmware will not transmit them
      (by setting the station as draining). The op_mode then needs
      to wait until the transport itself is empty to be sure that
      the queue is really empty.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      fe92e32a
  16. 12 3月, 2015 2 次提交
  17. 01 2月, 2015 1 次提交
  18. 22 1月, 2015 3 次提交
  19. 29 12月, 2014 2 次提交
  20. 24 11月, 2014 5 次提交
  21. 11 11月, 2014 1 次提交