1. 29 8月, 2014 2 次提交
  2. 19 7月, 2014 1 次提交
  3. 04 7月, 2014 1 次提交
  4. 26 6月, 2014 3 次提交
  5. 25 4月, 2014 1 次提交
  6. 23 4月, 2014 2 次提交
  7. 01 4月, 2014 1 次提交
    • A
      mwifiex: fix spinlock bad magic bug · a7488c79
      Amitkumar Karwar 提交于
      [ 6630.450908] BUG: spinlock bad magic on CPU#1,
                     ksdioirqd/mmc1/355
      [ 6630.450914] Unable to handle kernel NULL pointer dereference
                     at virtual address 0000004f
      [ 6630.450919] pgd = ecbd8000
      [ 6630.450926] [0000004f] *pgd=00000000
      [ 6630.450936]  lock: 0xeea4ab08, .magic: 00000000,
                     .owner: <none>/-1, .owner_cpu: 0
      [ 6630.450939] Backtrace:
      [ 6630.450956] [<c010d354>] (unwind_backtrace+0x0/0x118) from
                     [<c060c238>] (dump_stack+0x28/0x30)
      [ 6630.450960] Internal error: Oops: 5 [#1] SMP ARM
      [ 6630.450964] Modules linked in: uvcvideo videobuf2_vmalloc
      [ 6630.450980] [<c060c238>] (dump_stack+0x28/0x30) from
                     [<c0315ab4>] (spin_dump+0x80/0x94)
      [ 6630.450988] [<c0315ab4>] (spin_dump+0x80/0x94) from
                     [<c0315af4>] (spin_bug+0x2c/0x30)
      [ 6630.450996] [<c0315af4>] (spin_bug+0x2c/0x30) from
                     [<c0315b80>] (do_raw_spin_lock+0x28/0x15c)
      [ 6630.451004] [<c0315b80>] (do_raw_spin_lock+0x28/0x15c) from
                     [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
      [ 6630.451016] [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
                     from [<bf07a7f4>] (mwifiex_exec_next_cmd
                                        +0x6c/0x45c [mwifiex])
      [ 6630.451030] [<bf07a7f4>] (mwifiex_exec_next_cmd+0x6c/0x45c
                     [mwifiex]) from [<bf07834c>]
                     (mwifiex_main_process+0x2c8/0x464 [mwifiex])
      [ 6630.451047] [<bf07834c>] (mwifiex_main_process+0x2c8/0x464
                     [mwifiex]) from [<bf0a093c>]
                     (mwifiex_sdio_interrupt+0xc8/0x1cc [mwifiex_sdio]
      [ 6630.451064] [<bf0a093c>] (mwifiex_sdio_interrupt+0xc8/0x1cc
                     [mwifiex_sdio]) from [<c04bbde0>]
                     (sdio_irq_thread+0x178/0x31c)
      [ 6630.451079] [<c04bbde0>] (sdio_irq_thread+0x178/0x31c) from
                     [<c0145514>] (kthread+0xc8/0xd8)
      [ 6630.451095] [<c0145514>] (kthread+0xc8/0xd8) from
                     [<c0106118>] (ret_from_fork+0x14/0x20)
      
      This bug has introduced/exposed due to recent patch in which we
      cancel pending commands before suspend (using hs_enabling flag).
      The NULL pointer is dereferenced when both
      mwifiex_cancel_all_pending_cmd() and mwifiex_exec_next_cmd()
      try to access cmd pending queue simultaneously.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7488c79
  8. 28 3月, 2014 2 次提交
  9. 15 3月, 2014 1 次提交
  10. 01 3月, 2014 7 次提交
  11. 25 2月, 2014 1 次提交
  12. 13 2月, 2014 3 次提交
  13. 10 12月, 2013 1 次提交
  14. 11 10月, 2013 1 次提交
  15. 27 9月, 2013 1 次提交
  16. 23 5月, 2013 1 次提交
  17. 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
  18. 23 4月, 2013 1 次提交
  19. 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
  20. 19 3月, 2013 2 次提交
  21. 07 3月, 2013 1 次提交
  22. 19 2月, 2013 1 次提交
  23. 05 2月, 2013 1 次提交
  24. 17 11月, 2012 1 次提交
  25. 15 11月, 2012 1 次提交
  26. 20 10月, 2012 1 次提交