1. 18 11月, 2015 1 次提交
  2. 25 10月, 2015 1 次提交
  3. 05 10月, 2015 1 次提交
  4. 28 8月, 2015 2 次提交
  5. 23 8月, 2015 1 次提交
  6. 16 8月, 2015 1 次提交
  7. 05 8月, 2015 1 次提交
  8. 03 6月, 2015 1 次提交
    • J
      iwlwifi: prepare for higher API/CAPA bits · 859d914c
      Johannes Berg 提交于
      Currently, loading the firmware fails when it has higher API or CAPA
      bits than the driver supports. That's an issue with integration.
      
      At the same time, actually using api[0] and capa[0] will become
      confusing when we also have api[1] and capa[1], and it's almost
      certain that we'll mix up the bits and use the bits for api[1] with
      api[0] by accident.
      
      Avoid all this by translating the API/CAPA bits to the regular kernel
      test_bit() format, and also providing wrapper functions. Also use the
      __bitwise__ facility of sparse to check that we're testing the right
      one.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      859d914c
  9. 27 5月, 2015 1 次提交
    • E
      iwlwifi: mvm: fix ROC reference accounting · c779273b
      Eliad Peller 提交于
      commit b112889c ("iwlwifi: mvm: add Aux ROC request/response flow")
      added aux ROC flow in addition to the existing ROC flow. While doing
      it, it moved the ROC reference release to a common work item, which
      is being called for both the ROC and aux ROC flows.
      
      This resulted in invalid reference accounting, as no reference was
      taken in case of aux ROC, while a reference was released on completion.
      
      Fix it by adding a reference for the aux ROC as well, and release
      only the relevant references on completion (according to the set bits).
      
      While at it, convert cancel_work_sync() to flush_work(), in order
      to make sure the references are being cleaned properly.
      
      Fixes: b112889c ("iwlwifi: mvm: add Aux ROC request/response flow")
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      c779273b
  10. 02 4月, 2015 1 次提交
  11. 26 3月, 2015 1 次提交
  12. 12 3月, 2015 1 次提交
  13. 02 3月, 2015 2 次提交
    • E
      iwlwifi: mvm: add the cause of the firmware dump in the dump · b6eaa45a
      Emmanuel Grumbach 提交于
      Now that the firmware dump can be triggered by events in
      the code and not only the user or an firmware ASSERT, we
      need a way to know why the firmware dump was triggered.
      Add a section in the dump file for that.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      b6eaa45a
    • E
      iwlwifi: mvm: add framework for triggers for fw dump · d2709ad7
      Emmanuel Grumbach 提交于
      Most of the time, the issues we want to debug with the
      firmware dump mechanism are transient. It is then very
      hard to stop the recording on time and get meaningful
      data.
      In order to solve this, I add here an infrastucture
      of triggers. The user will supply a list of triggers
      that will start / stop the recording. We have two types
      of triggers: start and stop. Start triggers can start a
      specific configuration. The stop triggers will be able to
      kick the collection of the data with the currently running
      configuration. These triggers are given to the driver by
      the .ucode file - just like the configuration.
      
      In the next patches, I'll add triggers in the code.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      d2709ad7
  14. 22 1月, 2015 4 次提交
  15. 29 12月, 2014 2 次提交
  16. 01 12月, 2014 1 次提交
  17. 24 11月, 2014 2 次提交
  18. 29 10月, 2014 2 次提交
  19. 16 9月, 2014 1 次提交
  20. 14 9月, 2014 2 次提交
  21. 04 9月, 2014 5 次提交
  22. 23 7月, 2014 2 次提交
  23. 21 7月, 2014 1 次提交
  24. 08 7月, 2014 3 次提交