Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 11月, 2020 3 次提交
  3. 24 11月, 2020 2 次提交
  5. 11 11月, 2020 1 次提交
  7. 06 11月, 2020 1 次提交
  9. 08 10月, 2020 1 次提交
  11. 02 10月, 2020 7 次提交
    • C
      ath11k: enable idle power save mode · c83c500b
      由 Carl Huang 提交于 
      Host sends wmi command to allow hardware enter idle power
save mode in ath11k_mac_op_start function.

hw parameter idle_ps indicates whether idle power save is supported.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NCarl Huang <cjhuang@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601544890-13450-8-git-send-email-kvalo@codeaurora.org
      c83c500b
    • W
      ath11k: mac: remove unused conf_mutex to solve a deadlock · 7fd85517
      由 Wen Gong 提交于 
      The conf_mutex is not use and lead below deadlock, remove it to solve
the deadlock issue.

[   44.967496] NET: Registered protocol family 42
[   45.119629] ath11k_pci 0000:06:00.0: WARNING: ath11k PCI support is experimental!
[   45.120087] ath11k_pci 0000:06:00.0: BAR 0: assigned [mem 0xdc000000-0xdc0fffff 64bit]
[   45.120108] ath11k_pci 0000:06:00.0: enabling device (0000 -> 0002)
[   45.206525] ath11k_pci 0000:06:00.0: aspm 0x42 changed to 0x40
[   45.207430] mhi 0000:06:00.0: Requested to power ON
[   45.208609] mhi 0000:06:00.0: Power on setup success
[   46.190711] ath11k_pci 0000:06:00.0: chip_id 0x0 chip_family 0xb board_id 0x101 soc_id 0xffffffff
[   46.190729] ath11k_pci 0000:06:00.0: fw_version 0x306a70f fw_build_timestamp 2000-01-01 00:00 fw_build_id
1]: Starting Load/Save RF Kill Switch Status...
[   46.385118] ath11k_pci 0000:06:00.0 wlp6s0: renamed from wlan0
1]: Started Load/Save RF Kill Switch Status.
[   53.566669] wlp6s0: authenticate with 00:03:7f:48:dd:bf
[   53.809092] wlp6s0: send auth to 00:03:7f:48:dd:bf (try 1/3)
[   53.816490] wlp6s0: authenticated
[   53.818618] wlp6s0: associate with 00:03:7f:48:dd:bf (try 1/3)
[   53.820839] wlp6s0: RX AssocResp from 00:03:7f:48:dd:bf (capab=0x1 status=0 aid=2)
[   53.834859]
[   53.834861] ======================================================
[   53.834862] WARNING: possible circular locking dependency detected
[   53.834863] 5.9.0-rc5-wt-ath+ #198 Not tainted
[   53.834864] ------------------------------------------------------
[   53.834865] kworker/u16:3/166 is trying to acquire lock:
[   53.834866] ffff8c4b37184f78 (&ar->conf_mutex){+.+.}-{3:3}, at: ath11k_mac_op_config+0x16/0x30 [ath11k]
[   53.834875]
[   53.834875] but task is already holding lock:
[   53.834876] ffff8c4b37182808 (&local->iflist_mtx){+.+.}-{3:3}, at: ieee80211_set_associated+0x167/0x360
[   53.834879]
[   53.834879] which lock already depends on the new lock.
[   53.834879]
[   53.834880]
[   53.834880] the existing dependency chain (in reverse order) is:
[   53.834881]
[   53.834881] -> #1 (&local->iflist_mtx){+.+.}-{3:3}:
[   53.834884]        __lock_acquire+0x3bf/0x6e0
[   53.834886]        lock_acquire+0xb6/0x270
[   53.834887]        __mutex_lock+0x88/0x8e0
[   53.834890]        ieee80211_set_hw_80211_encap+0x3e/0x1f0
[   53.834895]        ath11k_mac_op_add_interface+0x348/0x7f0 [ath11k]
[   53.834897]        drv_add_interface+0x7c/0x190
[   53.834899]        ieee80211_do_open+0x552/0x9a0
[   53.834901]        __dev_open+0xe5/0x190
[   53.834902]        __dev_change_flags+0x1c6/0x230
[   53.834903]        dev_change_flags+0x1c/0x50
[   53.834905]        do_setlink+0x246/0xc60
[   53.834906]        __rtnl_newlink+0x607/0x990
[   53.834907]        rtnl_newlink+0x3f/0x60
[   53.834908]        rtnetlink_rcv_msg+0x174/0x490
[   53.834910]        netlink_rcv_skb+0x42/0x100
[   53.834911]        netlink_unicast+0x18c/0x250
[   53.834912]        netlink_sendmsg+0x227/0x460
[   53.834914]        sock_sendmsg+0x59/0x60
[   53.834915]        ____sys_sendmsg+0x1f5/0x230
[   53.834916]        ___sys_sendmsg+0x70/0xb0
[   53.834917]        __sys_sendmsg+0x54/0xa0
[   53.834919]        do_syscall_64+0x33/0x40
[   53.834920]        entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   53.834921]
[   53.834921] -> #0 (&ar->conf_mutex){+.+.}-{3:3}:
[   53.834923]        check_prev_add+0x98/0x9f0
[   53.834925]        validate_chain+0x404/0x6c0
[   53.834926]        __lock_acquire+0x3bf/0x6e0
[   53.834927]        lock_acquire+0xb6/0x270
[   53.834929]        __mutex_lock+0x88/0x8e0
[   53.834934]        ath11k_mac_op_config+0x16/0x30 [ath11k]
[   53.834935]        ieee80211_hw_config+0xb3/0x270
[   53.834937]        ieee80211_set_associated+0x17c/0x360
[   53.834938]        ieee80211_assoc_success.constprop.0+0x5a2/0xc80
[   53.834940]        ieee80211_rx_mgmt_assoc_resp+0x16a/0x350
[   53.834941]        ieee80211_sta_rx_queued_mgmt+0xca/0x410
[   53.834943]        ieee80211_iface_work+0x1f3/0x350
[   53.834945]        process_one_work+0x265/0x5d0
[   53.834946]        worker_thread+0x49/0x300
[   53.834948]        kthread+0x135/0x150
[   53.834949]        ret_from_fork+0x22/0x30
[   53.834950]
[   53.834950] other info that might help us debug this:
[   53.834950]
[   53.834951]  Possible unsafe locking scenario:
[   53.834951]
[   53.834952]        CPU0                    CPU1
[   53.834952]        ----                    ----
[   53.834953]   lock(&local->iflist_mtx);
[   53.834954]                                lock(&ar->conf_mutex);
[   53.834955]                                lock(&local->iflist_mtx);
[   53.834956]   lock(&ar->conf_mutex);
[   53.834957]
[   53.834957]  *** DEADLOCK ***
[   53.834957]
[   53.834958] 4 locks held by kworker/u16:3/166:
[   53.834959]  #0: ffff8c4b37c22948 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0
[   53.834961]  #1: ffffa98300abfe70 ((work_completion)(&sdata->work)){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0
[   53.834963]  #2: ffff8c4b371e4cd0 (&wdev->mtx){+.+.}-{3:3}, at: ieee80211_sta_rx_queued_mgmt+0x4b/0x410
[   53.834965]  #3: ffff8c4b37182808 (&local->iflist_mtx){+.+.}-{3:3}, at: ieee80211_set_associated+0x167/0x360
[   53.834968]
[   53.834968] stack backtrace:
[   53.834969] CPU: 1 PID: 166 Comm: kworker/u16:3 Not tainted 5.9.0-rc5-wt-ath+ #198
[   53.834970] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018
[   53.834972] Workqueue: phy0 ieee80211_iface_work
[   53.834974] Call Trace:
[   53.834976]  dump_stack+0x77/0xa0
[   53.834978]  check_noncircular+0x15d/0x180
[   53.834980]  check_prev_add+0x98/0x9f0
[   53.834982]  ? add_chain_cache+0x143/0x440
[   53.834984]  validate_chain+0x404/0x6c0
[   53.834986]  __lock_acquire+0x3bf/0x6e0
[   53.834988]  lock_acquire+0xb6/0x270
[   53.834993]  ? ath11k_mac_op_config+0x16/0x30 [ath11k]
[   53.834999]  ? ath11k_mac_op_config+0x16/0x30 [ath11k]
[   53.835001]  __mutex_lock+0x88/0x8e0
[   53.835006]  ? ath11k_mac_op_config+0x16/0x30 [ath11k]
[   53.835007]  ? sched_clock_cpu+0xc/0xb0
[   53.835009]  ? __lock_release+0x179/0x2c0
[   53.835014]  ath11k_mac_op_config+0x16/0x30 [ath11k]
[   53.835016]  ieee80211_hw_config+0xb3/0x270
[   53.835018]  ieee80211_set_associated+0x17c/0x360
[   53.835019]  ieee80211_assoc_success.constprop.0+0x5a2/0xc80
[   53.835021]  ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140
[   53.835023]  ? cmpxchg_double_slab.constprop.0+0x185/0x1a0
[   53.835025]  ? trace_hardirqs_on+0x1c/0x100
[   53.835027]  ? __slab_free+0x8f/0x330
[   53.835029]  ? slab_free_freelist_hook+0xf8/0x150
[   53.835031]  ? ieee802_11_parse_elems_crc+0x147/0x1d0
[   53.835032]  ? kfree+0x2b0/0x2d0
[   53.835034]  ? ieee802_11_parse_elems_crc+0x147/0x1d0
[   53.835036]  ieee80211_rx_mgmt_assoc_resp+0x16a/0x350
[   53.835041]  ieee80211_sta_rx_queued_mgmt+0xca/0x410
[   53.835043]  ? __lock_acquire+0x3bf/0x6e0
[   53.835045]  ? lock_acquire+0xb6/0x270
[   53.835046]  ? skb_dequeue+0x13/0x70
[   53.835048]  ? find_held_lock+0x32/0x90
[   53.835049]  ? sched_clock_cpu+0xc/0xb0
[   53.835051]  ? mark_held_locks+0x50/0x80
[   53.835053]  ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140
[   53.835054]  ? _raw_spin_unlock_irqrestore+0x34/0x40
[   53.835056]  ? trace_hardirqs_on+0x1c/0x100
[   53.835058]  ieee80211_iface_work+0x1f3/0x350
[   53.835060]  process_one_work+0x265/0x5d0
[   53.835062]  worker_thread+0x49/0x300
[   53.835063]  ? process_one_work+0x5d0/0x5d0
[   53.835065]  kthread+0x135/0x150
[   53.835066]  ? kthread_create_worker_on_cpu+0x60/0x60
[   53.835068]  ret_from_fork+0x22/0x30
[   53.835075] wlp6s0: associated
[   53.835132] IPv6: ADDRCONF(NETDEV_CHANGE): wlp6s0: link becomes ready

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601463073-12106-4-git-send-email-kvalo@codeaurora.org
      7fd85517
    • C
      ath11k: add packet log support for QCA6390 · 701e48a4
      由 Carl Huang 提交于 
      Add packet log support for QCA6390, otherwise the data connection will stall
within a minute or so.  Enable it via debugfs and use trace-cmd to capture the
pktlogs.

echo 0xffff 1 > /sys/kernel/debug/ath11k/qca6390\ hw2.0/mac0/pktlog_filter

The mon status ring doesn't support interrupt so far, so host starts
a timer to reap this ring. The timer handler also reaps the
rxdma_err_dst_ring in case of monitor mode.

As QCA6390 requires bss created ahead of starting vdev, so check
vdev_start_delay for monitor mode.

For QCA6390, it uses wbm_desc_rel_ring to return descriptors.
It also uses rx_refill_buf_ring to fill mon buffer instead of
rxdma_mon_buf_ring.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NCarl Huang <cjhuang@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601463073-12106-2-git-send-email-kvalo@codeaurora.org
      701e48a4
    • K
      ath11k: disable monitor mode on QCA6390 · 3f6e6c32
      由 Kalle Valo 提交于 
      QCA6390 does not support monitor mode at the moment so disable it altogether,
using a hack as mac80211 does not support disabling it otherwise. Add a boolean
to hw_params to know if hardware supports monitor mode.

IPQ8074 continues to support monitor mode normally.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601399736-3210-6-git-send-email-kvalo@codeaurora.org
      3f6e6c32
    • K
      ath11k: add interface_modes to hw_params · 2626c269
      由 Kalle Valo 提交于 
      As QCA6390 does not support mesh interfaces, move the interface_modes to
hw_params. Also create interface combinations dynamically so that it's easy to
change the values.

Now QCA6390 does not claim to support mesh interfaces to user space, but
IPQ8074 continues to do that.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601399736-3210-4-git-send-email-kvalo@codeaurora.org
      2626c269
    • C
      ath11k: fix AP mode for QCA6390 · b0919924
      由 Carl Huang 提交于 
      For QCA6390, station vdev needs to delay startup but not for AP mode. On AP
mode vdev starts up immediately after bss peer is created in chanctx assignment
context.

This patch does not affect IPQ8074 family of devices.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: NCarl Huang <cjhuang@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601399736-3210-3-git-send-email-kvalo@codeaurora.org
      b0919924
    • K
      ath11k: mac: fix parenthesis alignment · cd19836a
      由 Kalle Valo 提交于 
      Commit 6aea26ce ("mac80211: rework tx encapsulation offload API")
introduced a new checkpatch warning:

drivers/net/wireless/ath/ath11k/mac.c:4354: Alignment should match open parenthesis

Fix that.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1601369160-1252-1-git-send-email-kvalo@codeaurora.org
      cd19836a
  13. 22 9月, 2020 2 次提交
  15. 18 9月, 2020 2 次提交
  17. 11 9月, 2020 1 次提交
  19. 09 9月, 2020 1 次提交
  21. 08 9月, 2020 1 次提交
    • T
      ath11k: fix a double free and a memory leak · 7e8453e3
      由 Tom Rix 提交于 
      clang static analyzer reports this problem

mac.c:6204:2: warning: Attempt to free released memory
        kfree(ar->mac.sbands[NL80211_BAND_2GHZ].channels);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The channels pointer is allocated in ath11k_mac_setup_channels_rates()
When it fails midway, it cleans up the memory it has already allocated.
So the error handling needs to skip freeing the memory.

There is a second problem.
ath11k_mac_setup_channels_rates(), allocates 3 channels. err_free
misses releasing ar->mac.sbands[NL80211_BAND_6GHZ].channels

Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: NTom Rix <trix@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200906212625.17059-1-trix@redhat.com
      7e8453e3
  23. 18 8月, 2020 4 次提交
  25. 31 7月, 2020 1 次提交
  27. 23 6月, 2020 2 次提交
  29. 15 6月, 2020 2 次提交
  31. 11 6月, 2020 3 次提交
  33. 30 5月, 2020 2 次提交
  35. 12 5月, 2020 1 次提交
  37. 06 5月, 2020 1 次提交
  39. 04 5月, 2020 2 次提交