Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 4月, 2021 1 次提交
  3. 24 2月, 2021 1 次提交
    • K
      ath11k: fix AP mode for QCA6390 · 77d7e871
      由 Kalle Valo 提交于 
      Commit c134d1f8 ("ath11k: Handle errors if peer creation fails") completely
broke AP mode on QCA6390:

kernel: [  151.230734] ath11k_pci 0000:06:00.0: failed to create peer after vdev start delay: -22
wpa_supplicant[2307]: Failed to set beacon parameters
wpa_supplicant[2307]: Interface initialization failed
wpa_supplicant[2307]: wlan0: interface state UNINITIALIZED->DISABLED
wpa_supplicant[2307]: wlan0: AP-DISABLED
wpa_supplicant[2307]: wlan0: Unable to setup interface.
wpa_supplicant[2307]: Failed to initialize AP interface

This was because commit c134d1f8 ("ath11k: Handle errors if peer creation
fails") added error handling for ath11k_peer_create(), which had been failing
all along but was unnoticed due to the missing error handling. The actual bug
was introduced already in commit aa44b2f3 ("ath11k: start vdev if a bss peer is
already created").

ath11k_peer_create() was failing because for AP mode the peer is created
already earlier op_add_interface() and we should skip creation here, but the
check for modes was wrong.  Fixing that makes AP mode work again.

This shouldn't affect IPQ8074 nor QCN9074 as they have hw_params.vdev_start_delay disabled.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1

Fixes: c134d1f8 ("ath11k: Handle errors if peer creation fails")
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1614006849-25764-1-git-send-email-kvalo@codeaurora.org
      77d7e871
  5. 11 2月, 2021 1 次提交
  7. 10 2月, 2021 1 次提交
  9. 04 2月, 2021 1 次提交
  11. 27 1月, 2021 1 次提交
    • W
      ath11k: add ieee80211_unregister_hw to avoid kernel crash caused by NULL pointer · 0d969683
      由 Wen Gong 提交于 
      When function return fail to __ath11k_mac_register after success called
ieee80211_register_hw, then it set wiphy->dev.parent to NULL by
SET_IEEE80211_DEV(ar->hw, NULL) in end of __ath11k_mac_register, then
cfg80211_get_drvinfo will be called by below call stack, but the
wiphy->dev.parent is NULL, so kernel crash.

Call stack to cfg80211_get_drvinfo:
NetworkManager   826 [001]  6696.731371:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)
        ffffffffc107d8f1 cfg80211_get_drvinfo+0x1 (/lib/modules/5.10.0-rc1-wt-ath+/kernel/net/wireless-back/cfg80211.ko)
        ffffffff9d8fc529 ethtool_get_drvinfo+0x99 (vmlinux)
        ffffffff9d90080e dev_ethtool+0x1dbe (vmlinux)
        ffffffff9d8b88f7 dev_ioctl+0xb7 (vmlinux)
        ffffffff9d8668de sock_do_ioctl+0xae (vmlinux)
        ffffffff9d866d60 sock_ioctl+0x350 (vmlinux)
        ffffffff9d2ca30e __x64_sys_ioctl+0x8e (vmlinux)
        ffffffff9da0dda3 do_syscall_64+0x33 (vmlinux)
        ffffffff9dc0008c entry_SYSCALL_64_after_hwframe+0x44 (vmlinux)
            7feb5f673007 __GI___ioctl+0x7 (/lib/x86_64-linux-gnu/libc-2.23.so)
                       0 [unknown] ([unknown])

Code of cfg80211_get_drvinfo, the pdev which is wiphy->dev.parent is
NULL when kernel crash:
void cfg80211_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
{
	struct wireless_dev *wdev = dev->ieee80211_ptr;
	struct device *pdev = wiphy_dev(wdev->wiphy);

	if (pdev->driver)
....

kernel crash log:
[  973.619550] ath11k_pci 0000:05:00.0: failed to perform regd update : -16
[  973.619555] ath11k_pci 0000:05:00.0: ath11k regd update failed: -16
[  973.619566] ath11k_pci 0000:05:00.0: failed register the radio with mac80211: -16
[  973.619618] ath11k_pci 0000:05:00.0: failed to create pdev core: -16
[  973.636035] BUG: kernel NULL pointer dereference, address: 0000000000000068
[  973.636046] #PF: supervisor read access in kernel mode
[  973.636050] #PF: error_code(0x0000) - not-present page
[  973.636054] PGD 800000012452e067 P4D 800000012452e067 PUD 12452d067 PMD 0
[  973.636064] Oops: 0000 [#1] SMP PTI
[  973.636072] CPU: 3 PID: 848 Comm: NetworkManager Kdump: loaded Tainted: G        W  OE     5.10.0-rc1-wt-ath+ #24
[  973.636076] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011
[  973.636161] RIP: 0010:cfg80211_get_drvinfo+0x25/0xd0 [cfg80211]
[  973.636169] Code: e9 c9 fe ff ff 66 66 66 66 90 55 53 ba 20 00 00 00 48 8b af 08 03 00 00 48 89 f3 48 8d 7e 04 48 8b 45 00 48 8b 80 90 01 00 00 <48> 8b 40 68 48 85 c0 0f 84 8d 00 00 00 48 8b 30 e8 a6 cc 72 c7 48
[  973.636174] RSP: 0018:ffffaafb4040bbe0 EFLAGS: 00010286
[  973.636180] RAX: 0000000000000000 RBX: ffffaafb4040bbfc RCX: 0000000000000000
[  973.636184] RDX: 0000000000000020 RSI: ffffaafb4040bbfc RDI: ffffaafb4040bc00
[  973.636188] RBP: ffff8a84c9568950 R08: 722d302e30312e35 R09: 74612d74772d3163
[  973.636192] R10: 3163722d302e3031 R11: 2b6874612d74772d R12: ffffaafb4040bbfc
[  973.636196] R13: 00007ffe453707c0 R14: ffff8a84c9568000 R15: 0000000000000000
[  973.636202] FS:  00007fd3d179b940(0000) GS:ffff8a84fa2c0000(0000) knlGS:0000000000000000
[  973.636206] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  973.636211] CR2: 0000000000000068 CR3: 00000001153b6002 CR4: 00000000000606e0
[  973.636215] Call Trace:
[  973.636234]  ethtool_get_drvinfo+0x99/0x1f0
[  973.636246]  dev_ethtool+0x1dbe/0x2be0
[  973.636256]  ? mntput_no_expire+0x35/0x220
[  973.636264]  ? inet_ioctl+0x1ce/0x200
[  973.636274]  ? tomoyo_path_number_perm+0x68/0x1d0
[  973.636282]  ? kmem_cache_alloc+0x3cb/0x430
[  973.636290]  ? dev_ioctl+0xb7/0x570
[  973.636295]  dev_ioctl+0xb7/0x570
[  973.636307]  sock_do_ioctl+0xae/0x150
[  973.636315]  ? sock_ioctl+0x350/0x3c0
[  973.636319]  sock_ioctl+0x350/0x3c0
[  973.636332]  ? __x64_sys_ioctl+0x8e/0xd0
[  973.636339]  ? dlci_ioctl_set+0x30/0x30
[  973.636346]  __x64_sys_ioctl+0x8e/0xd0
[  973.636359]  do_syscall_64+0x33/0x80
[  973.636368]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Sequence of function call when wlan load for success case when function
__ath11k_mac_register return 0:

kworker/u16:3-e  2922 [001]  6696.729734:   probe:ieee80211_register_hw: (ffffffffc116ae60)
kworker/u16:3-e  2922 [001]  6696.730210:        probe:ieee80211_if_add: (ffffffffc1185cc0)
NetworkManager   826 [001]  6696.731345:     probe:ethtool_get_drvinfo: (ffffffff9d8fc490)
NetworkManager   826 [001]  6696.731371:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)
NetworkManager   826 [001]  6696.731639:     probe:ethtool_get_drvinfo: (ffffffff9d8fc490)
NetworkManager   826 [001]  6696.731653:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)
NetworkManager   826 [001]  6696.732866:     probe:ethtool_get_drvinfo: (ffffffff9d8fc490)
NetworkManager   826 [001]  6696.732893:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)
systemd-udevd  3850 [003]  6696.737199:     probe:ethtool_get_drvinfo: (ffffffff9d8fc490)
systemd-udevd  3850 [003]  6696.737226:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)
NetworkManager   826 [000]  6696.759950:     probe:ethtool_get_drvinfo: (ffffffff9d8fc490)
NetworkManager   826 [000]  6696.759967:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)
NetworkManager   826 [000]  6696.760057:     probe:ethtool_get_drvinfo: (ffffffff9d8fc490)
NetworkManager   826 [000]  6696.760062:    probe:cfg80211_get_drvinfo: (ffffffffc107d8f0)

After apply this patch, kernel crash gone, and below is the test case's
sequence of function call and log when wlan load with fail by function
ath11k_regd_update, and __ath11k_mac_register return fail:

kworker/u16:5-e   192 [001]   215.174388:   probe:ieee80211_register_hw: (ffffffffc1131e60)
kworker/u16:5-e   192 [000]   215.174973:        probe:ieee80211_if_add: (ffffffffc114ccc0)
NetworkManager   846 [001]   215.175857:     probe:ethtool_get_drvinfo: (ffffffff928fc490)
kworker/u16:5-e   192 [000]   215.175867: probe:ieee80211_unregister_hw: (ffffffffc1131970)
NetworkManager   846 [001]   215.175880:    probe:cfg80211_get_drvinfo: (ffffffffc107f8f0)
NetworkManager   846 [001]   215.176105:     probe:ethtool_get_drvinfo: (ffffffff928fc490)
NetworkManager   846 [001]   215.176118:    probe:cfg80211_get_drvinfo: (ffffffffc107f8f0)
[  215.175859] ath11k_pci 0000:05:00.0: ath11k regd update failed: -16
NetworkManager   846 [001]   215.196420:     probe:ethtool_get_drvinfo: (ffffffff928fc490)
NetworkManager   846 [001]   215.196430:    probe:cfg80211_get_drvinfo: (ffffffffc107f8f0)
[  215.258598] ath11k_pci 0000:05:00.0: failed register the radio with mac80211: -16
[  215.258613] ath11k_pci 0000:05:00.0: failed to create pdev core: -16

When ath11k_regd_update or ath11k_debugfs_register return fail, function
ieee80211_unregister_hw of mac80211 will be called, then it will wait
untill cfg80211_get_drvinfo finished, the wiphy->dev.parent is not NULL
at this moment, after that, it set wiphy->dev.parent to NULL by
SET_IEEE80211_DEV(ar->hw, NULL) in end of __ath11k_mac_register, so
not happen kernel crash.

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/1608607824-16067-1-git-send-email-wgong@codeaurora.org
      0d969683
  13. 17 12月, 2020 1 次提交
  15. 12 12月, 2020 1 次提交
  17. 09 12月, 2020 3 次提交
  19. 03 12月, 2020 2 次提交
    • S
      ath11k: Reset ath11k_skb_cb before setting new flags · 5da7acfe
      由 Sven Eckelmann 提交于 
      It was observed that the codepath for the ATH11K_SKB_HW_80211_ENCAP was
used even when the IEEE80211_TX_CTRL_HW_80211_ENCAP was not enabled for a
an skbuff. This became even more prominent when the QCAs wlan-open patchset
for ath11k [1] was applied and a sane looking fix just caused crashes when
injecting frames via a monitor interface (for example with ratechecker):

  [   86.963152] Unable to handle kernel NULL pointer dereference at virtual address 00000338
  [   86.963192] pgd = ffffffc0008f0000
  [   86.971034] [00000338] *pgd=0000000051706003, *pud=0000000051706003, *pmd=0000000051707003, *pte=00e800000b000707
  [   86.984292] Internal error: Oops: 96000006 [#1] PREEMPT SMP
  [...]
  [   87.713339] [<ffffffbffc802480>] ieee80211_tx_status_8023+0xf8/0x220 [mac80211]
  [   87.715654] [<ffffffbffc98bad4>] ath11k_dp_tx_completion_handler+0x42c/0xa10 [ath11k]
  [   87.722924] [<ffffffbffc989190>] ath11k_dp_service_srng+0x70/0x3c8 [ath11k]
  [   87.730831] [<ffffffbffca03460>] 0xffffffbffca03460
  [   87.737599] [<ffffffc00046ef58>] net_rx_action+0xf8/0x288
  [   87.742462] [<ffffffc000097554>] __do_softirq+0xfc/0x220
  [   87.748014] [<ffffffc000097900>] irq_exit+0x98/0xe8
  [   87.753396] [<ffffffc0000cf188>] __handle_domain_irq+0x90/0xb8
  [   87.757999] [<ffffffc000081ca4>] gic_handle_irq+0x6c/0xc8
  [   87.763899] Exception stack(0xffffffc00081bdc0 to 0xffffffc00081bef0)

Problem is that the state of ath11k_skb_cb->flags must be considered
unknown and could contain anything when it is not manually initialized. So
it could also contain ATH11K_SKB_HW_80211_ENCAP. And this can result in the
code to assume that the ath11k_skb_cb->vif is set - even when this is not
always the case for non ATH11K_SKB_HW_80211_ENCAP transmissions.

Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2

[1] https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches?h=NHSS.QSDK.11.4.r3
    (162 patches at the moment which are often not upstreamed but essential
     to get ath11k working)

Fixes: e7f33e0c ("ath11k: add tx hw 802.11 encapsulation offloading support")
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201119154235.263250-2-sven@narfation.org
      5da7acfe
    • S
      ath11k: Don't cast ath11k_skb_cb to ieee80211_tx_info.control · f4d291b4
      由 Sven Eckelmann 提交于 
      The driver_data area of ieee80211_tx_info is used in ath11k for
ath11k_skb_cb. The first function in the TX patch which rewrites it to
ath11k_skb_cb is already ath11k_mac_op_tx. No one else in the code path
must use it for something else before it reinitializes it. Otherwise the
data has to be considered uninitialized or corrupt.

But the ieee80211_tx_info.control shares exactly the same area as
ieee80211_tx_info.driver_data and ath11k is still using it. This results in
best case in a

  ath11k c000000.wifi1: no vif found for mgmt frame, flags 0x0

or (slightly worse) in a kernel oops.

Instead, the interesting data must be moved first into the ath11k_skb_cb
and ieee80211_tx_info.control must then not be used anymore.

Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2

Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201119154235.263250-1-sven@narfation.org
      f4d291b4
  21. 25 11月, 2020 3 次提交
  23. 24 11月, 2020 2 次提交
  25. 11 11月, 2020 1 次提交
  27. 06 11月, 2020 1 次提交
  29. 08 10月, 2020 1 次提交
  31. 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
  33. 22 9月, 2020 2 次提交
  35. 18 9月, 2020 2 次提交
  37. 11 9月, 2020 1 次提交
  39. 09 9月, 2020 1 次提交
  41. 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
  43. 18 8月, 2020 4 次提交
  45. 31 7月, 2020 1 次提交