1. 16 4月, 2016 1 次提交
    • 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
  2. 08 4月, 2016 1 次提交
  3. 29 1月, 2016 2 次提交
  4. 18 11月, 2015 1 次提交
  5. 14 10月, 2015 1 次提交
  6. 29 9月, 2015 1 次提交
  7. 11 8月, 2015 1 次提交
  8. 21 7月, 2015 3 次提交
  9. 08 6月, 2015 2 次提交
  10. 26 5月, 2015 2 次提交
  11. 17 3月, 2015 1 次提交
  12. 03 2月, 2015 1 次提交
  13. 29 1月, 2015 1 次提交
  14. 07 1月, 2015 1 次提交
  15. 01 11月, 2014 1 次提交
  16. 16 9月, 2014 1 次提交
  17. 29 8月, 2014 1 次提交
  18. 16 7月, 2014 1 次提交
  19. 26 6月, 2014 1 次提交
  20. 23 5月, 2014 1 次提交
  21. 15 3月, 2014 1 次提交
  22. 01 3月, 2014 1 次提交
  23. 13 2月, 2014 5 次提交
  24. 27 12月, 2013 1 次提交
  25. 06 12月, 2013 1 次提交
  26. 12 11月, 2013 3 次提交
  27. 27 8月, 2013 1 次提交
  28. 10 8月, 2013 1 次提交
    • A
      mwifiex: add packet coalesce support · 562fc5b3
      Amitkumar Karwar 提交于
      Coalesce filters are configured in firmware based on settings
      received from cfg80211.
      
      Packet type which is required by firmware is determined based on
      provided patterns in a rule:
      
      Unicast: if pattern '01' with offset 0 is found
      Multicast: if pattern '33:33' or '01:00:5e' with offset 0 is found
      Broadcast: if pattern 'ff:ff:ff:ff' with offset 0 is found
      
      Some example coalesce configuration files:
      
      1) Coalesce Rx data packets from 192.168.0.88
      mac address of our device is 00:50:43:21:53:7A
      Source IP address offset comes out as 52 after following
      calculations:
          32 bytes of HW 802.11 header + 8 bytes LLC +
          12 bytes in IPV4 header till source IP address
      Destination mac is at offset 6 in HW header.
      
      delay=100
      condition=1
      patterns=01,6+00:50:43:22,10+53:7A,52+c0:a8:00:58
      
      2) Coalesce all broadcast and multicast packets(Multiple packet
      types are not allowed in a single rule. Hence created separate
      rules)
      
      delay=400
      condition=1
      patterns=33:33
      delay=400
      condition=1
      patterns=ff:ff:ff:ff
      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>
      562fc5b3
  29. 23 5月, 2013 1 次提交