1. 26 Aug, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: add qca6164 support · 36582e5d
      Michal Kazior authored
      
      
      This adds additional 0x0041 PCI Device ID
      definition to ath10k for QCA6164 which is a 1
      spatial stream sibling of the QCA6174 (which is 2
      spatial stream chip).
      
      The QCA6164 needs a dedicated board.bin file which
      is different than the one used for QCA6174. If the
      board.bin is wrong the device will crash early
      while trying to boot firmware. The register dump
      will look like this:
      
       ath10k_pci 0000:02:00.0: firmware register dump:
       ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31
       ...
      
      Note the value 0x000A012D.
      
      Special credit goes to Alan Liu
      <alanliu@qca.qualcomm.com> for providing support
      help which enabled me to come up with this patch.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      36582e5d
  2. 17 Aug, 2015 1 commit
  3. 30 Jul, 2015 1 commit
    • Raja Mani's avatar
      ath10k: fix memory alloc failure in qca99x0 during wmi svc rdy event · c8ecfc1c
      Raja Mani authored
      
      
      Host memory required for firmware is allocated while handling
      wmi service ready event. Right now, wmi service ready is handled
      in tasklet context and it calls dma_alloc_coherent() with atomic
      flag (GFP_ATOMIC) to allocate memory in host needed for firmware.
      The problem is, dma_alloc_coherent() with GFP_ATOMIC fails in
      the platform (at least in AP platform) where it has less atomic
      pool memory (< 2mb). QCA99X0 requires around 2 MB of host memory
      for one card, having additional QCA99X0 card in the same platform
      will require similarly amount of memory. So, it's not guaranteed that
      all the platform will have enough atomic memory pool.
      
      Fix this issue, by handling wmi service ready event in workqueue
      context and calling dma_alloc_coherent() with GFP_KERNEL. mac80211 work
      queue will not be ready at the time of handling wmi service ready.
      So, it can't be used to handle wmi service ready. Also, register work
      gets scheduled during insmod in existing ath10k_wq and waits for
      wmi service ready to completed. Both workqueue can't be used for
      this purpose. New auxiliary workqueue is added to handle wmi service
      ready.
      
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      c8ecfc1c
  4. 29 Jul, 2015 1 commit
    • David Liu's avatar
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu authored
      
      
      This patch enables raw Rx/Tx encap mode to support software based
      crypto engine. This patch introduces a new module param 'cryptmode'.
      
       cryptmode:
      
         0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
            encapsulation to the firmware. This is the default mode.
         1: Use sofware crypto engine globally with raw mode TX/RX
            encapsulation to the firmware.
      
      Known limitation:
         A-MSDU must be disabled for RAW Tx encap mode to perform well when
         heavy traffic is applied.
      
      Testing: (by Michal Kazior <michal.kazior@tieto.com>)
      
           a) Performance Testing
      
            cryptmode=1
             ap=qca988x sta=killer1525
              killer1525  ->  qca988x     194.496 mbps [tcp1 ip4]
              killer1525  ->  qca988x     238.309 mbps [tcp5 ip4]
              killer1525  ->  qca988x     266.958 mbps [udp1 ip4]
              killer1525  ->  qca988x     477.468 mbps [udp5 ip4]
              qca988x     ->  killer1525  301.378 mbps [tcp1 ip4]
              qca988x     ->  killer1525  297.949 mbps [tcp5 ip4]
              qca988x     ->  killer1525  331.351 mbps [udp1 ip4]
              qca988x     ->  killer1525  371.528 mbps [udp5 ip4]
             ap=killer1525 sta=qca988x
              qca988x     ->  killer1525  331.447 mbps [tcp1 ip4]
              qca988x     ->  killer1525  328.783 mbps [tcp5 ip4]
              qca988x     ->  killer1525  375.309 mbps [udp1 ip4]
              qca988x     ->  killer1525  403.379 mbps [udp5 ip4]
              killer1525  ->  qca988x     203.689 mbps [tcp1 ip4]
              killer1525  ->  qca988x     222.339 mbps [tcp5 ip4]
              killer1525  ->  qca988x     264.199 mbps [udp1 ip4]
              killer1525  ->  qca988x     479.371 mbps [udp5 ip4]
      
            Note:
             - only open network tested for RAW vs nwifi performance comparison
             - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
             - used iperf
             - OTA, devices a few cm apart from each other, no shielding
             - tcpX/udpX, X - means number of threads used
      
            Overview:
             - relative Tx performance drop is seen but is within reasonable and
               expected threshold (A-MSDU must be disabled with RAW Tx)
      
           b) Connectivity Testing
      
            cryptmode=1
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
      
            Note:
             - each test takes all possible endpoint pairs and pings
             - each pair-ping flushes arp table
             - ip6 is used
      
           c) Testbed Topology:
      
            1ap1sta:
              [ap] ---- [sta]
      
              endpoints: ap, sta
      
            1ap1sta2br:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                  [br0]            [br1]
      
              endpoints: veth0, veth2, br0, br1
              note: STA works in 4addr mode, AP has wds_sta=1
      
            1ap1sta2br1vlan:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                [br0]              [br1]
                  |                  |
                [vlan0_id2]        [vlan1_id2]
      
              endpoints: vlan0_id2, vlan1_id2
              note: STA works in 4addr mode, AP has wds_sta=1
      
      Credits:
      
          Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
          amsdu issue, contributed a workaround (already squashed into this
          patch), and contributed the throughput and connectivity tests results.
      
      Signed-off-by: default avatarDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Tested-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ccec9038
  5. 11 Jul, 2015 1 commit
  6. 02 Jul, 2015 3 commits
    • Raja Mani's avatar
      ath10k: configure frag desc memory to target for qca99X0 · d9156b5f
      Raja Mani authored
      
      
      Pre qca99X0 chipsets follows the model where dynamically allocate
      memory for frag desc on getting new skb for TX. But, this is not
      going to be the case in qca99X0. It expects frag desc memory to be
      allocated at boot time and let the driver to reuse allocated memory
      after every TX completion. So there won't be any dynamic frag memory
      memory allocation in qca99X0 during data transmission.
      
      qca99X0 hardware doesn't need fragment desc address to be programmed
      in msdu descriptor for every data transaction. It needs to know only
      starting address of fragment descriptor at the time of the boot.
      During data transmission, qca99X0 hardware can retrieve corresponding
      frag addr by adding programmed frag desc base addr + msdu id.
      
      Allocate continuous fragment descriptor memory (same size as number of
      descriptor) at the time of target initialization and configure allocated
      dma address to the target via HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG.
      
      How this is allocated continuous memory is going to be used is not
      covered in this patch. It just allocates memory and hand over to firmware.
      If we don't do it at init time, qca99X0 will stall when firmware tries
      to do TX.
      
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d9156b5f
    • Raja Mani's avatar
      ath10k: set max spatial stream to 4 for 10.4 fw · 5c8726ec
      Raja Mani authored
      
      
      10.4 fw supports upto 4 spatial stream. Limit max spatial
      stream to 4 for 10.4 firmware and to 3 for non 10.4 firmware.
      
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      5c8726ec
    • Raja Mani's avatar
      ath10k: handle 10.4 firmware wmi swba event · 3cec3be3
      Raja Mani authored
      
      
      10.4 firmware swba event payload has space to accommodate upto
      512 client traffic indication info & one p2p noa descriptor.
      It's is not matching with exiting swba event format defined for
      non 10.4 firmware. Non 10.4 firmware swba event format is designed
      to support only upto only 128 client and four p2p notice of absence
      descriptor.
      
      following changes are done in this patch to enable ath10k to handle
      10.4 firmware swba event,
      
       - link generic ath10k_wmi_event_host_swba() to handle 10.4 swba
         event in 10.4 wmi rx handler.
      
       - add 10.4 specific swba event structure wmi_10_4_host_swba_event.
      
       - new function ath10k_wmi_10_4_op_pull_swba_ev() to parse
         10.4 swba event.
      
       - increase tim_bitmap[] size in ath10k_vif to 64 to hold 512 station
         power save state.
      
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      3cec3be3
  7. 30 Jun, 2015 4 commits
  8. 16 Jun, 2015 1 commit
  9. 09 Jun, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: remove ath10k_chanctx struct · 089ab7a5
      Michal Kazior authored
      
      
      In practice there's no point in having a copy of
      chanctx_conf.
      
      Most of the time the channel pointer (and band
      along with it) is accessed and this can't change
      after a chanctx is created because switching is
      done using explicit chanctx swapping via
      switch_vif_chanctx().
      
      The only thing that can change within a
      chanctx_conf and is used by the driver is
      radar_enabled and channel width. These are however
      always accessed in adequate mac80211 callback
      context which guarantees safe access to the
      chanctx data.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      089ab7a5
  10. 01 Jun, 2015 1 commit
  11. 29 May, 2015 2 commits
    • Michal Kazior's avatar
      ath10k: fix inconsistent survey reports · 44b7d483
      Michal Kazior authored
      
      
      In some cases some channel survey data was
      reported incorrect.
      
      Channel info events were expected to come in pairs
      without and with COMPLETE flag set respectively
      for each channel visit during scan.
      
      The known deviation from this is rule for last
      scan chan info and first (next) scan chan info
      both have COMPLETE flag set. This was either
      programmed with the intent of providing BSS cycle
      count info or this is an artefact of firmware scan
      state machine. Either way this is useless due to
      short wraparound time, wraparound quirks and no
      overflow notification.
      
      Survey dumps now include only data gathered during
      scan channel visits that can be computed
      correctly.
      
      This should improve hostapd ACS a little bit.
      
      Reported-by: default avatarSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      44b7d483
    • Michal Kazior's avatar
      ath10k: handle cycle counter wraparound · 587f7031
      Michal Kazior authored
      
      
      When QCA988X cycle counter HW register wraps
      around it resets to 0x7fffffff instead of 0. All
      other cycle counter related registers are divided
      by 2 so they never wraparound themselves. QCA61X4
      has a uniform CC and it wraparounds in a regular
      fashion though.
      
      Worst case wraparound time is approx 24 seconds
      (2**31 / 88MHz). Since scan channel visit times
      are max 5 seconds (offchannel case) it is
      guaranteed there's been at most 1 wraparound and
      it is possible to compute survey active time
      value. It is, however, impossible to determine the
      point at which Rx Clear Count has been divided by
      two so it is not reported upon wraparound.
      
      This fixes some occasional incorrect survey data
      on QCA988X as some channels (depending on how/when
      scan/offchannel requests were requested) would
      have approx 24 sec active time which wasn't
      actually the case.
      
      This should improve hostapd ACS a little bit.
      
      Reported-by: default avatarSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      587f7031
  12. 22 May, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: add new 4addr related fw_feature · 48f4ca34
      Michal Kazior authored
      
      
      Some firmware revisions pad 4th hw address in
      Native Wifi Rx decap. This is the case with 10.x
      and it was assumed that this is true for all
      firmware images.
      
      However QCA988X with 999.999.0.636 and QCA61X4
      with WLAN.RM.2.0-00088 don't have the padding.
      Hence add a feature flag indicating that the
      padding isn't present so firmware images can
      advertise it appropriately. This way driver will
      behave as it was before with old firmware blobs
      and doesn't cause any regressions from user
      perspective.
      
      Effectively this patch enables QCA988X with
      999.999.0.636 and QCA61X4 with WLAN.RM.2.0-00088
      to set up client bridging provided user has an
      updated firmware blob.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      48f4ca34
  13. 04 May, 2015 1 commit
    • Kalle Valo's avatar
      ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT · d9153546
      Kalle Valo authored
      
      
      qca6174 otp binary seems to always return an error to the host, even if the
      calibration succeeded. Add a firmware feature flag to detect if the firmware
      image which have this problem and workaround the issue in ath10k by ignoring
      the error code.
      
      I was also considering making this hw specific flag but as this is strictly a
      firmware issue it's best to handle this via a firmware feature flag so that it
      will be easy to disable the workaround.
      
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d9153546
  14. 27 Apr, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: implement more versatile set_bitrate_mask · 45c9abc0
      Michal Kazior authored
      
      
      Until now only a single fixed tx rate or nss was
      allowed to be set.
      
      The patch attempts to improve this by allowing
      most bitrate masks. The limitation is VHT MCS
      rates cannot be expressed separately using
      existing firmware interfaces and only the
      following VHT MCS ranges are supported: none, 0-7,
      0-8, and 0-9.
      
      This keeps the old behaviour when requesting
      single tx rate or single nss. The new bitrate mask
      logic is only applied to other cases that would
      return -EINVAL until now.
      
      Depending on firmware revisions some combinations
      may crash firmware so use with care, please.
      
      This depends on "ath10k: don't use reassoc flag".
      Without it key cache would effectively be
      invalidated upon bitrate change leading to
      communication being no longer possible.
      
      These work:
      
        iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3
        iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9
        iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
      
      These won't work:
      
        iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
        iw wlan0 set bitrates vht-mcs-5 2:7-9
      
      (note the invalid VHT MCS ranges)
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      45c9abc0
  15. 21 Apr, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior authored
      
      
      Some devices differ slightly and require different
      board files. If wrong board data is used they
      crash or behave incorrectly.
      
      These devices can be differentiated by looking at
      PCI subsystem device id. That is the case for
      qca61x4 devices at least.
      
      The board specific filename is constructed as:
      
       board-<bus>-<id>.bin
      
      For PCI in particular it is:
      
       board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin
      
      These files are looked in device/hw specific
      directories. Hence for Killer 1525 (qca6174 hw2.1)
      ath10k will request:
      
        /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin
      
      To not break any existing setups (e.g. in case
      some devices in the wild already have subsys ids)
      if a board specific file isn't found a generic one
      is used which is the one which would be used until
      now. This guarantees that after upgrading a driver
      device will not suddenly stop working due to
      now-missing specific board file. If this is the
      case a "fallback" string is appended to the info
      string when driver boots.
      
      Keep in mind this is distinct from cal-pci-*.bin
      files which contain full calibration data and MAC
      address. Cal data is aimed at systems where
      calibration data is stored out of band, e.g. on
      nand flash instead of device EEPROM - an approach
      taken by some AP/router vendors.
      
      Board files are more of a template and needs some
      bits to be filled in by the OTP program using
      device EEPROM contents.
      
      One could argue to map subsystem ids to some board
      design codename strings instead of using raw ids
      when building the board filename. Using a mapping
      however would make it a lot more cumbersome and
      time consuming (due to how patches propagate over
      various kernel trees) to add support for some new
      device board designs. Adding a board file is a lot
      quicker and doesn't require recompilation.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      de57e2c8
  16. 09 Apr, 2015 1 commit
  17. 01 Apr, 2015 4 commits
  18. 30 Mar, 2015 3 commits
  19. 23 Mar, 2015 2 commits
  20. 12 Mar, 2015 1 commit
  21. 07 Mar, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: fix AP/IBSS CSA with template based fw · 81a9a17d
      Michal Kazior authored
      
      
      qca6174 with wmi-tlv firmware uses offloaded
      beaconing scheme (i.e. templates). This requires a
      little different approach when implementing CSA.
      
      Add missing code to update CS count and report CSA
      completion to mac80211. Without it channel switch
      was never finished.
      
      To avoid races during interface teardown data_lock
      has been used to protect is_up and is_started so
      they can be compared against before scheduling
      count down work.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      81a9a17d
  22. 04 Mar, 2015 1 commit
  23. 15 Feb, 2015 1 commit
  24. 04 Feb, 2015 3 commits
    • SenthilKumar Jegadeesan's avatar
      ath10k: add log level configuration for fw_dbglog · 467210a6
      SenthilKumar Jegadeesan authored
      
      
      Introduce an optional log level configuration for the existing debugfs fw_dbglog file. It
      allows users to configure the desired log level for firmware dbglog messages.
      
      To configure log level as WARN:
      
      echo 0xffffffff  2 > /sys/kernel/debug/ieee80211/phy0/ath10k/fw_dbglog
      
      The values are:
      
      VERBOSE		0
      INFO		1
      WARN		2
      ERR		3
      
      Signed-off-by: default avatarSenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      467210a6
    • Michal Kazior's avatar
      ath10k: fix beacon deadlock · af21319f
      Michal Kazior authored
      
      
      This should fix a very rare occurrence of the following deadlock:
      
        [<ffffffffa018265e>] ath10k_wmi_tx_beacons_nowait+0x1e/0x50 [ath10k_core]
        [<ffffffffa01829b6>] ath10k_wmi_op_ep_tx_credits+0x16/0x40 [ath10k_core]
        [<ffffffffa017d685>] ath10k_htc_send+0x285/0x3d0 [ath10k_core]
        [<ffffffffa0184b81>] ath10k_wmi_cmd_send_nowait+0x81/0x110 [ath10k_core]
        [<ffffffffa0184c61>] ath10k_wmi_tx_beacon_nowait.part.33+0x51/0x90 [ath10k_core]
        [<ffffffffa0184cd0>] ath10k_wmi_tx_beacons_iter+0x30/0x40 [ath10k_core]
        [<ffffffff81882246>] __iterate_active_interfaces+0xa6/0x100
        [<ffffffffa0184ca0>] ? ath10k_wmi_tx_beacon_nowait.part.33+0x90/0x90 [ath10k_core]
        [<ffffffff818822ae>] ieee80211_iterate_active_interfaces_atomic+0xe/0x10
        [<ffffffffa0182676>] ath10k_wmi_tx_beacons_nowait+0x36/0x50 [ath10k_core]
        [<ffffffffa01829b6>] ath10k_wmi_op_ep_tx_credits+0x16/0x40 [ath10k_core]
        [<ffffffffa017d140>] ath10k_htc_rx+0x280/0x410 [ath10k_core]
        [<ffffffffa01bcbf0>] ? ath10k_ce_completed_recv_next+0x60/0x80 [ath10k_pci]
        [<ffffffffa01bc6ab>] ath10k_pci_ce_recv_data+0x11b/0x1d0 [ath10k_pci]
        [<ffffffffa01bcf44>] ath10k_ce_per_engine_service+0x64/0xc0 [ath10k_pci]
        [<ffffffffa01bcfc2>] ath10k_ce_per_engine_service_any+0x22/0x50 [ath10k_pci]
        [<ffffffffa01bc4d0>] ath10k_pci_tasklet+0x30/0x90 [ath10k_pci]
        [<ffffffff81055a55>] tasklet_action+0xc5/0x100
      
      To prevent this make sure to release ar->data_lock
      while calling to ath10k_wmi_beacon_send_ref_nowait().
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      af21319f
    • SenthilKumar Jegadeesan's avatar
      ath10k: prevent setting wrong key idx for station · 627613f8
      SenthilKumar Jegadeesan authored
      
      
      Ath10k driver sets wrong default key idx that results in
      sending unicast frames with multicast key.
      
      The reason for this behavior is that cached broadcast key
      is installed for station MAC address on association. After
      dot1x completes, unicast key is installed for station
      MAC address. Default key idx is set to broadcast key id when
      driver tries to send broadcast frame. This causes firmware
      to use broadcast key id to transmit unicast frames to stations.
      
      Used TX_USAGE flag to set default key for stations.
      
      Added callback for setting unicast default idx which will be
      invoked on every default key idx configuration.
      
      Signed-off-by: default avatarSenthilKumar Jegadeesan <sjegadee@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      627613f8
  25. 29 Jan, 2015 1 commit
  26. 27 Jan, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: add support for qca6174 · d63955b3
      Michal Kazior authored
      
      
      The QCA6174 in combination with new wmi-tlv firmware is capable of
      multi-channel, beamforming, tdls and other features.
      
      This patch just makes it possible to boot these devices and do some basic stuff
      like connect to an AP without encryption. Some things may not work or may be
      unreliable. New features will be implemented later. This will be addressed
      eventually with future patches.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d63955b3