1. 29 10月, 2015 5 次提交
    • A
      ath10k: add FW API support to test mode · a81a98ce
      Alan Liu 提交于
      Add WMI-TLV and FW API support in ath10k testmode.
      Ath10k can get right wmi command format from UTF image
      to communicate UTF firmware.
      Signed-off-by: NAlan Liu <alanliu@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a81a98ce
    • M
      ath10k: enable adaptive CCA · 62f77f09
      Maharaja 提交于
      European Union has made it mandatory that all devices working in 2.4 GHz
      has to adhere to the ETSI specification (ETSI EN 300 328 V1.9.1)
      beginnig this year. The standard basically speaks about interferences
      in 2.4Ghz band.
      For example, when 802.11 device detects interference, TX must be stopped
      as long as interference is present.
      
      Adaptive CCA is a feature, when enabled the device learns from the
      environment and configures CCA levels adaptively. This will improve
      detecting interferences and the device can stop trasmissions till the
      interference is present eventually leading to good performances in
      varying interference conditions.
      
      The patch includes code for enabling adaptive CCA for 10.2.4 firmware on
      QCA988X.
      Signed-off-by: NMaharaja <c_mkenna@qti.qualcomm.com>
      Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      62f77f09
    • Y
      wcn36xx: Remove warning message when dev is NULL for arm64 dma_alloc. · 07225524
      yfw 提交于
      arm64 has requirement that all the dma operations have actual device.
      Otherwise, following warnning message shown and dma allocation fails:
      
      WARNING: CPU: 0 PID: 954 at arch/arm64/mm/dma-mapping.c:106 __dma_alloc+0x24c/0x258()
      Use an actual device structure for DMA allocation
      Modules linked in: wcn36xx wcn36xx_platform
      CPU: 0 PID: 954 Comm: ifconfig Not tainted 4.0.0+ #14
      Hardware name: Qualcomm Technologies, Inc. MSM 8916 MTP (DT)
      Call trace:
      [<ffffffc000089904>] dump_backtrace+0x0/0x124
      [<ffffffc000089a38>] show_stack+0x10/0x1c
      [<ffffffc000627114>] dump_stack+0x80/0xc4
      [<ffffffc0000b2e64>] warn_slowpath_common+0x98/0xd0
      [<ffffffc0000b2ee8>] warn_slowpath_fmt+0x4c/0x58
      [<ffffffc00009487c>] __dma_alloc+0x248/0x258
      [<ffffffbffc009270>] wcn36xx_dxe_allocate_mem_pools+0xc4/0x108 [wcn36xx]
      [<ffffffbffc0079c4>] wcn36xx_start+0x38/0x240 [wcn36xx]
      [<ffffffc0005f161c>] ieee80211_do_open+0x1b0/0x9a4
      [<ffffffc0005f1e68>] ieee80211_open+0x58/0x68
      [<ffffffc00051693c>] __dev_open+0xb0/0x120
      [<ffffffc000516c10>] __dev_change_flags+0x88/0x150
      [<ffffffc000516cf4>] dev_change_flags+0x1c/0x5c
      [<ffffffc000570950>] devinet_ioctl+0x644/0x6f0
      Signed-off-by: NYin, Fengwei <fengwei.yin@linaro.org>
      Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      07225524
    • B
      wcn36xx: introduce per-channel ring buffer locks · 8e8e54c4
      Bob Copeland 提交于
      wcn36xx implements a ring buffer for transmitted frames for each
      (high and low priority) DMA channel.  The ring buffers are lockless:
      new frames are inserted at the head of the queue, while finished
      packets are reaped from the tail.
      
      Unfortunately, the list manipulations are missing any kind of barriers
      so are susceptible to various races: for example, a TX completion
      handler might read an updated desc->ctrl before the head has actually
      advanced, and then null out the ctl->skb pointer while it is still
      being used in the TX path.
      
      Simplify things here by adding a spin lock when traversing the ring.
      This change increased stability for me without adding any noticeable
      overhead on my platform (xperia z).
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      8e8e54c4
    • Z
      ath9k: fix phyerror codes · 56bae464
      Zefir Kurtisi 提交于
      Some of the ath9k_phyerr enums were wrong from the
      beginning (and even before). Most of the time the
      codes were used for counters to be displayed over
      debugfs, which made this a non-functional issue.
      
      Some (e.g. ATH9K_PHYERR_FALSE_RADAR_EXT) are used
      for radar detection and require the correct code
      to work as intended.
      
      This patch includes:
      a) fixes
        ATH9K_PHYERR_FALSE_RADAR_EXT:    24 => 36
        ATH9K_PHYERR_CCK_LENGTH_ILLEGAL: 32 => 28
        ATH9K_PHYERR_CCK_POWER_DROP:     33 => 29
        ATH9K_PHYERR_HT_CRC_ERROR:       34 => 32
        ATH9K_PHYERR_HT_LENGTH_ILLEGAL:  35 => 33
        ATH9K_PHYERR_HT_RATE_ILLEGAL:    36 => 34
      
      b) extensions
        ATH9K_PHYERR_CCK_BLOCKER = 24
        ATH9K_PHYERR_HT_ZLF      = 35
        ATH9K_PHYERR_GREEN_FIELD = 37
      
      Aside from the correction and completion made in
      the enum, the patch also extends the display of
      the related counters in the debugfs.
      Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      56bae464
  2. 19 10月, 2015 2 次提交
  3. 16 10月, 2015 7 次提交
  4. 14 10月, 2015 7 次提交
  5. 13 10月, 2015 1 次提交
    • A
      cfg80211: Add multiple scan plans for scheduled scan · 3b06d277
      Avraham Stern 提交于
      Add the option to configure multiple 'scan plans' for scheduled scan.
      Each 'scan plan' defines the number of scan cycles and the interval
      between scans. The scan plans are executed in the order they were
      configured. The last scan plan will always run infinitely and thus
      defines only the interval between scans.
      The maximum number of scan plans supported by the device and the
      maximum number of iterations in a single scan plan are advertised
      to userspace so it can configure the scan plans appropriately.
      
      When scheduled scan results are received there is no way to know which
      scan plan is being currently executed, so there is no way to know when
      the next scan iteration will start. This is not a problem, however.
      The scan start timestamp is only used for flushing old scan results,
      and there is no difference between flushing all results received until
      the end of the previous iteration or the start of the current one,
      since no results will be received in between.
      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>
      3b06d277
  6. 09 10月, 2015 16 次提交
  7. 06 10月, 2015 2 次提交