1. 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
  2. 30 10月, 2012 2 次提交
  3. 20 10月, 2012 1 次提交
  4. 09 10月, 2012 1 次提交
  5. 29 9月, 2012 6 次提交
  6. 25 9月, 2012 1 次提交
  7. 19 9月, 2012 1 次提交
  8. 12 9月, 2012 1 次提交
  9. 08 9月, 2012 2 次提交
  10. 07 8月, 2012 7 次提交
  11. 18 7月, 2012 3 次提交
  12. 12 7月, 2012 1 次提交
  13. 10 7月, 2012 1 次提交
  14. 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
  15. 21 6月, 2012 2 次提交
  16. 12 6月, 2012 2 次提交
  17. 17 5月, 2012 7 次提交