1. 19 11月, 2016 1 次提交
  2. 17 9月, 2016 1 次提交
  3. 09 9月, 2016 2 次提交
  4. 03 9月, 2016 1 次提交
  5. 06 7月, 2016 1 次提交
    • A
      nl80211: support beacon report scanning · 1d76250b
      Avraham Stern 提交于
      Beacon report radio measurement requires reporting observed BSSs
      on the channels specified in the beacon request. If the measurement
      mode is set to passive or active, it requires actually performing a
      scan (passive or active, accordingly), and reporting the time that
      the scan was started and the time each beacon/probe was received
      (both in terms of TSF of the BSS of the requesting AP). If the
      request mode is table, this information is optional.
      In addition, the radio measurement request specifies the channel
      dwell time for the measurement.
      
      In order to use scan for beacon report when the mode is active or
      passive, add a parameter to scan request that specifies the
      channel dwell time, and add scan start time and beacon received time
      to scan results information.
      
      Supporting beacon report is required for Multi Band Operation (MBO).
      Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d76250b
  6. 18 6月, 2016 1 次提交
    • A
      mwifiex: fix link error against sdio · 2095b142
      Arnd Bergmann 提交于
      Calling sdio_claim_host() from the interface independent part of
      the mwifiex driver is not only a layering violation, but also causes
      a link error if MMC support is disabled, or if CONFIG_MMC=m
      and CONFIG_MWIFIEX=y:
      
      drivers/net/built-in.o: In function `mwifiex_fw_dpc':
      :(.text+0xff138): undefined reference to `sdio_claim_host'
      :(.text+0xff158): undefined reference to `sdio_release_host'
      
      The right way to do this is to have the sdio specific code in the
      sdio driver front-end, and we already have a callback pointer that
      we can use for this after exporting the generic fw download
      function from the core driver.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 65c71efe ("mwifiex: fix racing condition when downloading firmware")
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      2095b142
  7. 14 6月, 2016 1 次提交
    • W
      mwifiex: fix racing condition when downloading firmware · 65c71efe
      Wei-Ning Huang 提交于
      The action 'check for winner' and 'download firmware' should be an
      atomic action. This is true for btmrvl driver but not mwmfiex, which
      cause firmware download to fail when the following senerio happens:
      
      1) mwifiex check winner status: true
      2) btmrvl check winner status: true, and start downloading firmware
      3) mwfieix tries to download firmware, but failed because btmrvl is
      already downloading.
      
      This won't happen if 1) and 3) is an atomic action. This patch adds
      sdio_claim/release_host call around those two actions to make sure it's
      atomic.
      Signed-off-by: NWei-Ning Huang <wnhuang@chromium.org>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      65c71efe
  8. 26 4月, 2016 1 次提交
  9. 14 4月, 2016 1 次提交
  10. 08 4月, 2016 1 次提交
  11. 29 1月, 2016 2 次提交
  12. 07 1月, 2016 1 次提交
    • A
      mwifiex: reduce cloned skb queue size · ee548d4b
      Amitkumar Karwar 提交于
      Driver supports Tx status ack feature. When hostapd/
      wpa_supplicant asks for ack status of an EAPOL/ACTION
      frame, driver maintains a cloned skb for the packet
      until TX_STATUS event is received from firmware.
      
      Cloned skb queue gets flushed when connection is terminated
      or driver is unloaded.
      
      Let's reduce the queue size to avoid unnecessarily
      keeping memory allocated when environment is busy.
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ee548d4b
  13. 18 11月, 2015 1 次提交
  14. 14 10月, 2015 1 次提交
  15. 29 9月, 2015 3 次提交
  16. 21 7月, 2015 2 次提交
  17. 03 6月, 2015 4 次提交
  18. 26 5月, 2015 2 次提交
  19. 09 5月, 2015 1 次提交
  20. 30 3月, 2015 2 次提交
    • T
      cfg80211: pass name_assign_type to rdev_add_virtual_intf() · 6bab2e19
      Tom Gundersen 提交于
      This will expose in /sys whether the ifname of a device is set by
      userspace or generated by the kernel. The latter kind (wlanX, etc)
      is not deterministic, so userspace needs to rename these devices
      to names that are guaranteed to stay the same between reboots. The
      former, however should never be renamed, so userspace needs to be
      able to reliably tell the difference.
      
      Similar functionality was introduced for the rtnetlink core in
      commit 5517750f ("net: rtnetlink - make create_link take name_assign_type")
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
      Cc: Hante Meuleman <meuleman@broadcom.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      [reformat changelog to fit 72 cols]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6bab2e19
    • M
      mwifiex: Fix issue in the SDIO reset path of mwifiex. · 2f5872b6
      Maithili Hinge 提交于
      SDIO reset was not happening properly on mwifiex as cancel_work_sync
      in mwifiex_sdio_remove used to kill the calling work function itself.
      Due to this, the interface was not getting removed and card was not
      getting added again. Reset work function has been made independent
      of adapter variable and cancel_work_sync has been moved to cleanup
      function.
      Signed-off-by: NMaithili Hinge <maithili@marvell.com>
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      2f5872b6
  21. 17 3月, 2015 5 次提交
  22. 27 2月, 2015 1 次提交
    • S
      mwifiex: more_task flag for main_process · 04c7b363
      Shengzhen Li 提交于
      This patch handles a corner case where TX packet would remain in
      driver queue till next packet comes in.
      Here is sequence:
      1. TX packet is queued via hard_start_xmit and main_work is queued
      2. SDIO interrupt comes in which directly call mwifiex_main_process.
      This starts executing main superloop.
      3. Now work from step1 is scheduled but at first check itself it sees
      mwifiex_processing is set and exits.
      4. Now if superloop from step2 has passed TX processing part of superloop
      this packet would remain in queue until next packet/command/SDIO interrupt
      arrives and queues main_work.
      
      This patch fixes this corner case by defining more_task flag which is set when
      mwifiex_processing is found to be true. At end of superloop we again check if
      more_task flag is set and if set, execute superloop again.
      Signed-off-by: NShengzhen Li <szli@marvell.com>
      Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: NCathy Luo <cluo@marvell.com>
      Signed-off-by: NAvinash Patil <patila@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      04c7b363
  23. 29 1月, 2015 4 次提交