1. 23 Sep, 2014 3 commits
    • Michal Kazior's avatar
      ath10k: remove unused pdev_set_channel command · 1435c2bb
      Michal Kazior authored
      This command is not used anymore and most firmware
      revisions do not seem to handle it well. Channel
      switching is done via vdev restarting.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      1435c2bb
    • Michal Kazior's avatar
      ath10k: fix tx/rx chainmask init · fdb959c7
      Michal Kazior authored
      Firmware reports the number of RF chains so use
      that for initialization of supp_{tx,rx}_chainmask
      instead of using a macro for 3x3 chips.
      
      This should make tx/rx chainmask reports correct
      for chips other than 3x3.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      fdb959c7
    • Michal Kazior's avatar
      ath10k: workaround fw beaconing bug · 64badcb6
      Michal Kazior authored
      Some firmware revisions don't wait for beacon tx
      completion before sending another SWBA event. This
      could lead to hardware using old (freed) beacon
      data in some cases, e.g. tx credit starvation
      combined with missed TBTT. This is very very rare.
      
      On non-IOMMU-enabled hosts this could be a
      possible security issue because hw could beacon
      some random data on the air.  On IOMMU-enabled
      hosts DMAR faults would occur in most cases and
      target device would crash.
      
      Since there are no beacon tx completions (implicit
      nor explicit) propagated to host the only
      workaround for this is to allocate a DMA-coherent
      buffer for a lifetime of a vif and use it for all
      beacon tx commands. Worst case for this approach
      is some beacons may become corrupted, e.g. garbled
      IEs or out-of-date TIM bitmap.
      
      Keep the original beacon-related code as-is in
      case future firmware revisions solve this problem
      so that the old path can be easily re-enabled with
      a fw_feature flag.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      64badcb6
  2. 18 Sep, 2014 10 commits
  3. 11 Sep, 2014 4 commits
  4. 10 Sep, 2014 3 commits
    • Matteo Croce's avatar
      ath10k: ATH10K_DEBUGFS depends on DEBUG_FS · ca5c671f
      Matteo Croce authored
      ATH10K_DEBUGFS must depend on DEBUG_FS, otherwise
      ath10k will generate an invalid pointer on module load.
      Signed-off-by: default avatarMatteo Croce <matteo@openwrt.org>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ca5c671f
    • Michal Kazior's avatar
      ath10k: use proper service bitmap size · c4f8c836
      Michal Kazior authored
      On 32bit systems the bitmap was too small and it
      was overwritten partially by the stat completion
      structure. This was visible with 10.2 firmware
      only due to it using a few of the last service
      ids.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      c4f8c836
    • Michal Kazior's avatar
      ath10k: move fw_crash_dump allocation · e13cf7a3
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      e13cf7a3
  5. 02 Sep, 2014 8 commits
  6. 28 Aug, 2014 12 commits