summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath
AgeCommit message (Collapse)AuthorFilesLines
2022-06-08ath10k: fix recently introduced checkpatch warningKalle Valo2-3/+3
I updated my checkpatch and saw new warnings: drivers/net/wireless/ath/ath10k/qmi.c:593: Prefer strscpy over strlcpy - see: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ drivers/net/wireless/ath/ath10k/qmi.c:598: Prefer strscpy over strlcpy - see: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ drivers/net/wireless/ath/ath10k/htt_rx.c:3565: Integer promotion: Using 'h' in '%04hx' is unnecessary Compile tested only. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220606142957.23721-1-kvalo@kernel.org
2022-06-06ath11k: Fix warnings reported by checkpatchManikanta Pubbisetty4-6/+6
Fix warnings reported by checkpatch tool. Below are the errors fixed, drivers/net/wireless/ath/ath11k/hal_rx.c:760: 'recevied' may be misspelled - perhaps 'received? drivers/net/wireless/ath/ath11k/qmi.c:2232: Prefer strscpy over strlcpy drivers/net/wireless/ath/ath11k/qmi.c:2238: Prefer strscpy over strlcpy drivers/net/wireless/ath/ath11k/qmi.c:2662: Prefer strscpy over strlcpy drivers/net/wireless/ath/ath11k/mac.c:7836: 'atleast' may be misspelled - perhaps 'at least'? drivers/net/wireless/ath/ath11k/wmi.c:6566: 'succeded' may be misspelled - perhaps 'succeeded'? Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220602131350.29486-1-quic_mpubbise@quicinc.com
2022-06-06ath11k: Fix LDPC config in set_bitrate_mask hookManikanta Pubbisetty2-3/+3
Currently ar->ht_cap_info is not set anywhere in the code, this could result in LDPC config computed wrongly in the set_bitrate_mask() hook and eventually sending wrong config to the target. Fix this by checking the LDPC support from the band HT capabilities of the radio instead. Furthermore, it looks like firmwares running on the ath11k hardware do not set WMI_HT_CAP_LDPC for advertising the TX LDPC capability, WMI_HT_CAP_TX_LDPC is set instead and this should be checked for getting hardware's TX LDPC support. This is true for QCA6390, WCN6855 & WCN6750 hardware. Also, remove unused variables ht_cap_info & vht_cap_info from struct ath11k{}. Found this during code review. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220602124142.29909-1-quic_mpubbise@quicinc.com
2022-06-06ath11k: Avoid REO CMD failed prints during firmware recoveryManikanta Pubbisetty1-2/+3
Currently when firmware recovery is in progress, we do not queue REO commands to the firmware, instead -ESHUTDOWN will be returned to the caller leading to a failure print on the console. The REO command in the problem scenario is sent for all tids of a peer in which case we will have 16 failure prints on the console for a single peer. For an AP usecase, this count would be even higher in a worst case scenario. Since these commands are bound to fail during firmware recovery, it is better to avoid printing these failures and thereby avoid message flooding on the console. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Fixes: 8ee8d38ca472 ("ath11k: Fix crash during firmware recovery on reo cmd ring access") Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220602122929.18896-1-quic_mpubbise@quicinc.com
2022-06-06ath11k: Fix incorrect debug_mask mappingsManikanta Pubbisetty1-2/+2
Currently a couple of debug_mask entries are mapped to the same value, this could enable unintended driver logging. If enabling DP_TX logs was the intention, then this could also enable PCI logs flooding the dmesg buffer or vice versa. Fix this by correctly assigning the debug masks. Found during code review. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Fixes: aa2092a9bab3f ("ath11k: add raw mode and software crypto support") Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220602115621.15339-1-quic_mpubbise@quicinc.com
2022-06-06ath11k: fix missing skb drop on htc_tx_completion errorChristian 'Ansuel' Marangi1-1/+3
On htc_tx_completion error the skb is not dropped. This is wrong since the completion_handler logic expect the skb to be consumed anyway even when an error is triggered. Not freeing the skb on error is a memory leak since the skb won't be freed anywere else. Correctly free the packet on eid >= ATH11K_HTC_EP_COUNT before returning. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 Fixes: f951380a6022 ("ath11k: Disabling credit flow for WMI path") Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220528142516.20819-2-ansuelsmth@gmail.com
2022-05-30ath10k: fix regdomain info of iw reg set/getWen Gong1-1/+2
When wlan load, firmware report the reg code with 0x6C for QCA6174, it is world reg which checked by ath_is_world_regd(), then the reg will be save into reg_world_copy of ath_common in ath_regd_init(). Later the regulatory of ath_common is updated to another country code such as "US" in ath_reg_notifier_apply() by below call stack. After that, regulatory_hint() is called in ath10k_mac_register() and it lead "iw reg get" show two regdomain info as below. global country US: DFS-FCC (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A) (57240 - 71000 @ 2160), (N/A, 40), (N/A) phy#0 country US: DFS-FCC (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A) (57240 - 71000 @ 2160), (N/A, 40), (N/A) [ 4255.704975] Call Trace: [ 4255.704983] ath_reg_notifier_apply+0xa6/0xc5 [ath] [ 4255.704991] ath10k_reg_notifier+0x2f/0xd2 [ath10k_core] [ 4255.705010] wiphy_regulatory_register+0x5f/0x69 [cfg80211] [ 4255.705020] wiphy_register+0x459/0x8f0 [cfg80211] [ 4255.705042] ? ieee80211_register_hw+0x3a6/0x7d1 [mac80211] [ 4255.705049] ? __kmalloc+0xf4/0x218 [ 4255.705058] ? ieee80211_register_hw+0x3a6/0x7d1 [mac80211] [ 4255.705066] ? ath10k_mac_register+0x70/0xaab [ath10k_core] [ 4255.705075] ieee80211_register_hw+0x51a/0x7d1 [mac80211] [ 4255.705084] ath10k_mac_register+0x8b4/0xaab [ath10k_core] [ 4255.705094] ath10k_core_register_work+0xa5e/0xb45 [ath10k_core] [ 4255.705100] ? __schedule+0x61f/0x7d3 [ 4255.705105] process_one_work+0x1b7/0x392 [ 4255.705109] worker_thread+0x271/0x35d [ 4255.705112] ? pr_cont_work+0x58/0x58 [ 4255.705116] kthread+0x13f/0x147 [ 4255.705119] ? pr_cont_work+0x58/0x58 [ 4255.705123] ? kthread_destroy_worker+0x62/0x62 [ 4255.705126] ret_from_fork+0x22/0x40 At this moment, the two regdomain info is same, when run "iw reg set KR", the global regdomain info changed to KR, but the regdomain of phy#0 does not change again. It leads inconsistent values between global and phy#0 as below. global country KR: DFS-JP (2402 - 2482 @ 40), (N/A, 13), (N/A) (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW (5490 - 5710 @ 160), (N/A, 30), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57000 - 66000 @ 2160), (N/A, 43), (N/A) phy#0 country US: DFS-FCC (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A) (57240 - 71000 @ 2160), (N/A, 40), (N/A) The initial reg code is 0x6C which saved in reg_world_copy of ath_common, and the code US is updated from cfg80211 later, so ath10k should also check the initial reg code before regulatory_hint(). After this fix, regdomain info is same between "iw reg get" and "iw reg set xx", it does not have the regdomain info of phy#0 again. global country KR: DFS-JP (2402 - 2482 @ 40), (N/A, 13), (N/A) (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW (5490 - 5710 @ 160), (N/A, 30), (0 ms), DFS (5735 - 5835 @ 80), (N/A, 30), (N/A) (57000 - 66000 @ 2160), (N/A, 43), (N/A) This does not effect the channel list and power which ath10k used. When the country code for regulatory_hint() in ath10k_mac_register() is same with the global country code, then reg_set_rd_driver() of cfg80211 called from crda which return -EALREADY to set_regdom() and then update_all_wiphy_regulatory() will not be called while wlan load. When run "iw reg set xx", reg_get_regdomain() which used by function handle_channel() in net/wirelss/reg.c always use the regdomain returned by get_cfg80211_regdom() because the initiator of last regulatory_request is NL80211_REGDOM_SET_BY_USER, get_cfg80211_regdom() is the global regdomain, then all the ieee80211_channel info is updated in handle_channel() with the global regdomain. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049 Tested-on: QCA9984 hw1.0 PCI 10.4-3.6-00104 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220525132247.23459-1-quic_wgong@quicinc.com
2022-05-30ath11k: support avg signal in station dumpThiraviyam Mariyappan3-0/+12
Currently mac80211 doesn't calculate average signal when RSS(Receive side scaling) is enabled from the driver, so average signal isn't printed in the station dump. To address this issue, calculate the average signal from RSSI within driver and display in the station dump. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 Signed-off-by: Thiraviyam Mariyappan <quic_tmariyap@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1652965061-30457-1-git-send-email-quic_tmariyap@quicinc.com
2022-05-30ath11k: fix IRQ affinity warning on shutdownJohan Hovold1-0/+2
Make sure to clear the IRQ affinity hint also on shutdown to avoid triggering a WARN_ON_ONCE() in __free_irq() when stopping MHI while using a single MSI vector. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: e94b07493da3 ("ath11k: Set IRQ affinity to CPU0 in case of one MSI vector") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220523143258.24818-1-johan+linaro@kernel.org
2022-05-30ath6kl: fix typo in commentJulia Lawall1-1/+1
Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220521111145.81697-14-Julia.Lawall@inria.fr
2022-05-30ath11k: fix netdev open raceJohan Hovold1-8/+8
Make sure to allocate resources needed before registering the device. This specifically avoids having a racing open() trigger a BUG_ON() in mod_timer() when ath11k_mac_op_start() is called before the mon_reap_timer as been set up. I did not see this issue with next-20220310, but I hit it on every probe with next-20220511. Perhaps some timing changed in between. Here's the backtrace: [ 51.346947] kernel BUG at kernel/time/timer.c:990! [ 51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ... [ 51.578225] Call trace: [ 51.583293] __mod_timer+0x298/0x390 [ 51.589518] mod_timer+0x14/0x20 [ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k] [ 51.603165] drv_start+0x38/0x60 [mac80211] [ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211] [ 51.617945] ieee80211_open+0x60/0xb0 [mac80211] [ 51.625311] __dev_open+0x100/0x1c0 [ 51.631420] __dev_change_flags+0x194/0x210 [ 51.638214] dev_change_flags+0x24/0x70 [ 51.644646] do_setlink+0x228/0xdb0 [ 51.650723] __rtnl_newlink+0x460/0x830 [ 51.657162] rtnl_newlink+0x4c/0x80 [ 51.663229] rtnetlink_rcv_msg+0x124/0x390 [ 51.669917] netlink_rcv_skb+0x58/0x130 [ 51.676314] rtnetlink_rcv+0x18/0x30 [ 51.682460] netlink_unicast+0x250/0x310 [ 51.688960] netlink_sendmsg+0x19c/0x3e0 [ 51.695458] ____sys_sendmsg+0x220/0x290 [ 51.701938] ___sys_sendmsg+0x7c/0xc0 [ 51.708148] __sys_sendmsg+0x68/0xd0 [ 51.714254] __arm64_sys_sendmsg+0x28/0x40 [ 51.720900] invoke_syscall+0x48/0x120 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Fixes: 840c36fa727a ("ath11k: dp: stop rx pktlog before suspend") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220517103436.15867-1-johan+linaro@kernel.org
2022-05-24ath6kl: Use cc-disable-warning to disable -Wdangling-pointerNathan Chancellor1-1/+1
Clang does not support this option so the build fails: error: unknown warning option '-Wno-dangling-pointer' [-Werror,-Wunknown-warning-option] Use cc-disable-warning so that the option is only added when it is supported. Fixes: bd1d129daa3e ("wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12") Reported-by: "kernelci.org bot" <bot@kernelci.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220524145655.869822-1-nathan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-23wifi: carl9170: silence a GCC 12 -Warray-bounds warningJakub Kicinski1-0/+5
carl9170 has a big union (struct carl9170_cmd) with all the command types in it. But it allocates buffers only large enough for a given command. This upsets GCC 12: drivers/net/wireless/ath/carl9170/cmd.c:125:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[8]’ [-Warray-bounds] 125 | tmp->hdr.cmd = cmd; | ~~~~~~~~~~~~~^~~~~ Punt the warning to W=1 for now. Hopefully GCC will learn to recognize which fields are in-bounds. Acked-by: Christian Lamparter <chunkeey@gmail.com> Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-23wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12Jakub Kicinski1-0/+5
For some reason GCC 12 decided to complain about the common pattern of queuing an object onto a list on the stack in ath6k: inlined from ‘ath6kl_htc_mbox_tx’ at drivers/net/wireless/ath/ath6kl/htc_mbox.c:1142:3: include/linux/list.h:74:19: warning: storing the address of local variable ‘queue’ in ‘*&packet_15(D)->list.prev’ [-Wdangling-pointer=] 74 | new->prev = prev; | ~~~~~~~~~~^~~~~~ Move the warning to W=1, hopefully it goes away with a compiler update. Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-23wifi: ath9k: silence array-bounds warning on GCC 12Jakub Kicinski1-0/+5
GCC 12 says: drivers/net/wireless/ath/ath9k/mac.c: In function ‘ath9k_hw_resettxqueue’: drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is above array bounds of ‘struct ath9k_tx_queue_info[10]’ [-Warray-bounds] 373 | qi = &ah->txq[q]; | ~~~~~~~^~~ I don't know where it got the 32 from, relegate the warning to W=1+. Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-22ath9k: replace ternary operator with max()Guo Zhengkui1-1/+1
Fix the following coccicheck warning: drivers/net/wireless/ath/ath9k/dfs.c:249:28-30: WARNING opportunity for max() Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220517024106.77050-1-guozhengkui@vivo.com
2022-05-22ath11k: Init hw_params before setting up AHB resourcesManikanta Pubbisetty1-2/+2
As part of adding the support of WCN6750 to ath11k, bus_params were moved to hw_params and this regressed the initialization of WCN6750. By the time AHB resources are setup for WCN6750, hw_params will not be initialized and therefore initialization for WCN6750 will fail. This is applicable only for WCN6750, no other device is impacted. Fix this by moving the initialization of hw_params before setting up AHB resources. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device") Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220517055241.15885-1-quic_mpubbise@quicinc.com
2022-05-22ath5k: replace ternary operator with min()Guo Zhengkui1-1/+1
Fix the following coccicheck warning: drivers/net/wireless/ath/ath5k/phy.c:3139:62-63: WARNING opportunity for min() Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220517023923.76989-1-guozhengkui@vivo.com
2022-05-22ath11k: Fix warning on variable 'sar' dereference before checkBaochen Qiang1-7/+6
We are seeing below warning: warn: variable dereferenced before check 'sar' Fix it by moving ahead pointer check on 'sar'. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: 652f69ed9c1b ("ath11k: Add support for SAR") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220517004844.2412660-1-quic_bqiang@quicinc.com
2022-05-22ath10k: fix misreported tx bandwidth for 160MhzMaxime Bizon1-0/+4
Because of this missing switch case, 160Mhz transmit was reported as 20Mhz, leading to wrong airtime calculation and AQL limiting max throughput. Tested-on: QCA9984 hw2.0 PCI 10.4-3.10-00047 Signed-off-by: Maxime Bizon <mbizon@freebox.fr> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/cd2735a40da7f4fcc5323e3fca3775e7b5402ece.camel@freebox.fr
2022-05-22ath10k: add encapsulation offloading supportSergey Ryazanov2-14/+55
Frame encapsulation from Ethernet into the IEEE 802.11 frame format takes a considerable host CPU time on the xmit path. The firmware is able to do this operation for us, so enable encapsulation offloading for AP and Sta interface types to improve overall system performance. The driver is almost ready for encapsulation offloading support. There are only a few places where the driver assumes the frame format is IEEE 802.11 that need to be fixed. Encapsulation offloading is currently disabled by default and the driver utilizes mac80211 encapsulation support. To activate offloading, the frame_mode=2 parameter should be passed during module loading. On a QCA9563+QCA9888-based access point in bridged mode, encapsulation offloading increases TCP 16-streams DL throughput from 365 to 396 mbps (+8%) and UDP DL throughput from 436 to 483 mbps (+11%). Tested-on: QCA9888 hw2.0 PCI 10.4-3.9.0.2-00131 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1 Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Tested-by: Oldřich Jedlička <oldium.pro@gmail.com> # TP-Link Archer C7 v4 & v5 (QCA9563 + QCA9880) Tested-by: Edward Matijevic <motolav@gmail.com> # TP-Link Archer C2600 (IPQ8064 + QCA9980 10.4.1.00030-1) Tested-by: Edward Matijevic <motolav@gmail.com> # QCA9377 PCI in Sta mode Tested-by: Zhijun You <hujy652@gmail.com> # NETGEAR R7800 (QCA9984 10.4-3.9.0.2-00159) Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220516032519.29831-5-ryazanov.s.a@gmail.com
2022-05-22ath10k: turn rawmode into frame_modeSergey Ryazanov2-4/+8
Turn boolean rawmode module param into integer frame_mode param that contains value from ath10k_hw_txrx_mode enum. As earlier the default param value is non-RAW (native Wi-Fi) encapsulation. The param name is selected to be consistent with the similar ath11k param. This is a preparation step for upcoming encapsulation offloading support. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220516032519.29831-4-ryazanov.s.a@gmail.com
2022-05-22ath10k: htt_tx: do not interpret Eth frames as WiFiSergey Ryazanov1-26/+35
The xmit path for the Ethernet encapsulated frames become more or less usable since d740d8fd2439 ("ath10k: unify tx mode and dispatch"). This change reorganize the xmit path in a manageable way to properly support various tx modes, but misses that the Ethernet encapsulated frame is a special case. We do not have an IEEE 802.11 header at the begining of them. But the HTT Tx handler still interprets first bytes of each frame as an IEEE 802.11 Frame Control field. Than this code was copied by e62ee5c381c5 ("ath10k: Add support for htt_data_tx_desc_64 descriptor") and a2097d6444c3 ("ath10k: htt: High latency TX support") to another handlers. In fact the issue in the high latency (HL) handler was introduced by 83ac260151e7 ("ath10k: add mic bytes for pmf management packet"). Ethernet encapsulated frame tx mode stay unused until 75d85fd9993c ("ath10k: introduce basic tdls functionality") started using it for TDLS frames to avoid key selection issue in some firmwares. Trying to interpret the begining of an Ethernet encapsulated frame as an IEEE 802.11 header was not hurt us noticeably since we need to meet two conditions: (1) xmit should be performed towards a TDLS peer, and (2) the TDLS peer should have a specific OUI part of its MAC address. Looks like that the rareness in TDLS communications of OUIs that can be interpreted as an 802.11 management frame saves users from facing this issue earlier. Improve Ethernet tx mode support in the HTT Tx handler by avoiding interpreting its first bytes as an IEEE 802.11 header. While at it, make the ieee80211_hdr variable local to the code block that is guarded by !is_eth check. In this way, we clarify in which cases a frame can be interpreted as IEEE 802.11, and saves us from similar issues in the future. Credits: this change as part of xmit encapsulation offloading support was originally made by QCA and then submitted for inclusion by John Crispin [1]. But the whole work was not accepted due to the lack of a part for 64-bits descriptors [2]. Zhijun You then pointed this out to me in a reply to my initial RFC patch series. And I made this slightly reworked version that covered all the HTT Tx handler variants. 1. https://lore.kernel.org/all/20191216092207.31032-1-john@phrozen.org/ 2. https://patchwork.kernel.org/project/linux-wireless/patch/20191216092207.31032-1-john@phrozen.org/ Reported-by: Zhijun You <hujy652@gmail.com> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220516032519.29831-3-ryazanov.s.a@gmail.com
2022-05-22ath10k: improve tx status reportingSergey Ryazanov1-1/+14
We use ieee80211_tx_status() to report each completed tx frame. Internally, this function calls sta_info_get_by_addrs(), what has a couple of drawbacks: 1. additional station lookup causes a performance degradation; 2. mac80211 can not properly account Ethernet encapsulated frames due to the inability to properly determine the destination (station) MAC address since ieee80211_tx_status() assumes the frame has a 802.11 header. The latter is especially destructive if we want to use hardware frames encapsulation. To fix both of these issues, replace ieee80211_tx_status() with ieee80211_tx_status_ext() call and feed it station pointer from the tx queue associated with the transmitted frame. Tested-on: QCA9888 hw2.0 PCI 10.4-3.9.0.2-00131 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1 Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Tested-by: Oldřich Jedlička <oldium.pro@gmail.com> # TP-Link Archer C7 v4 & v5 (QCA9563 + QCA9880) Tested-by: Edward Matijevic <motolav@gmail.com> # TP-Link Archer C2600 (IPQ8064 + QCA9980 10.4.1.00030-1) Tested-by: Edward Matijevic <motolav@gmail.com> # QCA9377 PCI in Sta mode Tested-by: Zhijun You <hujy652@gmail.com> # NETGEAR R7800 (QCA9984 10.4-3.9.0.2-00159) Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220516032519.29831-2-ryazanov.s.a@gmail.com
2022-05-22ath10k: do not enforce interrupt trigger typeKrzysztof Kozlowski1-3/+2
Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge rising - but instead rely on Devicetree to configure it. All Qualcomm DTSI with WCN3990 define the interrupt type as level high, so the mismatch between DTSI and driver causes rebind issues: $ echo 18800000.wifi > /sys/bus/platform/drivers/ath10k_snoc/unbind $ echo 18800000.wifi > /sys/bus/platform/drivers/ath10k_snoc/bind [ 44.763114] irq: type mismatch, failed to map hwirq-446 for interrupt-controller@17a00000! [ 44.763130] ath10k_snoc 18800000.wifi: error -ENXIO: IRQ index 0 not found [ 44.763140] ath10k_snoc 18800000.wifi: failed to initialize resource: -6 Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.0.c8-00009-QCAHLSWSC8180XMTPLZ-1 Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 Fixes: c963a683e701 ("ath10k: add resource init and deinit for WCN3990") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220513151516.357549-1-krzysztof.kozlowski@linaro.org
2022-05-18ath11k: update missing MU-MIMO and OFDMA statsSriram R2-1/+126
Update the missing MU-MIMO/OFDMA info in PDEV RX, trigger and schedule stats. i.e HTT stats type 10, 12 and 17 respectively. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4-01209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1652152236-12038-1-git-send-email-quic_srirrama@quicinc.com
2022-05-16Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo17-36/+575
ath.git patches for v5.19. Major changes: ath11k * enable keepalive during WoWLAN suspend * implement remain-on-channel support
2022-05-16mac80211: extend current rate control tx status APIJonas Jelonek1-1/+7
This patch adds the new struct ieee80211_rate_status and replaces 'struct rate_info *rate' in ieee80211_tx_status with pointer and length annotation. The struct ieee80211_rate_status allows to: (1) receive tx power status feedback for transmit power control (TPC) per packet or packet retry (2) dynamic mapping of wifi chip specific multi-rate retry (mrr) chains with different lengths (3) increase the limit of annotatable rate indices to support IEEE802.11ac rate sets and beyond ieee80211_tx_info, control and status buffer, and ieee80211_tx_rate cannot be used to achieve these goals due to fixed size limitations. Our new struct contains a struct rate_info to annotate the rate that was used, retry count of the rate and tx power. It is intended for all information related to RC and TPC that needs to be passed from driver to mac80211 and its RC/TPC algorithms like Minstrel_HT. It corresponds to one stage in an mrr. Multiple subsequent instances of this struct can be included in struct ieee80211_tx_status via a pointer and a length variable. Those instances can be allocated on-stack. The former reference to a single instance of struct rate_info is replaced with our new annotation. An extension is introduced to struct ieee80211_hw. There are two new members called 'tx_power_levels' and 'max_txpwr_levels_idx' acting as a tx power level table. When a wifi device is registered, the driver shall supply all supported power levels in this list. This allows to support several quirks like differing power steps in power level ranges or alike. TPC can use this for algorithm and thus be designed more abstract instead of handling all possible step widths individually. Further mandatory changes in status.c, mt76 and ath11k drivers due to the removal of 'struct rate_info *rate' are also included. status.c already uses the information in ieee80211_tx_status->rate in radiotap, this is now changed to use ieee80211_rate_status->rate_idx. mt76 driver already uses struct rate_info to pass the tx rate to status path. The new members of the ieee80211_tx_status are set to NULL and 0 because the previously passed rate is not relevant to rate control and accurate information is passed via tx_info->status.rates. For ath11k, the txrate can be passed via this struct because ath11k uses firmware RC and thus the information does not interfere with software RC. Compile-Tested: current wireless-next tree with all flags on Tested-on: Xiaomi 4A Gigabit (MediaTek MT7603E, MT7612E) with OpenWrt Linux 5.10.113 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Link: https://lore.kernel.org/r/20220509173958.1398201-2-jelonek.jonas@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10ath11k: remove redundant assignment to variables vht_mcs and he_mcsColin Ian King1-2/+2
The variables vht_mcs and he_mcs are being initialized in the start of for-loops however they are re-assigned new values in the loop and not used outside the loop. The initializations are redundant and can be removed. Cleans up clang scan warnings: warning: Although the value stored to 'vht_mcs' is used in the enclosing expression, the value is never actually read from 'vht_mcs' [deadcode.DeadStores] warning: Although the value stored to 'he_mcs' is used in the enclosing expression, the value is never actually read from 'he_mcs' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220507184155.26939-1-colin.i.king@gmail.com
2022-05-10ath11k: Reuse the available memory after firmware reloadAnilkumar Kolli3-4/+23
Ath11k allocates memory when firmware requests memory in QMI. Coldboot calibration and firmware recovery uses firmware reload. On firmware reload, firmware sends memory request again. If Ath11k allocates memory on first firmware boot, reuse the available memory. Also check if the segment type and size is same on the next firmware boot. Reuse if segment type/size is same as previous firmware boot else free the segment and allocate the segment with size/type. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.6.0.1-00752-QCAHKSWPL_SILICONZ-1 Signed-off-by: Anilkumar Kolli <quic_akolli@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220506141448.10340-1-quic_akolli@quicinc.com
2022-05-10wil6210: remove 'freq' debugfsJohannes Berg1-14/+0
This is completely racy, remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220506095451.9852305a92c8.I05155824a1b9059eb59beccde81786dc69de354a@changeid
2022-05-10ath11k: Designating channel frequency when sending management framesBaochen Qiang3-1/+24
In case of Passpoint, the WLAN interface may be requested to remain on a specific channel and then to send some management frames on that channel. Now chanfreq of wmi_mgmt_send_cmd is set as 0, as a result firmware may choose a default but wrong channel. Fix it by assigning chanfreq field with the designated channel. This change only applies to WCN6855 and QCA6390, other chips are not affected. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220506013614.1580274-4-quic_bqiang@quicinc.com
2022-05-10ath11k: Don't check arvif->is_started before sending management framesBaochen Qiang1-2/+3
Commit 66307ca04057 ("ath11k: fix mgmt_tx_wmi cmd sent to FW for deleted vdev") wants both of below two conditions are true before sending management frames: 1: ar->allocated_vdev_map & (1LL << arvif->vdev_id) 2: arvif->is_started Actually the second one is not necessary because with the first one we can make sure the vdev is present. Also use ar->conf_mutex to synchronize vdev delete and mgmt. TX. This issue is found in case of Passpoint scenario where ath11k needs to send action frames before vdev is started. Fix it by removing the second condition. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Fixes: 66307ca04057 ("ath11k: fix mgmt_tx_wmi cmd sent to FW for deleted vdev") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220506013614.1580274-3-quic_bqiang@quicinc.com
2022-05-10ath11k: Implement remain-on-channel supportBaochen Qiang3-0/+120
Add remain on channel support, it is needed in several scenarios such as Passpoint etc. Currently this is supported by QCA6390, WCN6855, IPQ8074, IPQ6018 and QCN9074. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220506013614.1580274-2-quic_bqiang@quicinc.com
2022-05-10ath11k: Handle keepalive during WoWLAN suspend and resumeBaochen Qiang5-0/+156
With WoWLAN enabled and after sleeping for a rather long time, we are seeing that with some APs, it is not able to wake up the STA though the correct wake up pattern has been configured. This is because the host doesn't send keepalive command to firmware, thus firmware will not send any packet to the AP and after a specific time the AP kicks out the STA. Fix this issue by enabling keepalive before going to suspend and disabling it after resume back. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220506012540.1579604-1-quic_bqiang@quicinc.com
2022-05-09ath11k: reset 11d state in process of recoveryWen Gong3-0/+9
When doing simulate_fw_crash operation periodically with a short interval time such as 10 seconds, it is easy happened WMI command timed out for WMI_SCAN_CHAN_LIST_CMDID in ath11k_reg_update_chan_list(). log: [42287.610053] ath11k_pci 0000:01:00.0: wmi command 12291 timeout [42287.610064] ath11k_pci 0000:01:00.0: failed to send WMI_SCAN_CHAN_LIST cmd [42287.610073] ath11k_pci 0000:01:00.0: failed to perform regd update : -11 Note that this issue does not occur with a longer interval such as 20 seconds. The reason the issue occurs with a shorter interval is the following steps: 1) Upon initial boot, or after device recovery, the initial hw scan plus the 11d scan will run, and when 6 GHz support is present, these scans can take up to 12 seconds to complete, so ath11k_reg_update_chan_list() is still waiting the completion of ar->completed_11d_scan. 2) If a simulate_fw_crash operation is received during this time, those scans do not complete, and ath11k_core_pre_reconfigure_recovery() complete the ar->completed_11d_scan, then ath11k_reg_update_chan_list() wakeup and start to send WMI_SCAN_CHAN_LIST_CMDID, but firmware is crashed at this moment, so wmi timed out occur. To address this issue, reset the 11d state during device recovery so that WMI_SCAN_CHAN_LIST_CMDID does not timed out for short interval time such as 10 seconds. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: 1f682dc9fb37 ("ath11k: reduce the wait time of 11d scan and hw scan while add interface") Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220505034636.29582-1-quic_wgong@quicinc.com
2022-05-06ath11k: Fix RX de-fragmentation issue on WCN6750Manikanta Pubbisetty3-3/+23
The offset of REO register where the RX fragment destination ring is configured is different in WCN6750 as compared to WCN6855. Due to this differnce in offsets, on WCN6750, fragment destination ring will be configured incorrectly, leading to RX fragments not getting delivered to the driver. Fix this by defining HW specific offsets for the REO MISC CTL register. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220504083900.31513-1-quic_mpubbise@quicinc.com
2022-05-06ath10k: support bus and device specific API 1 BDF selectionRobert Marko1-1/+12
Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the BDF-s to be extracted from the device storage instead of shipping packaged API 2 BDF-s. This is required as MikroTik has started shipping boards that require BDF-s to be updated, as otherwise their WLAN performance really suffers. This is however impossible as the devices that require this are release under the same revision and its not possible to differentiate them from devices using the older BDF-s. In OpenWrt we are extracting the calibration data during runtime and we are able to extract the BDF-s in the same manner, however we cannot package the BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on the fly. This is an issue as the ath10k driver explicitly looks only for the board.bin file and not for something like board-bus-device.bin like it does for pre-cal data. Due to this we have no way of providing correct BDF-s on the fly, so lets extend the ath10k driver to first look for BDF-s in the board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin If that fails, look for the default board file name as defined previously. Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211009221711.2315352-1-robimarko@gmail.com
2022-05-06ath10k: mac: fix too long linesKalle Valo1-4/+9
checkpatch warns: drivers/net/wireless/ath/ath10k/mac.c:2696: line length of 92 exceeds 90 columns drivers/net/wireless/ath/ath10k/mac.c:6942: line length of 94 exceeds 90 columns drivers/net/wireless/ath/ath10k/mac.c:6948: line length of 91 exceeds 90 columns These were introduced by commit 046d2e7c50e3 ("mac80211: prepare sta handling for MLO support"). Compile tested only. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220503060415.24499-2-kvalo@kernel.org
2022-05-06ath11k: mac: fix too long lineKalle Valo1-4/+8
checkpatch warns: drivers/net/wireless/ath/ath11k/mac.c:7760: line length of 91 exceeds 90 columns This was introduced by commit 046d2e7c50e3 ("mac80211: prepare sta handling for MLO support"). Compile tested only. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220503060415.24499-1-kvalo@kernel.org
2022-05-06wil6210: switch to netif_napi_add_tx()Jakub Kicinski1-6/+4
Switch to the new API not requiring passing in NAPI_POLL_WEIGHT. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220504163316.549648-2-kuba@kernel.org
2022-05-04ath11k: Add support for targets without trustzoneManikanta Pubbisetty2-1/+186
Add the support to attach WCN6750 and map iommu domain for targets which do not have the support of TrustZone. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00573-QCAMSLSWPLZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220328062032.28881-1-quic_mpubbise@quicinc.com
2022-05-04Merge tag 'wireless-next-2022-05-03' of ↵Jakub Kicinski70-1762/+5629
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.19 First set of patches for v5.19 and this is a big one. We have two new drivers, a change in mac80211 STA API affecting most drivers and ath11k getting support for WCN6750. And as usual lots of fixes and cleanups all over. Major changes: new drivers - wfx: silicon labs devices - plfxlc: pureLiFi X, XL, XC devices mac80211 - host based BSS color collision detection - prepare sta handling for IEEE 802.11be Multi-Link Operation (MLO) support rtw88 - support TP-Link T2E devices rtw89 - support firmware crash simulation - preparation for 8852ce hardware support ath11k - Wake-on-WLAN support for QCA6390 and WCN6855 - device recovery (firmware restart) support for QCA6390 and WCN6855 - support setting Specific Absorption Rate (SAR) for WCN6855 - read country code from SMBIOS for WCN6855/QCA6390 - support for WCN6750 wcn36xx - support for transmit rate reporting to user space * tag 'wireless-next-2022-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (228 commits) rtw89: 8852c: rfk: add DPK rtw89: 8852c: rfk: add IQK rtw89: 8852c: rfk: add RX DCK rtw89: 8852c: rfk: add RCK rtw89: 8852c: rfk: add TSSI rtw89: 8852c: rfk: add LCK rtw89: 8852c: rfk: add DACK rtw89: 8852c: rfk: add RFK tables plfxlc: fix le16_to_cpu warning for beacon_interval rtw88: remove a copy of the NAPI_POLL_WEIGHT define carl9170: tx: fix an incorrect use of list iterator wil6210: use NAPI_POLL_WEIGHT for napi budget ath10k: remove a copy of the NAPI_POLL_WEIGHT define ath11k: Add support for WCN6750 device ath11k: Datapath changes to support WCN6750 ath11k: HAL changes to support WCN6750 ath11k: Add QMI changes for WCN6750 ath11k: Fetch device information via QMI for WCN6750 ath11k: Add register access logic for WCN6750 ath11k: Add HW params for WCN6750 ... ==================== Link: https://lore.kernel.org/r/20220503153622.C1671C385A4@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-03Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo35-249/+1158
ath.git patches for v5.19. Major changes: ath11k * support setting Specific Absorption Rate (SAR) for WCN6855 * read country code from SMBIOS for WCN6855/QCA6390 * support for WCN6750
2022-05-02carl9170: tx: fix an incorrect use of list iteratorXiaomeng Tong1-0/+3
If the previous list_for_each_entry_continue_rcu() don't exit early (no goto hit inside the loop), the iterator 'cvif' after the loop will be a bogus pointer to an invalid structure object containing the HEAD (&ar->vif_list). As a result, the use of 'cvif' after that will lead to a invalid memory access (i.e., 'cvif->id': the invalid pointer dereference when return back to/after the callsite in the carl9170_update_beacon()). The original intention should have been to return the valid 'cvif' when found in list, NULL otherwise. So just return NULL when no entry found, to fix this bug. Cc: stable@vger.kernel.org Fixes: 1f1d9654e183c ("carl9170: refactor carl9170_update_beacon") Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220328122820.1004-1-xiam0nd.tong@gmail.com
2022-05-02wil6210: use NAPI_POLL_WEIGHT for napi budgetJakub Kicinski2-5/+4
The comment next to WIL6210_NAPI_BUDGET says "arbitrary". If we're picking arbitrary values let's pick the recommended default which is NAPI_POLL_WEIGHT. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220429174643.196994-4-kuba@kernel.org
2022-05-02ath10k: remove a copy of the NAPI_POLL_WEIGHT defineJakub Kicinski5-7/+4
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220429174643.196994-3-kuba@kernel.org
2022-05-02ath11k: Add support for WCN6750 deviceManikanta Pubbisetty4-13/+158
WCN6750 is non-DBS 2x2 11AX chipset. Unlike QCA6390 which is a DBS (dual band simultaneous) solution (2 LMACs), WCN6750 has a single LMAC supporting 2G, 5G and 6G bands but will operate only on one band at any given point. WCN6750 is a PCIe based solution, but it is attached to the WPSS (Wireless Processor SubSystem) Q6 processor, hence it is enumerated by the Q6 processor. It is registered to the APSS processor (Application Processor SubSystem) as a platform device(AHB) and remoteproc APIs are used to boot up or shutdown the device like other AHB devices. Also, Device information like BAR and it's size is not known to the APSS processor as the chip is enumerated by WPSS Q6. These details are fetched over QMI. STA and AP modes are supported. Verified basic connectivity and ping in both the modes. An important point to note is that though WCN6750 is a PCIe device, it cannot be attached to any other platform except on Qualcomm Snapdragon SoCs due to the aforementioned reasons. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220429170502.20080-10-quic_mpubbise@quicinc.com
2022-05-02ath11k: Datapath changes to support WCN6750Manikanta Pubbisetty2-0/+33
HAL RX descriptor for WCN6750 is same as QCN9074, this means that the size of the HAL RX decriptor and the DP APIs that WCN6750 requires to enable datapath should be initialized with that of QCN9074's RX descriptor size and the DP APIs respectively. There is one change wrt to REO configuration though, REO configuration for WCN6750 follows WCN6855, therefore use reo_setup() of WCN6855 for WCN6750. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220429170502.20080-9-quic_mpubbise@quicinc.com
2022-05-02ath11k: HAL changes to support WCN6750Manikanta Pubbisetty5-13/+163
Add HAL changes required to support WCN6750. Offsets of some registers for WCN6750 are different from other supported devices; move such register offsets to platform specific ath11k_hw_regs. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00192-QCAHKSWPL_SILICONZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220429170502.20080-8-quic_mpubbise@quicinc.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 04:49:46 +0300