1. 29 1月, 2016 1 次提交
  2. 18 11月, 2015 1 次提交
  3. 14 10月, 2015 1 次提交
  4. 29 9月, 2015 1 次提交
  5. 11 8月, 2015 1 次提交
  6. 21 7月, 2015 3 次提交
  7. 08 6月, 2015 2 次提交
  8. 26 5月, 2015 2 次提交
  9. 17 3月, 2015 1 次提交
  10. 03 2月, 2015 1 次提交
  11. 29 1月, 2015 1 次提交
  12. 07 1月, 2015 1 次提交
  13. 01 11月, 2014 1 次提交
  14. 16 9月, 2014 1 次提交
  15. 29 8月, 2014 1 次提交
  16. 16 7月, 2014 1 次提交
  17. 26 6月, 2014 1 次提交
  18. 23 5月, 2014 1 次提交
  19. 15 3月, 2014 1 次提交
  20. 01 3月, 2014 1 次提交
  21. 13 2月, 2014 5 次提交
  22. 27 12月, 2013 1 次提交
  23. 06 12月, 2013 1 次提交
  24. 12 11月, 2013 3 次提交
  25. 27 8月, 2013 1 次提交
  26. 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
  27. 23 5月, 2013 2 次提交
  28. 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
  29. 26 3月, 2013 1 次提交