1. 11 10月, 2013 1 次提交
  2. 27 9月, 2013 1 次提交
  3. 23 5月, 2013 1 次提交
  4. 09 5月, 2013 1 次提交
    • B
      mwifiex: clear is_suspended flag when interrupt is received early · 48795424
      Bing Zhao 提交于
      When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN
      mwifiex is often flooded with "not allowed while suspended" messages
      and the interface is unusable.
      
      [  202.171609] int: sdio_ireg = 0x1
      [  202.180700] info: mwifiex_process_hs_config: auto cancelling host
                     sleep since there is interrupt from the firmware
      [  202.201880] event: wakeup device...
      [  202.211452] event: hs_deactivated
      [  202.514638] info: --- Rx: Data packet ---
      [  202.514753] data: 4294957544 BSS(0-0): Data <= kernel
      [  202.514825] PREP_CMD: device in suspended state
      [  202.514839] data: dequeuing the packet ec7248c0 ec4869c0
      [  202.514886] mwifiex_write_data_sync: not allowed while suspended
      [  202.514886] host_to_card, write iomem (1) failed: -1
      [  202.514917] mwifiex_write_data_sync: not allowed while suspended
      [  202.514936] host_to_card, write iomem (2) failed: -1
      [  202.514949] mwifiex_write_data_sync: not allowed while suspended
      [  202.514965] host_to_card, write iomem (3) failed: -1
      [  202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF
      
      This can be readily reproduced when putting the XO-4 in a loop where
      it goes to sleep due to inactivity, but then wakes up due to an
      incoming ping. The error is hit within an hour or two.
      
      This issue happens when an interrupt comes in early while host sleep
      is still activated. Driver handles this case by auto cancelling host
      sleep. However is_suspended flag is still set which prevents any cmd
      or data from being sent to firmware. Fix it by clearing is_suspended
      flag in this path.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NDaniel Drake <dsd@laptop.org>
      Tested-by: NDaniel Drake <dsd@laptop.org>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      48795424
  5. 23 4月, 2013 1 次提交
  6. 09 4月, 2013 1 次提交
    • B
      mwifiex: fix negative cmd_pending count · 9908b074
      Bing Zhao 提交于
      cmd_pending is increased in mwifiex_wait_queue_complete() and
      decreased in mwifiex_complete_cmd() currently.
      If there are two or more commands in the cmd_pending_q the main
      worker thread will pick up next command from cmd_pending_q
      automatically after finishing current command. As a result
      mwifiex_wait_queue_complete() will not be called because
      the command is alreay completed. This leads to a negative
      number in cmd_pending count.
      
      Fix it by increasing cmd_pending when a cmd is queued into
      cmd_pending_q and decreasing when that cmd is recycled. For scan
      commands we don't perform inc/dec operations until it's moved
      from scan_pending_q to cmd_pending_q. This covers both
      synchronous and asynchronous commands.
      Reported-by: NDaniel Drake <dsd@laptop.org>
      Tested-by: NDaniel Drake <dsd@laptop.org>
      Tested-by: NMarco Cesarano <marco@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9908b074
  7. 19 3月, 2013 2 次提交
  8. 07 3月, 2013 1 次提交
  9. 19 2月, 2013 1 次提交
  10. 05 2月, 2013 1 次提交
  11. 17 11月, 2012 1 次提交
  12. 15 11月, 2012 1 次提交
  13. 20 10月, 2012 2 次提交
  14. 29 9月, 2012 1 次提交
  15. 06 9月, 2012 1 次提交
  16. 07 8月, 2012 1 次提交
  17. 29 6月, 2012 1 次提交
    • A
      mwifiex: wakeup main thread to handle command queued · 1a1fb970
      Amitkumar Karwar 提交于
      We miss to wakeup main thread after adding command to cmd pending
      queue at follwing places. These commands are handled later when
      main thread is woken up for handling an interrupt for sleep event
      from firmware. This adds worst case delay of 50msec.
      
      1) We don't wakeup main thread when asynchronous command is added
      to cmd pending queue. Move queue_work() call from
      mwifiex_wait_queue_complete() to mwifiex_send_cmd_async() to wakeup
      main thread for sync as well as async commands.
      
      2) Scan operation is triggered due to following reasons
         a) request from user (ex. "iw scan" command)
         b) Scan performed by driver internally.
         In first case main thread is woken up when first scan command is
      queued in cmd pending queue (we don't need to wakeup main thread for
      subsequent scan commands, because they are queued in scan command
      response handler), but it is not done for second case. queue_work()
      is moved inside mwifiex_scan_networks() to handle both the cases.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NAvinash Patil <patila@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1a1fb970
  18. 23 6月, 2012 1 次提交
  19. 17 5月, 2012 2 次提交
  20. 24 4月, 2012 1 次提交
  21. 15 3月, 2012 1 次提交
  22. 06 3月, 2012 1 次提交
  23. 25 1月, 2012 1 次提交
  24. 15 12月, 2011 1 次提交
  25. 15 10月, 2011 1 次提交
    • A
      mwifiex: use separate wait condition for each command node · efaaa8b8
      Amitkumar Karwar 提交于
      Currently global wait condition (adapter->cmd_wait_q.condition)
      is used while sending synchronous commands to FW. When two threads
      enter in mwifiex_send_cmd_sync() routine at the same time, both the
      threads wait for their command responses. Since wait condition is
      same for both, they wake up simultaneously after getting response
      of 1st command. After this when a thread is waiting for command
      response of 3rd command, it wakes up after getting response of 2nd
      command and so on. Therefore we don't wait for the response of last
      command(0xaa) during unload. Hence while next time loading the driver
      command time out is seen for INIT command.
      
      This problem is resolved by having separate wait condition flag for
      each command(except scan command). Since scan command is treated
      differently (by maintaining scan pending q etc.), newly defined flag
      (scan_wait_q_woken) is used as a scan wait condition.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      efaaa8b8
  26. 13 10月, 2011 1 次提交
  27. 28 9月, 2011 1 次提交
  28. 23 6月, 2011 1 次提交
  29. 13 5月, 2011 1 次提交
  30. 11 5月, 2011 2 次提交
  31. 06 5月, 2011 1 次提交
  32. 15 4月, 2011 2 次提交
  33. 13 4月, 2011 1 次提交
  34. 05 4月, 2011 2 次提交