1. 12 1月, 2017 4 次提交
  2. 29 11月, 2016 1 次提交
    • B
      mwifiex: pcie: implement timeout loop for FW programming doorbell · 22dde1ed
      Brian Norris 提交于
      Marvell Wifi PCIe modules don't always behave nicely for PCIe power
      management when their firmware hasn't been loaded, particularly after
      suspending the PCIe link one or more times. When this happens, we might
      end up spinning forever in this status-polling tight loop. Let's make
      this less tight by adding a timeout and by sleeping a bit in between
      reads, as we do with the other similar loops.
      
      This prevents us from hogging a CPU even in such pathological cases, and
      allows the FW initialization to just fail gracefully instead.
      
      I chose the same polling parameters as the earlier loop in this
      function, and empirically, I found that this loop never makes it more
      than about 12 cycles in a sane FW init sequence. I had no official
      information on the actual intended latency for this portion of the
      download.
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Acked-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      22dde1ed
  3. 25 11月, 2016 1 次提交
  4. 19 11月, 2016 11 次提交
  5. 18 11月, 2016 1 次提交
    • B
      mwifiex: don't do unbalanced free()'ing in cleanup_if() · 66b9c182
      Brian Norris 提交于
      The cleanup_if() callback is the inverse of init_if(). We allocate our
      'card' interface structure in the probe() function, but we free it in
      cleanup_if(). That gives a few problems:
      (a) we leak this memory if probe() fails before we reach init_if()
      (b) we can't safely utilize 'card' after cleanup_if() -- namely, in
          remove() or suspend(), both of which might race with the cleanup
          paths in our asynchronous FW initialization path
      
      Solution: just use devm_kzalloc(), which will free this structure
      properly when the device is removed -- and drop the set_drvdata(...,
      NULL), since the driver core does this for us. This also removes the
      temptation to use drvdata == NULL as a hack for checking if the device
      has been "cleaned up."
      
      I *do* leave the set_drvdata(..., NULL) for the hacky SDIO
      mwifiex_recreate_adapter(), since the device core won't be able to clear
      that one for us.
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      66b9c182
  6. 09 11月, 2016 2 次提交
    • A
      mwifiex: report error to PCIe for suspend failure · 5190f2e4
      Amitkumar Karwar 提交于
      When host_sleep_config command fails, we should return an error to
      PCIe, instead of continuing (and possibly panicking, when we try to keep
      processing a timed-out ioctl after we return "successfully" from
      suspend).
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      5190f2e4
    • A
      mwifiex: prevent register accesses after host is sleeping · ec815dd2
      Amitkumar Karwar 提交于
      Following is mwifiex driver-firmware host sleep handshake.
      It involves three threads. suspend handler, interrupt handler, interrupt
      processing in main work queue.
      
      1) Enter suspend handler
      2) Download HS_CFG command
      3) Response from firmware for HS_CFG
      4) Suspend thread waits until handshake completes(i.e hs_activate becomes
         true)
      5) SLEEP from firmware
      6) SLEEP confirm downloaded to firmware.
      7) SLEEP confirm response from firmware
      8) Driver processes SLEEP confirm response and set hs_activate to wake up
      suspend thread
      9) Exit suspend handler
      10) Read sleep cookie in loop and wait until it indicates firmware is
      sleep.
      11) After processing SLEEP confirm response, we are at the end of interrupt
      processing routine. Recheck if there are interrupts received while we were
      processing them.
      
      During suspend-resume stress test, it's been observed that we may end up
      acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
      to a kernel crash.
      
      This patch solves the problem with below changes.
      a) action 10 above can be done before 8
      b) Skip 11 if hs_activated is true. SLEEP confirm response
      is the last interrupt from firmware. No need to recheck for
      pending interrupts.
      c) Add flush_workqueue() in suspend handler.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Tested-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ec815dd2
  7. 09 9月, 2016 3 次提交
  8. 04 9月, 2016 3 次提交
  9. 19 7月, 2016 3 次提交
  10. 08 7月, 2016 3 次提交
  11. 14 6月, 2016 2 次提交
  12. 04 6月, 2016 1 次提交
  13. 14 4月, 2016 3 次提交
  14. 08 4月, 2016 2 次提交