1. 18 6月, 2013 1 次提交
    • D
      mwifiex: fix memory corruption when unsetting multicast list · 6390d885
      Daniel Drake 提交于
      When trying to unset a previously-set multicast list (i.e. the new list
      has 0 entries), mwifiex_set_multicast_list() was calling down to
      mwifiex_request_set_multicast_list() while leaving
      mcast_list.num_multicast_addr as an uninitialized value.
      
      We were arriving at mwifiex_cmd_mac_multicast_adr() which would then
      proceed to do an often huge memcpy of
      mcast_list.num_multicast_addr*ETH_ALEN bytes, causing memory corruption
      and hard to debug crashes.
      
      Fix this by setting mcast_list.num_multicast_addr to 0 when no multicast
      list is provided. Similarly, fix up the logic in
      mwifiex_request_set_multicast_list() to unset the multicast list that
      was previously sent to the hardware in such cases.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6390d885
  2. 13 6月, 2013 1 次提交
  3. 23 5月, 2013 2 次提交
  4. 09 5月, 2013 1 次提交
  5. 09 3月, 2013 1 次提交
  6. 15 11月, 2012 2 次提交
    • B
      mwifiex: process RX packets in SDIO IRQ thread directly · 601216e1
      Bing Zhao 提交于
      ksdioirqd has higher priority than kworker. Process RX packets
      in SDIO IRQ thread (ksdioirqd/mmcX) directly instead of deferring
      the work to kworker to avoid the extra latency.
      This improves TCP throughput 15~20% on an ARM platform with SDIO
      2.0 controller.
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      601216e1
    • A
      mwifiex: add multi-queue support · 47411a06
      Avinash Patil 提交于
      This patch adds support for multiple TX queues inside mwifiex
      driver. Four different queues according to WMM access categories
      are defined for each virtual interface. When a packet is
      received from netdev for transmission, tx pending count for
      particular queue is incremented and if tx pending count has
      reached upper water-mark, this queue is stopped instead of
      stopping all queues. Similarly when a packet is successfully
      transmitted from device, tx pending count is decremented per
      queue and if pending count falls below lower water-mark, queue
      operations are again resumed. This ensures that not all
      tranmission is blocked if traffic with particular TOS value
      suddenly increases.
      
      Also wake all queues after association/IBSS_join/uAP_BSS_start
      to enable traffic on all queues.
      Signed-off-by: NAvinash Patil <patila@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      47411a06
  7. 30 10月, 2012 1 次提交
  8. 29 9月, 2012 2 次提交
  9. 12 9月, 2012 1 次提交
  10. 07 8月, 2012 1 次提交
  11. 12 7月, 2012 1 次提交
  12. 23 6月, 2012 1 次提交
  13. 12 6月, 2012 1 次提交
    • A
      mwifiex: fix simultaneous scan and Tx traffic problem · 3249ba73
      Amitkumar Karwar 提交于
      If scan operation is started when Tx traffic is already running,
      driver locks Tx queue until it gets completed. With this logic
      there is a delay for Tx packets.
      
      This patch implements new approach to give Tx path higher priority
      in this case. Driver internally sends multiple synchronous scan
      commands to firmware when scan is requested by user. Now we will
      make sure that Tx queue is empty everytime before sending next scan
      command. If Tx queue isn't empty scan command will be postponsed by
      20msec. This rule will be followed until Tx queue becomes empty or
      timeout of 1 second happens. In case of timeout scan operation will
      be aborted.
      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>
      3249ba73
  14. 17 5月, 2012 4 次提交
  15. 24 4月, 2012 1 次提交
  16. 13 4月, 2012 2 次提交
  17. 15 3月, 2012 1 次提交
  18. 07 2月, 2012 1 次提交
  19. 28 1月, 2012 1 次提交
  20. 25 1月, 2012 1 次提交
  21. 15 12月, 2011 1 次提交
  22. 14 12月, 2011 1 次提交
  23. 15 10月, 2011 1 次提交
    • A
      mwifiex: use separate wait condition for each command node · efaaa8b8
      Amitkumar Karwar 提交于
      Currently global wait condition (adapter->cmd_wait_q.condition)
      is used while sending synchronous commands to FW. When two threads
      enter in mwifiex_send_cmd_sync() routine at the same time, both the
      threads wait for their command responses. Since wait condition is
      same for both, they wake up simultaneously after getting response
      of 1st command. After this when a thread is waiting for command
      response of 3rd command, it wakes up after getting response of 2nd
      command and so on. Therefore we don't wait for the response of last
      command(0xaa) during unload. Hence while next time loading the driver
      command time out is seen for INIT command.
      
      This problem is resolved by having separate wait condition flag for
      each command(except scan command). Since scan command is treated
      differently (by maintaining scan pending q etc.), newly defined flag
      (scan_wait_q_woken) is used as a scan wait condition.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      efaaa8b8
  24. 13 10月, 2011 1 次提交
  25. 12 10月, 2011 1 次提交
    • Y
      mwifiex: fix smatch errors · 3d82de0f
      Yogesh Ashok Powar 提交于
      drivers/net/wireless/mwifiex/main.c +828 mwifiex_remove_card(52)
        error: potential null derefence 'priv'.
      drivers/net/wireless/mwifiex/main.c +828 mwifiex_remove_card(52)
        error: we previously assumed 'priv' could be null (see line 820)
      drivers/net/wireless/mwifiex/txrx.c +90 mwifiex_process_tx(24)
        error: potential null derefence 'local_tx_pd'.
      drivers/net/wireless/mwifiex/sta_ioctl.c +766
      mwifiex_rate_ioctl_set_rate_value(30)
        error: buffer overflow 'rate' 14 <= 14
      
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d82de0f
  26. 04 10月, 2011 1 次提交
  27. 01 10月, 2011 1 次提交
  28. 18 8月, 2011 1 次提交
  29. 10 8月, 2011 1 次提交
  30. 23 6月, 2011 1 次提交
  31. 11 6月, 2011 1 次提交
  32. 02 6月, 2011 1 次提交
  33. 11 5月, 2011 1 次提交