1. 29 4月, 2019 1 次提交
  2. 03 4月, 2019 1 次提交
  3. 22 3月, 2019 1 次提交
  4. 14 2月, 2019 5 次提交
  5. 04 2月, 2019 3 次提交
  6. 29 1月, 2019 3 次提交
  7. 26 1月, 2019 1 次提交
  8. 20 12月, 2018 1 次提交
  9. 14 12月, 2018 2 次提交
  10. 23 11月, 2018 4 次提交
  11. 11 11月, 2018 3 次提交
  12. 08 10月, 2018 1 次提交
    • S
      iwlwifi: dump debug data before stop device · 4244e7fc
      Shahar S Matityahu 提交于
      Debug data dump is not working in flows that stop the device is used
      in their error handling. During these flows the op mode mutex is
      locked until the device stops.  Because of that, any assert generated
      from the firmware can be handled only after the device already
      stopped.
      
      Since dumping cannot occour after stopping the device, split the the
      dump function to two parts, Part that handles locking, and the part
      that starts the actual dumping and call the second part in the op mode
      stop device function.
      Signed-off-by: NShahar S Matityahu <shahar.s.matityahu@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      4244e7fc
  13. 06 10月, 2018 6 次提交
  14. 28 9月, 2018 2 次提交
  15. 31 8月, 2018 3 次提交
  16. 20 4月, 2018 1 次提交
  17. 02 3月, 2018 1 次提交
  18. 25 11月, 2017 1 次提交
    • S
      iwlwifi: fix access to prph when transport is stopped · 0232d2cd
      Sara Sharon 提交于
      When getting HW rfkill we get stop_device being called from
      two paths.
      One path is the IRQ calling stop device, and updating op
      mode and stack.
      As a result, cfg80211 is running rfkill sync work that shuts
      down all devices (second path).
      In the second path, we eventually get to iwl_mvm_stop_device
      which calls iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording,
      that access periphery registers.
      The device may be stopped at this point from the first path,
      which will result with a failure to access those registers.
      Simply checking for the trans status is insufficient, since
      the race will still exist, only minimized.
      Instead, move the stop from iwl_fw_dump_conf_clear (which is
      getting called only from stop path) to the transport stop
      device function, where the access is always safe.
      This has the added value, of actually stopping dbgc before
      stopping device even when the stop is initiated from the
      transport.
      
      Fixes: 1efc3843 ("iwlwifi: stop dbgc recording before stopping DMA")
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      0232d2cd