1. 26 Aug, 2015 2 commits
  2. 30 Jul, 2015 1 commit
  3. 24 Jul, 2015 1 commit
  4. 11 Jul, 2015 1 commit
  5. 30 Jun, 2015 4 commits
  6. 16 Jun, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: prevent debugfs mmio access crash kernel · aeae5b4c
      Michal Kazior authored
      
      
      It was possible to force an out of bounds MMIO
      read/write via debugfs. E.g. on QCA988X this could
      be triggered with:
      
       echo 0x2080e0 | tee /sys/kernel/debug/ieee80211/*/ath10k/reg_addr
       cat /sys/kernel/debug/ieee80211/*/ath10k/reg_value
      
       BUG: unable to handle kernel paging request at ffffc90001e080e0
       IP: [<ffffffff8135c860>] ioread32+0x40/0x50
       ...
       Call Trace:
        [<ffffffffa00d0c7f>] ? ath10k_pci_read32+0x4f/0x70 [ath10k_pci]
        [<ffffffffa0080f50>] ath10k_reg_value_read+0x90/0xf0 [ath10k_core]
        [<ffffffff8115c2c1>] ? handle_mm_fault+0xa91/0x1050
        [<ffffffff81189758>] __vfs_read+0x28/0xe0
        [<ffffffff812e4694>] ? security_file_permission+0x84/0xa0
        [<ffffffff81189ce3>] ? rw_verify_area+0x53/0x100
        [<ffffffff81189e1a>] vfs_read+0x8a/0x140
        [<ffffffff8118acb9>] SyS_read+0x49/0xb0
        [<ffffffff8104e39c>] ? trace_do_page_fault+0x3c/0xc0
        [<ffffffff8196596e>] system_call_fastpath+0x12/0x71
      
      Reported-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      aeae5b4c
  7. 09 Jun, 2015 1 commit
  8. 01 Jun, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: fix possible ps sleep crash · 0bcbbe67
      Michal Kazior authored
      If probing failed pci sleep timer could remain
      running and trigger after ath10k structures were
      freed causing invalid pointer dereference:
      
       BUG: unable to handle kernel paging request at ffffc90001c80004
       IP: [<ffffffff81354728>] iowrite32+0x38/0x40
       ...
       Call Trace:
        <IRQ>
        [<ffffffffa00da048>] ? __ath10k_pci_sleep+0x48/0x60 [ath10k_pci]
        [<ffffffffa00da44e>] ath10k_pci_ps_timer+0x5e/0x80 [ath10k_pci]
        [<ffffffff810b210e>] call_timer_fn+0x3e/0x120
        [<ffffffffa00da3f0>] ? ath10k_pci_wake+0x150/0x150 [ath10k_pci]
        [<ffffffff810b3d11>] run_timer_softirq+0x201/0x2e0
        [<ffffffff8105d73f>] __do_softirq+0xaf/0x290
        [<ffffffff8105da95>] irq_exit+0x95/0xa0
        [<ffffffff81950406>] smp_apic_timer_interrupt+0x46/0x60
        [<ffffffff8194e77e>] apic_timer_interrupt+0x6e/0x80
      
      Fixes: 77258d40
      
       ("ath10k: enable pci soc powersaving")
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      0bcbbe67
  9. 29 May, 2015 1 commit
  10. 22 May, 2015 2 commits
    • Michal Kazior's avatar
      ath10k: enable pci soc powersaving · 77258d40
      Michal Kazior authored
      
      
      By using SOC_WAKE register it is possible to bring
      down power consumption of QCA61X4 from 36mA to
      16mA when associated and idle.
      
      Currently the sleep threshold/grace period is at a
      very conservative value of 60ms.
      
      Contrary to QCA61X4 the QCA988X firmware doesn't
      have Rx/beacon filtering available for client mode
      and SWBA events are used for beaconing in AP/IBSS
      so the SoC needs to be woken up at least every
      ~100ms in most cases. This means that QCA988X
      is at a disadvantage and the power consumption
      won't drop as much as for QCA61X4.
      
      Due to putting irq-safe spinlocks on every MMIO
      read/write it is expected this can cause a little
      performance regression on some systems. I haven't
      done any thorough measurements but some of my
      tests don't show any extreme degradation.
      
      The patch removes some explicit pci_wake calls
      that were added in 320e14b8db51aa ("ath10k: fix
      some pci wake/sleep issues"). This is safe because
      all MMIO accesses are now wrapped and the device
      is woken up automatically if necessary.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      77258d40
    • Janusz Dziedzic's avatar
      ath10k: enable ASPM · 76d870ed
      Janusz Dziedzic authored
      
      
      It is actually safe to enable ASPM after the
      device is booted up.
      
      This reduces power drain of QCA61X4 when driver is
      simply loaded (no interface is up) from 31mA to
      14mA. QCA988X wasn't measured but doesn't seem to
      regress in any other way.
      
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      76d870ed
  11. 21 Apr, 2015 2 commits
    • Michal Kazior's avatar
      ath10k: fix qca61x4 hw2.1 support · 11a002ef
      Michal Kazior authored
      
      
      During initialization firmware does some sort of
      memory switch between DRAM and IRAM. If
      configuration value for bank switching isn't
      correct device crashes during init.
      
      The new value prevents firmware 11.0.0.302 (and
      possibly others) for qca61x4 hw2.1 from crashing
      during init.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      11a002ef
    • 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
  12. 17 Apr, 2015 1 commit
  13. 30 Mar, 2015 1 commit
    • Kalle Valo's avatar
      ath10k: bump up FW API to 5 · 53513c30
      Kalle Valo authored
      
      
      Firmware 10.2.4.48-3 now supports management frames over HTT feature and has
      ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX. But as 10.2.4 branch has conflicting HTT ids
      patch "ath10k: add ATH10K_FW_IE_HTT_OP_VERSION" is needed to fix the issue.
      Older ath10k versions don't have support that support and to maintain backwards
      compatibility we need bump up the FW API to 5 not break older versions.
      
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      53513c30
  14. 07 Mar, 2015 3 commits
  15. 05 Mar, 2015 1 commit
  16. 04 Mar, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: workaround corrupted htt rx events · 63838640
      Michal Kazior authored
      
      
      qca6174 WLAN.RM.2.0-00073 firmware uses full rx
      reordering offload and delivers Rx via a new HTT
      event. The event however is incorrectly generated
      in firmware and becomes overly long (with trailing
      garbage). This was hitting defined CE buffer limit
      that was programmed to the device and caused
      device to crash upon busier Rx traffic.
      
      Increasing the CE buffer limit for HTT Rx pipe to
      2KBytes seems to be enough to workaround this
      problem.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      63838640
  17. 27 Jan, 2015 4 commits
  18. 15 Jan, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: prevent fw reg dump spam · a2fa8800
      Michal Kazior authored
      
      
      Originally the explicit fw register dump was added
      to wait_for_target_init because interrupts are
      masked early during power_up.
      
      Due to some changes in power_up/reset sequences
      sometimes when fw crashed ath10k would print the
      dump more than once via hif_stop -> warm_reset ->
      wait_for_target_init, possibly with different
      values each.
      
      Prevent this by doing the explicit fw register
      dump only during power_up instead of
      wait_for_target_init.
      
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      a2fa8800
  19. 08 Dec, 2014 1 commit
  20. 01 Dec, 2014 3 commits
  21. 26 Nov, 2014 2 commits
    • Yanbo Li's avatar
      ath10k: add memory dump debugfs interface · 9f65ad25
      Yanbo Li authored
      
      
      Add mem_val debugfs file for dumping the firmware (target) memory and also for
      writing to the memory. The firmware memory is accessed through one file which
      uses position of the file as the firmware memory address. For example, with dd
      use skip parameter for the address.
      
      Beucase target memory width is 32 bits it's strongly recommended to use
      blocksize divisable with 4 when using this interface. For example, when using
      dd use bs=4 to set the block size to 4 and remember to divide both count and
      skip values with four.
      
      To read 4 kB chunk from address 0x400000:
      
      dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1
      
      To write value 0x01020304 to address 0x400400:
      
      echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832
      
      To read 4 KB chunk of memory and then write back after edit:
      
      dd if=mem_value of=tmp.bin bs=4 count=1024 skip=1048576
      emacs tmp.bin
      dd if=tmp.bin of=mem_value bs=4 count=1024 seek=1048576
      
      Signed-off-by: default avatarYanbo Li <yanbol@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      9f65ad25
    • Yanbo Li's avatar
      ath10k: add register access debugfs interface · 077a3804
      Yanbo Li authored
      
      
      Debugfs files reg_addr and reg_val are used for reading and writing to the
      firmware (target) registers. reg_addr contains the address to be accessed,
      which also needs to be set first, and reg_value is when used for reading and
      writing the actual value in ASCII.
      
      To read a value from the firmware register 0x100000:
      
      # echo 0x100000 > reg_addr
      # cat reg_value
      0x00100000:0x000002d3
      
      To write value 0x2400 to address 0x100000:
      
      # echo 0x100000 > reg_addr
      # echo  0x2400 > reg_value
      #
      
      Signed-off-by: default avatarYanbo Li <yanbol@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      077a3804
  22. 03 Nov, 2014 1 commit
  23. 31 Oct, 2014 4 commits