1. 09 3月, 2013 1 次提交
  2. 07 3月, 2013 2 次提交
    • A
      mwifiex: add WOWLAN support · 7da060c1
      Amitkumar Karwar 提交于
      Currently 'magic-packet' and 'patterns' options in 'iw wowlan'
      command are supported.
      
      Appropriate packet filters for wowlan are configured in firmware
      based on provided patterns and/or magic-packet option.
      
      For examples,
      
      wake-on ARP request for 192.168.0.100:
      iw phy0 wowlan enable patterns ff:ff:ff:ff:ff:ff 20+08:06
        46+c0:a8:00:64
      
      wake-on RX packets sent from IP address 192.168.0.88:
      iw phy0 wowlan enable patterns 34+c0:a8:00:58
      
      wake-on RX packets with TCP destination port 80
      iw phy0 wowlan enable patterns 44+50
      
      wake-on MagicPacket:
      iw phy0 wowlan enable magic-packet
      
      wake-on MagicPacket or patterns:
      iw phy0 wowlan enable magic-packet patterns 12+00:11:22:33:44:55
        18+00:50:43:21
      
      wake-on IPv4 multicast packets:
      iw phy0 wowlan enable patterns 01:00:5e
      
      wake-on IPv6 multicast packets:
      iw phy0 wowlan enable patterns 33:33
      
      disable all wowlan options
      iw phy0 wowlan disable
      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>
      7da060c1
    • A
      mwifiex: add "ethtool wol" command support · 0d7f53e3
      Amitkumar Karwar 提交于
      Host sleep wakeup condition is configured using this command.
      
      Supports Wake-on: pumb
      
      For examples:
      
      wake-on any unicast packets:
      ethtool -s mlan0 wol u
      
      wake-on multicast/broadcast packet:
      ethtool -s mlan0 wol mb
      
      wake-on unicast packets and MAC events:
      ethtool -s mlan0 wol pu
      
      wake-on unicast/multicast/broadcast packets and MAC events:
      ethtool -s mlan0 wol pmbu
      
      disable all wake-on options:
      ethtool -s mlan0 wol d
      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>
      0d7f53e3
  3. 19 2月, 2013 1 次提交
  4. 02 2月, 2013 1 次提交
  5. 08 1月, 2013 3 次提交
  6. 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
  7. 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
  8. 30 10月, 2012 2 次提交
  9. 20 10月, 2012 1 次提交
  10. 09 10月, 2012 1 次提交
  11. 29 9月, 2012 6 次提交
  12. 25 9月, 2012 1 次提交
  13. 19 9月, 2012 1 次提交
  14. 12 9月, 2012 1 次提交
  15. 08 9月, 2012 2 次提交
  16. 07 8月, 2012 7 次提交
  17. 18 7月, 2012 3 次提交
  18. 12 7月, 2012 1 次提交
  19. 10 7月, 2012 1 次提交
  20. 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
  21. 21 6月, 2012 1 次提交