1. 03 9月, 2016 1 次提交
  2. 06 7月, 2016 1 次提交
    • A
      nl80211: support beacon report scanning · 1d76250b
      Avraham Stern 提交于
      Beacon report radio measurement requires reporting observed BSSs
      on the channels specified in the beacon request. If the measurement
      mode is set to passive or active, it requires actually performing a
      scan (passive or active, accordingly), and reporting the time that
      the scan was started and the time each beacon/probe was received
      (both in terms of TSF of the BSS of the requesting AP). If the
      request mode is table, this information is optional.
      In addition, the radio measurement request specifies the channel
      dwell time for the measurement.
      
      In order to use scan for beacon report when the mode is active or
      passive, add a parameter to scan request that specifies the
      channel dwell time, and add scan start time and beacon received time
      to scan results information.
      
      Supporting beacon report is required for Multi Band Operation (MBO).
      Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d76250b
  3. 29 6月, 2016 1 次提交
  4. 16 4月, 2016 2 次提交
    • A
      mwifiex: make mwifiex_insert_cmd_to_free_q local static · 85abfb12
      Andreas Fenkart 提交于
      after factoring out mwifiex_cancel_pending_scan_cmd
      the function is not called outside of cmdevt file
      moved function to head of file to avoid forward declaration,
      also moved mwifiex_recycle_cmd_node since they are very similar
      Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      85abfb12
    • A
      mwifiex: factor out mwifiex_cancel_pending_scan_cmd · c70ca8cb
      Andreas Fenkart 提交于
      Releasing the scan_pending lock in mwifiex_check_next_scan_command
      introduces a short window where pending scan commands can be removed
      or added before removing them all in mwifiex_cancel_pending_scan_cmd.
      I think this is safe, since the worst thing to happen is that a
      pending scan cmd is removed by the command handler. Adding new scan
      commands is not possible while one is pending, see scan_processing flag.
      Since all commands are removed from the queue anyway, we don't care if
      some commands are removed by a different code path earlier, the final
      state remains the same.
      I assume, that the critical section needed for the check has been
      extended over clearing the pending scan queue out of convenience. The
      lock was already held and releasing it and grab it again was just
      more work. It doesn't seem to be necessary because of concurrency.
      Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      c70ca8cb
  5. 14 4月, 2016 1 次提交
  6. 29 1月, 2016 1 次提交
  7. 30 12月, 2015 1 次提交
  8. 18 11月, 2015 1 次提交
  9. 06 8月, 2015 5 次提交
  10. 08 6月, 2015 3 次提交
  11. 03 6月, 2015 1 次提交
  12. 26 5月, 2015 2 次提交
  13. 29 1月, 2015 2 次提交
  14. 07 1月, 2015 1 次提交
  15. 16 9月, 2014 2 次提交
  16. 29 8月, 2014 3 次提交
  17. 19 7月, 2014 1 次提交
  18. 04 7月, 2014 1 次提交
  19. 26 6月, 2014 3 次提交
  20. 25 4月, 2014 1 次提交
  21. 23 4月, 2014 2 次提交
  22. 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
  23. 28 3月, 2014 2 次提交
  24. 15 3月, 2014 1 次提交