Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 3月, 2013 1 次提交
  3. 19 2月, 2013 1 次提交
  5. 02 2月, 2013 1 次提交
  7. 08 1月, 2013 3 次提交
  9. 26 11月, 2012 1 次提交
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      由 Johannes Berg 提交于 
      As mwifiex (and mac80211 in the software case) are the
only drivers actually implementing remain-on-channel
with channel type, userspace can't be relying on it.
This is the case, as it's used only for P2P operations
right now.

Rather than adding a flag to tell userspace whether or
not it can actually rely on it, simplify all the code
by removing the ability to use different channel types.
Leave only the validation of the attribute, so that if
we extend it again later (with the needed capability
flag), it can't break userspace sending invalid data.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  11. 15 11月, 2012 2 次提交
    • 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
    • A
      mwifiex: add support for SDIO card reset · d31ab357
      由 Amitkumar Karwar 提交于 
      When command timeout happens due to a bug in firmware/hardware,
the timeout handler just prints some debug information. User is
unable to reload the driver in this case.

Inspired by 9a821f5d "libertas: add sd8686 reset_card support",
this patch adds card reset support for SDIO interface when
command timeout happens. If the SDIO host contoller supports
MMC_POWER_OFF|UP|ON operations, the chip will be reset and the
firmware will be re-downloaded.
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>
      d31ab357
  13. 30 10月, 2012 2 次提交
  15. 20 10月, 2012 1 次提交
  17. 09 10月, 2012 1 次提交
  19. 29 9月, 2012 6 次提交
  21. 25 9月, 2012 1 次提交
  23. 19 9月, 2012 1 次提交
  25. 12 9月, 2012 1 次提交
  27. 08 9月, 2012 2 次提交
  29. 07 8月, 2012 7 次提交
  31. 18 7月, 2012 3 次提交
  33. 12 7月, 2012 1 次提交
  35. 10 7月, 2012 1 次提交
  37. 29 6月, 2012 1 次提交
    • A
      mwifiex: wakeup main thread to handle command queued · 1a1fb970
      由 Amitkumar Karwar 提交于 
      We miss to wakeup main thread after adding command to cmd pending
queue at follwing places. These commands are handled later when
main thread is woken up for handling an interrupt for sleep event
from firmware. This adds worst case delay of 50msec.

1) We don't wakeup main thread when asynchronous command is added
to cmd pending queue. Move queue_work() call from
mwifiex_wait_queue_complete() to mwifiex_send_cmd_async() to wakeup
main thread for sync as well as async commands.

2) Scan operation is triggered due to following reasons
   a) request from user (ex. "iw scan" command)
   b) Scan performed by driver internally.
   In first case main thread is woken up when first scan command is
queued in cmd pending queue (we don't need to wakeup main thread for
subsequent scan commands, because they are queued in scan command
response handler), but it is not done for second case. queue_work()
is moved inside mwifiex_scan_networks() to handle both the cases.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
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>
      1a1fb970
  39. 21 6月, 2012 2 次提交
  41. 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