1. 28 7月, 2017 3 次提交
  2. 13 6月, 2017 1 次提交
  3. 31 5月, 2017 2 次提交
  4. 19 5月, 2017 1 次提交
  5. 18 5月, 2017 1 次提交
  6. 13 4月, 2017 1 次提交
  7. 21 3月, 2017 1 次提交
  8. 12 1月, 2017 3 次提交
  9. 30 12月, 2016 1 次提交
  10. 25 11月, 2016 1 次提交
  11. 19 11月, 2016 4 次提交
  12. 09 11月, 2016 1 次提交
    • X
      mwifiex: fix command timeout problem seen in stress tests · 49abe5c8
      Xinming Hu 提交于
      It is observed that if single tid 6 packet comes among with massive tid 0
      packets, tid 6 packet may stay in it's queue and will never be
      transmited. This is because wmm.highest_queued_prio will be set to 2
      during transmission of tid 0 packets As a result, main work thread
      keeps on looping without serving that packet. In this case, if command
      has downloaded to firmware, driver doesn't process it's response causing
      command timeout.
      
      This patch will reset highest_queued_prio if packets exist in data
      queue, and try to find a ra_list for current private.
      Signed-off-by: NXinming Hu <huxm@marvell.com>
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      49abe5c8
  13. 09 9月, 2016 2 次提交
  14. 03 9月, 2016 2 次提交
  15. 05 7月, 2016 1 次提交
  16. 29 6月, 2016 1 次提交
  17. 14 6月, 2016 1 次提交
  18. 27 4月, 2016 1 次提交
  19. 26 4月, 2016 1 次提交
  20. 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
  21. 08 4月, 2016 1 次提交
  22. 07 3月, 2016 1 次提交
  23. 07 2月, 2016 2 次提交
  24. 06 2月, 2016 1 次提交
  25. 29 1月, 2016 4 次提交