1. 31 10月, 2014 1 次提交
    • M
      ath10k: speed up hw recovery · 7962b0d8
      Michal Kazior 提交于
      In some cases hw recovery was taking an absurdly
      long time due to ath10k waiting for things that
      would never really complete.
      
      Instead of waiting for inevitable timeouts poke
      all completions and wakequeues and check if it's
      still worth waiting.
      
      Reading/writing ar->state requires conf_mutex.
      Since waiters might be holding it introduce a new
      flag CRASH_FLUSH so it's possible to tell waiters
      to abort whatever they were waiting for.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7962b0d8
  2. 21 10月, 2014 3 次提交
    • K
      ath10k: retrieve calibration data from file · a58227ef
      Kalle Valo 提交于
      A frequent request have been to be able to provide calibration data from a
      file as some of the AP devices store the calibration data on an MTD partition.
      This patchset adds support for that and also makes it easier to add Device Tree
      support later on.
      
      The calibration data is found by using the id string provided by dev_name()
      using this format:
      
      cal-<bus>-<id>.bin
      
      With PCI the id string contains bus, slot and func values. For example for a
      PCI device in bus 2 slot 0, ath10k will try to retrieve a calibration data from
      a file:
      
      /lib/firmware/ath10k/cal-pci-0000:02:00.0.bin
      
      The calibration data sequence is:
      
      1. Check with request_firmware() if there's a calibration file
         ("cal-<bus>-<id>.bin") on the filesystem for this device. If yes, use that. If
         not, goto 2
      
      2. Check if otp.bin is able to successfully load the calibration data
         from OTP. If yes, use that. If not, goto 3.
      
      4. Print an error message that no calibration data found and stop driver
         initialization for this device.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a58227ef
    • K
      ath10k: refactor ath10k_init_download_firmware() · 83091559
      Kalle Valo 提交于
      This is preparation for being able to download calibration data from a file.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      83091559
    • K
      ath10k: add back enum ath10k_bus · e07db352
      Kalle Valo 提交于
      Commit 3a0861ff ("ath10k: remove ath10k_bus") removed enum ath10k_bus
      because it was not used for anything at the time. But now it's needed for for
      retrieving the right calibration data file so add it back. Only new addition is
      ath10k_bus_str().
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e07db352
  3. 01 10月, 2014 1 次提交
  4. 12 9月, 2014 1 次提交
    • K
      ath10k: add testmode · 43d2a30f
      Kalle Valo 提交于
      Add testmode interface for starting and using UTF firmware which is used to run
      factory tests. This is implemented by adding new state ATH10K_STATE_UTF and user
      space can enable this state with ATH10K_TM_CMD_UTF_START command. To go back to
      normal mode user space can send ATH10K_TM_CMD_UTF_STOP.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      43d2a30f
  5. 10 9月, 2014 1 次提交
    • M
      ath10k: move fw_crash_dump allocation · e13cf7a3
      Michal Kazior 提交于
      The fw_crash_data was allocated too late. Upon
      early firmware crash, before registering to
      mac80211, it was possible to crash the whole
      system:
      
       ath10k_pci 0000:00:05.0: device has crashed during init
       BUG: unable to handle kernel NULL pointer dereference at           (null)
       IP: [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core]
       PGD 0
       Oops: 0002 [#1] SMP
       Modules linked in: ath10k_pci(O) ath10k_core(O) ath [last unloaded: ath]
       CPU: 3 PID: 29 Comm: kworker/u8:1 Tainted: G           O   3.17.0-rc2-wl-ath+ #447
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
       task: ffff88001eb01ad0 ti: ffff88001eb60000 task.ti: ffff88001eb60000
       RIP: 0010:[<ffffffffa0058005>]  [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core]
       RSP: 0018:ffff88001eb63ce8  EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffffc90001a09030 RDI: 0000000000000001
       RBP: ffff88001eb63cf0 R08: 0000000000000000 R09: ffff8800000bb200
       R10: 00000000000001e2 R11: ffff88001eb638de R12: ffff88001d7459a0
       R13: ffff88001d746ab0 R14: 00000000fffe14d4 R15: ffff88001d747c60
       FS:  0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000000 CR3: 000000001df34000 CR4: 00000000000006e0
       Stack:
        ffff88001d7459a0 ffff88001eb63d58 ffffffffa0083bbe ffff880000000010
        ffff88001eb63d68 ffff88001eb63d18 0000000000000002 0000000000059010
        ffffffffa0086fef 00000000deadbeef ffff88001d747a28 ffff88001d7459a0
       Call Trace:
        [<ffffffffa0083bbe>] ath10k_pci_fw_crashed_dump+0x2e/0xd0 [ath10k_pci]
        [<ffffffffa0085410>] __ath10k_pci_hif_power_up+0x5f0/0x700 [ath10k_pci]
        [<ffffffffa0085550>] ath10k_pci_hif_power_up+0x30/0xe0 [ath10k_pci]
        [<ffffffffa005bc7b>] ath10k_core_register_work+0x2b/0x520 [ath10k_core]
        [<ffffffff810689cc>] process_one_work+0x18c/0x3f0
        [<ffffffff81069011>] worker_thread+0x121/0x4a0
        [<ffffffff81068ef0>] ? rescuer_thread+0x2c0/0x2c0
        [<ffffffff8106daf2>] kthread+0xd2/0xf0
        [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170
        [<ffffffff81857cfc>] ret_from_fork+0x7c/0xb0
        [<ffffffff8106da20>] ? kthread_create_on_node+0x170/0x170
       Code: 8b 40 38 48 c7 80 00 01 00 00 00 00 00 00 5b 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 8b 9f 90 1d 00 00 48 8d 7b 01 <c6> 03 01 e8 e3 ec 2b e1 48 8d 7b 18 e8 6a 4f 05 e1 48 89 d8 5b
       RIP  [<ffffffffa0058005>] ath10k_debug_get_new_fw_crash_data+0x15/0x30 [ath10k_core]
        RSP <ffff88001eb63ce8>
       CR2: 0000000000000000
       ---[ end trace 5d0ed15b050bcc1f ]---
       Kernel panic - not syncing: Fatal exception in interrupt
       Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
       ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      
      To prevent that split debug functions and allocate
      fw_crash_data earlier.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e13cf7a3
  6. 27 8月, 2014 1 次提交
  7. 25 8月, 2014 3 次提交
  8. 14 8月, 2014 1 次提交
  9. 12 8月, 2014 3 次提交
  10. 04 8月, 2014 1 次提交
    • S
      ath10k: add spectral scan feature · 855aed12
      Simon Wunderlich 提交于
      Adds the spectral scan feature for ath10k. The spectral scan is triggered by
      configuring a mode through a debugfs control file. Samples can be gathered via
      another relay debugfs file.
      
      Essentially, to try it out:
      
      ip link set dev wlan0 up
      echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      echo trigger > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      iw dev wlan0 scan
      echo disable > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
      cat /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan0 > samples
      
      This feature is still experimental. Based on the original RFC patch of
      Sven Eckelmann.
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      855aed12
  11. 29 7月, 2014 1 次提交
  12. 14 7月, 2014 1 次提交
    • M
      ath10k: fix unregister deadlock when fw probe fails · a491a920
      Michal Kazior 提交于
      If firmware probing worker failed it called
      device_release_driver() which synchronously called
      remove() pci callback. The callback in turn waited
      for the worker that called it to finish resulting
      in a deadlock.
      
      Waiting for a completion instead of a worker, like
      some other drivers do, doesn't seem like the best
      idea either:
      
        Syscall                 Worker
      
                                probe_fw()
        rmmod
        dev_lock()
        pci->remove()
        wait_for_completion()
                                complete_all()
                                device_release_driver()
                                dev_lock()
                                [sleep]
        free(ar)
        dev_unlock()
                                [resume]
      
      There's no guarantee that Worker upon resuming can
      still access any data/code of the module.
      
      Leaving device bound to a driver is not as harmful
      as deadlocking so remove the call to
      device_release_driver() while a proper solution is
      figured out.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a491a920
  13. 03 6月, 2014 2 次提交
  14. 27 5月, 2014 1 次提交
  15. 26 5月, 2014 2 次提交
  16. 23 5月, 2014 1 次提交
  17. 24 4月, 2014 1 次提交
  18. 28 3月, 2014 3 次提交
  19. 21 3月, 2014 2 次提交
  20. 13 2月, 2014 2 次提交
  21. 05 2月, 2014 1 次提交
  22. 20 11月, 2013 2 次提交
  23. 13 11月, 2013 1 次提交
  24. 08 11月, 2013 1 次提交
  25. 21 10月, 2013 1 次提交
  26. 16 10月, 2013 1 次提交
  27. 09 10月, 2013 1 次提交