Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 9月, 2014 3 次提交
  3. 23 9月, 2014 10 次提交
  5. 18 9月, 2014 10 次提交
  7. 12 9月, 2014 4 次提交
  9. 10 9月, 2014 3 次提交
    • M
      ath10k: ATH10K_DEBUGFS depends on DEBUG_FS · ca5c671f
      由 Matteo Croce 提交于 
      ATH10K_DEBUGFS must depend on DEBUG_FS, otherwise
ath10k will generate an invalid pointer on module load.
Signed-off-by: NMatteo Croce <matteo@openwrt.org>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ca5c671f
    • M
      ath10k: use proper service bitmap size · c4f8c836
      由 Michal Kazior 提交于 
      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: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c4f8c836
    • 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
  11. 02 9月, 2014 8 次提交
  13. 29 8月, 2014 2 次提交
    • A
      carl9170: tx: Replace rcu_assign_pointer() with RCU_INIT_POINTER() · 6a5d088a
      由 Andreea-Cristina Bernat 提交于 
      According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3.   The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
 a.   You have not made -any- reader-visible changes to this structure since
then".

This case fulfills the conditions above because between the rcu_dereference()
call (cvif = rcu_dereference(ar->beacon_iter);) and the rcu_assign_pointer()
call there is no update of the "cvif" variable.
Therefore, this patch makes the replacement.

The following Coccinelle semantic patch was used:
@@
identifier v;
@@

v = rcu_dereference(...);
... when != rcu_dereference(...);
    when != v = ...;
    when != (<+...v...+>)++;
    when != \(memcpy\|memset\)(...);
(
- rcu_assign_pointer
+ RCU_INIT_POINTER
  (..., v);
|
 if(...) {
... when != v = ...;
- rcu_assign_pointer
+ RCU_INIT_POINTER
  (..., v);
... when any
 }
)

Because there are cases where between a “rcu_dereference()” call and a
“rcu_assign_pointer()” call might be updates of the value that interests us,
the Coccinelle semantic patch ignores them and replaces with
"RCU_INIT_POINTER()" only when the update is not happening.
Signed-off-by: NAndreea-Cristina Bernat <bernat.ada@gmail.com>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6a5d088a
    • S
      ath9k: Fix channel context timer · 1a7c5b7e
      由 Sujith Manoharan 提交于 
      Setup the channel context correctly. Not doing this was
causing beacon loss in a P2P-GO/STA concurrent setup.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1a7c5b7e