aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-03-09ath6kl: wmi: Replace one-element array with flexible-array member in struct ↵Gustavo A. R. Silva1-1/+1
wmi_disconnect_event Replace one-element array with flexible-array member in struct wmi_disconnect_event. This issue was found with the help of Coccinelle and audited and fixed, manually. Link: https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/e9957dc53ae48c2f39ae57b0157a67d844b5bc20.1645736204.git.gustavoars@kernel.org
2022-03-09ath6kl: wmi: Replace one-element array with flexible-array member in struct ↵Gustavo A. R. Silva1-1/+1
wmi_connect_event Replace one-element array with flexible-array member in struct wmi_connect_event. This issue was found with the help of Coccinelle and audited and fixed, manually. Link: https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/290a0cb7bddd813a6a96a59853880e66917aa03d.1645736204.git.gustavoars@kernel.org
2022-03-09ath6kl: wmi: Replace one-element array with flexible-array member in struct ↵Gustavo A. R. Silva1-1/+1
wmi_channel_list_reply Replace one-element array with flexible-array member in struct wmi_channel_list_reply. This issue was found with the help of Coccinelle and audited and fixed, manually. Link: https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/f3f9728a1dfc3767340f25a963be374e2ef5d8ad.1645736204.git.gustavoars@kernel.org
2022-03-09ath6kl: wmi: Replace one-element array with flexible-array member in struct ↵Gustavo A. R. Silva2-8/+2
wmi_start_scan_cmd Replace one-element array with flexible-array member in struct wmi_start_scan_cmd. Also, make use of the struct_size() helper. This issue was found with the help of Coccinelle and audited and fixed, manually. Link: https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/8b33c6d86a6bd40b5688cf118b4b35850db8d8c7.1645736204.git.gustavoars@kernel.org
2022-03-09ath6kl: wmi: Replace one-element array with flexible-array member in struct ↵Gustavo A. R. Silva2-8/+3
wmi_begin_scan_cmd Replace one-element array with flexible-array member in struct wmi_begin_scan_cmd. Also, make use of the struct_size() helper. This issue was found with the help of Coccinelle and audited and fixed, manually. Link: https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1ef801ea24475501fa0f296cb5435a440135206e.1645736204.git.gustavoars@kernel.org
2022-03-07Revert "ath: add support for special 0x0 regulatory domain"Brian Norris1-5/+5
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423. Users are reporting regressions in regulatory domain detection and channel availability. The problem this was trying to resolve was fixed in firmware anyway: QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042 https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552 Link: https://bbs.archlinux.org/viewtopic.php?id=254535 Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/ Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain") Cc: <stable@vger.kernel.org> Cc: Wen Gong <wgong@codeaurora.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20200527165718.129307-1-briannorris@chromium.org
2022-02-25rtw89: get channel parameters of 160MHz bandwidthPing-Ke Shih2-15/+36
Calculate the offset of center and primary frequencies to get hardware indices of center channel and primary channel, and then use them to configure hardware to a specific channel. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220222032103.29392-1-pkshih@realtek.com
2022-02-25Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo37-206/+2017
ath.git patches for v5.18. Major changes: ath11k * debugfs interface to configure firmware debug log level * debugfs interface to test Target Wake Time (TWT) * provide 802.11ax High Efficiency (HE) data via radiotap ath9k * use hw_random API instead of directly dumping into random.c wcn36xx * fix wcn3660 to work on 5 GHz band
2022-02-24mt76: fix dfs state issue with 160 MHz channelsFelix Fietkau4-10/+16
When operating on a mix of DFS and non-DFS channels, the driver only checks the CAC status of the control channel. This causes beacons/tx to fail if the control channel is on a non-DFS channel. Fix this by calling cfg80211_reg_can_beacon to determine the DFS status of all affected channels Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: simplify conditionalWan Jiabing1-3/+1
Fix following coccicheck warning: ./drivers/net/wireless/mediatek/mt76/mt7915/mac.c:768:29-31: WARNING !A || A && B is equivalent to !A || B Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7921: fix injected MPDU transmission to not use HW A-MSDULorenzo Bianconi1-0/+1
Similar to mt7915 driver, do not aggregate injected frames in HW A-MSDU block. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915e: Enable thermal management by defaultNicolas Cavallari1-1/+2
By default, mt7915e does not enable thermal management until the default thermal zone does not reach a trip point. If the rest of the system have better cooling than the wireless hardware, then it is possible that the wireless chip can overheat while the rest of the system is fine. Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915e: Add a hwmon attribute to get the actual throttle state.Nicolas Cavallari1-9/+18
The firmware-controlled actual throttle state was previously available by reading the cooling_device, but this confused the thermal subsystem. Add a hwmon attribute to get it instead. Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915e: Fix degraded performance after temporary overheatNicolas Cavallari2-6/+13
mt7915e registers a cooling_device with wrong semantics: 1. cooling_device expect that higher states values should cool more, but mt7915e did the opposite... with the exception of state == 0, which should "disable thermal management", but does not seem to have any effect since the previous state is kept. The result is that when the thermal zone heats up a bit and bumps the cooling_device state from 0 to 1 to cool a bit, the performance is destroyed, and when going back from 1 to 0, the performance stays bad. 2. Reading the cooling_device state does not always return the last written state, but can return the actual hardware throttle state, which is different. This is a problem because the mt7915 firmware actually implement the equivalent of a thermal zone with trip points. Setting the cooling device state actually changes the throttles at each trip point, so the following could occur if the first issue is fixed: - thermal subsystem set state to 100% power (state=0) - mt7915e driver set trip throttles to [100%, 50%, 25%, 12%] - hardware heats up and decides to switch to 50% power - thermal subsystem see that power is 50% (state=50), decide to increase it to 60% (state=40) because the rest of the system is cool. - mt7915e driver set trip throttle to [60%, 30%, 15%, 7%] - hardware thus switches to 30% power [race to the bottom continues...] This patch corrects the semantics of the cooling_device to the one that the thermal subsystem expect it. Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: improve signal strength reportingFelix Fietkau6-29/+33
Instead of just taking the maximum per-chain signal strength values, add an approximation for the sum of the combined signal. This should more accurately reflect the real signal strength, especially if the per-chain signal strength values are close to each other Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: use min_t() to make code cleanerChangcheng Deng1-6/+2
Use min_t() in order to make code cleaner. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: fix the muru tlv issueMeiChia Chiu1-7/+5
The muru enable/disable are only set after the first station connection. Without this patch, the firmware couldn't enable muru if the first connected station is non-HE type. Fixes: 16bff457dd33a ("mt76: mt7915: rework mt7915_mcu_sta_muru_tlv()") Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: check band idx for bcc eventRyder Lee2-3/+26
Add missing band idx check for DBDC cases. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7615: Fix assigning negative values to unsigned variableYang Li1-1/+1
Smatch reports the following: drivers/net/wireless/mediatek/mt76/mt7615/mac.c:1865 mt7615_mac_adjust_sensitivity() warn: assigning (-110) to unsigned variable 'def_th' drivers/net/wireless/mediatek/mt76/mt7615/mac.c:1865 mt7615_mac_adjust_sensitivity() warn: assigning (-98) to unsigned variable 'def_th' Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: connac: adjust wlan_idx size from u8 to u16Chad Monroe2-2/+2
Newer chips such as MT7915 require up to 16-bits for this field. Fixes: 49126ac1f8d26 ("mt76: connac: move mt76_connac_mcu_bss_basic_tlv in connac module") Signed-off-by: Chad Monroe <chad.monroe@smartrg.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: fix endianness warnings in mt7915_mac_tx_free()Lorenzo Bianconi1-1/+1
Fix the following sparse warning in mt7915_mac_tx_free routine: warning: incorrect type in assignment (different base types) expected unsigned int [usertype] *cur_info got restricted __le32 * warning: cast to restricted __le32 Fixes: c17780e7b21ec ("mt76: mt7915: add txfree event v3") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: fix endianness warnings in mt7915_debugfs_rx_fw_monitorLorenzo Bianconi1-2/+2
Fix the following sparse warnings: warning: incorrect type in initializer (different base types) expected restricted __le16 [usertype] msg_type got int warning: incorrect type in assignment (different base types) expected restricted __le32 [usertype] timestamp got unsigned int Fixes: 988845c9361a0 ("mt76: mt7915: add support for passing chip/firmware debug data to user space") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7615: fix compiler warning on frame sizeDeren Wu1-3/+11
The following error is see from the compiler: mt7615/debugfs.c: In function ‘mt7615_ext_mac_addr_read’: mt7615/debugfs.c:465:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=] The issue is due to allocating a buffer as string storage. Fix by converting to a dynamical allocation of the buffer. Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: initialize smps mode in mt7915_mcu_sta_rate_ctrl_tlv()Peter Chiu1-0/+1
Initialize smps mode to prevent firmware rate adaptation issue. Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: introduce band_idx in mt7915_phyBo Jiao10-160/+172
The wfsys of MT7986 has only single adie chip for non-dbdc devices, and it binds to band1 by default. Hence this patch adds band_idx to explicitly configure phy accordingly. Co-developed-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Co-developed-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24mt76: mt7915: add support for MT7986Bo Jiao15-80/+1817
This adds MT7986 SoC integrated multi-band 4x4 WiFi 6/6E. Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-24ath10k: fix pointer arithmetic error in trace callFrancesco Magliocca1-1/+1
Reading through the commit history, it looks like there is no special need why we must skip the first 4 bytes in this trace call: trace_ath10k_htt_rx_desc(ar, (void*)rx_desc + sizeof(u32), hw->rx_desc_ops->rx_desc_size - sizeof(u32)); found in the function ath10k_htt_rx_amsdu_pop in the file htt_rx.c i think the original author (who is also the one who added rx_desc tracing capabilities in a0883cf7e75a) just wanted to trace the rx_desc contents, ignoring the fw_rx_desc_base info field (which is the part being skipped over). But the trace_ath10k_htt_rx_desc later added don't care about skipping it, so it may be good to uniform this call to the others in the file. But this would change the output of the trace and thus it may be a problem for tools that rely on it. Therefore I propose until further discussion to just keep it as it is and just fix the pointer arithmetic bug. Add missing void* cast to rx descriptor pointer in order to properly skip the initial 4 bytes of the rx descriptor when passing it to trace_ath10k_htt_rx_desc trace function. This fixes the pointer arithmetic error detected by Dan Carpenter's static analysis tool. Fixes: 6bae9de622d3 ("ath10k: abstract htt_rx_desc structure") Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1 Signed-off-by: Francesco Magliocca <franciman12@gmail.com> Link: https://lore.kernel.org/ath10k/20220201130900.GD22458@kili/ Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220221122638.7971-1-franciman12@gmail.com
2022-02-24carl9170: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva2-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194955.GA904126@embeddedor
2022-02-24ath11k: add dbring debug supportVenkateswara Naralasetty6-6/+283
Target copies spectral report and CFR report through dbring to host for further processing. This mechanism involves ring and buffer management in the Host, FW, and uCode, where improper tail pointer update issues are seen. This dbring debug support help to debug such issues by tracking head and tail pointer movement along with the timestamp at which each buffer is received and replenished. Provide a debugfs interface to enalbe/disable dbring debug support and dump the dbring debug entries. Also introduced a new hardware param to add dbring debugfs support for few hardwares which are using dbings. Usage: echo <dbr_id> <val> > /sys/kernel/debug/ath11k/ipq8074_2/ mac0/enable_dbr_debug dbr_id: 0 for spectral and 1 for CFR val: 0 - disable, 1 - enable. Tested-on: IPQ8074 WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1 Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1645366059-11798-1-git-send-email-quic_vnaralas@quicinc.com
2022-02-24ath11k: translate HE status to radiotap formatPradeep Kumar Chitrapu2-64/+438
Translate HE status to radiotap format. This uses HE radiotap definitions from include/net/ieee80211_radiotap.h. Co-developed-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217012112.31211-4-pradeepc@codeaurora.org
2022-02-24ath11k: decode HE status tlvPradeep Kumar Chitrapu3-21/+215
Add new bitmasks and macro definitions required for parsing HE status tlvs. Decode HE status tlvs, which will used in dumping ppdu stats as well as updating radiotap headers. Co-developed-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217012112.31211-3-pradeepc@codeaurora.org
2022-02-24ath11k: switch to using ieee80211_tx_status_ext()Pradeep Kumar Chitrapu1-5/+23
This allows us to pass HE rates down into the stack. Co-developed-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217012112.31211-2-pradeepc@codeaurora.org
2022-02-23mt76: mt7921s: fix missing fc type/sub-type for 802.11 pktsDeren Wu2-3/+12
For non-mmio devices, should set fc values to proper txwi config Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Tested-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Leon Yen <Leon.Yen@mediatek.com> Signed-off-by: Leon Yen <Leon.Yen@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: fix potential memory leak of fw monitor packetsShayne Chen1-0/+1
Free the skb of fw monitor packets. Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: Fix channel state update error issueBo Jiao3-10/+24
Fix channel state update error issue due to wrong register access for mt7916. Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: fix endianness errors in reverse_frag0_hdr_transLorenzo Bianconi3-36/+55
Fix ht ctl field size in mt{7615,7915,7921}_reverse_frag0_hdr_trans. Fix the following endianness warnings in mt{7615,7915,7921}_reverse_frag0_hdr_trans: drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: expected restricted __le16 [usertype] frame_control drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: expected restricted __le16 [usertype] seq_ctrl drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: expected restricted __le32 [usertype] qos_ctrl drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: expected restricted __le32 [usertype] ht_ctrl drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:25: warning: restricted __be16 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:38: warning: restricted __be16 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: expected unsigned int [usertype] *cur_info drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: got restricted __le32 * drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1451:34: warning: cast to restricted __le32 Fixes: dc5399a50b45f ("mt76: reverse the first fragmented frame to 802.11") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7615: introduce SAR supportLorenzo Bianconi2-4/+27
Add SAR spec support to mt7615 driver to allow configuring SAR power limitations on the frequency ranges from the userland. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: fix injected MPDU transmission to not use HW A-MSDUJohan Almbladh1-0/+1
Before, the hardware would be allowed to transmit injected 802.11 MPDUs as A-MSDU. This resulted in corrupted frames being transmitted. Now, injected MPDUs are transmitted as-is, without A-MSDU. The fix was verified with frame injection on MT7915 hardware, both with and without the injected frame being encrypted. If the hardware cannot do A-MSDU aggregation on MPDUs, this problem would also be present in the TX path where mac80211 does the 802.11 encapsulation. However, I have not observed any such problem when disabling IEEE80211_HW_SUPPORTS_TX_ENCAP_OFFLOAD to force that mode. Therefore this fix is isolated to injected frames only. The same A-MSDU logic is also present in the mt7921 driver, so it is likely that this fix should be applied there too. I do not have access to mt7921 hardware so I have not been able to test that. Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-22rtw88: change rtw_info() to proper message levelPing-Ke Shih9-19/+20
Larry reported funny log entries [1] when he used rtl8821ce. These messages are not harmless, but not useful for users, so change them to rtw_dbg() level. By the way, I review all rtw_info() and change others to rtw_warn(). [1] https://lore.kernel.org/linux-wireless/c356d5ae-a7b3-3065-1121-64c446e70333@lwfinger.net/ Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218035527.9835-1-pkshih@realtek.com
2022-02-22rtw89: Limit the CFO boundaries of x'tal valueYi-Tang Chiu3-0/+26
Set the boundaries of x'tal value to avoid extremely adjusted results, causing severely unexpected CFO. Signed-off-by: Yi-Tang Chiu <chiuyitang@realtek.com> Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034537.9338-1-pkshih@realtek.com
2022-02-22rtw89: phy: handle txpwr lmt/lmt_ru of 160M bandwidthZong-Zhe Yang2-7/+110
Add handling to fill struct rtw89_txpwr_limit and rtw89_txpwr_limit_ru for 160Mhz bandwidth case. And enlarge RTW89_5G_BW_NUM because the chip under planning can support 160Mhz bandwidth on 5G band. Moreover, refine the filling of OFDM entry of struct rtw89_txpwr_limit by using the value corresponding to primary channel. E.g. center channel 38 (40Mhz bandwidth case) Originally OFDM entry was filled by value corresponding to 'ch - 2' (36) Now, we consider that it could be 36 or 40. E.g. cneter channel 42 (80Mhz bandwidth case) Originally OFDM entry was filled by value corresponding to 'ch - 6' (36) Now, we consider that it could be 36, 40, 44, or 48. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034042.9218-1-pkshih@realtek.com
2022-02-22rtw89: phy: handle txpwr lmt/lmt_ru of 6G bandZong-Zhe Yang2-3/+68
Add declarations of 6G stuff and extend rtw89_channel_to_idx() to map 6G's channels to 6G channel indexes. While 6G, correspondingly read 6G's entry for tx power limit and limit_ru. After this, we should pay attention to chip_info::support_bands. If a chip declares 6G support, it must configure txpwr_lmt_6g and txpwr_lmt_ru_6g in case accessing NULL pointer while setting tx power limit/limit_ru on 6G band. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034017.9160-2-pkshih@realtek.com
2022-02-22Merge tag 'iwlwifi-next-for-kalle-2022-02-18' of ↵Kalle Valo78-945/+2314
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next iwlwifi patches for v5.18 * Support UHB TAS enablement via BIOS; * Remove a bunch of W=1 warnings; * Add support for channel switch offload; * Support a new FW API command version; * Support 32 Rx AMPDU sessions in newer devices; * Support a few new FW API command versions; * Some debugging infra fixes; * A few fixes in the HE functionality; * Add a few new devices; * A bunch of fixes for W=1 and W=3 warnings; * Add support for a couple of new devices; * Fix a potential buffer underflow; * W=1 warnings clean up continues; * Some improvements and fixes in scanning; * More work on the Bz family of devices; * Add support for band disablement via BIOS; * Bump FW API version; * Fix config structure for one device; * Support a new FW API command version; * Support new queue allocation command; * Some more debugging improvements; * Some other small fixes, clean-ups and improvements.
2022-02-21ath11k: Fix frames flush failure caused by deadlockBaochen Qiang1-1/+1
We are seeing below warnings: kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0 this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work has no chance to run in 5 seconds. By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing ATH11K_FLUSH_TIMEOUT to 50 we get below warnings: kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds. kernel: [ 120.763169] Not tainted 5.10.90 #12 kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0 kernel: [ 120.763201] Call Trace: kernel: [ 120.763214] __schedule+0x785/0x12fa kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb kernel: [ 120.763242] schedule+0x7e/0xa1 kernel: [ 120.763253] schedule_timeout+0x98/0xfe kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a] kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2 kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763802] ? genl_rcv+0x36/0x36 kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7 kernel: [ 120.763829] genl_rcv+0x28/0x36 kernel: [ 120.763840] netlink_unicast+0x179/0x24b kernel: [ 120.763854] netlink_sendmsg+0x393/0x401 kernel: [ 120.763872] sock_sendmsg+0x72/0x76 kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6 kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2 kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1 kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf kernel: [ 120.763956] do_syscall_64+0x43/0x55 kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83 kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83 kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009 kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000 kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980 kernel: [ 120.764032] R13: 00007ffe604f0638 R14: 000059b40e98c360 R15: 00007ffe604f0558 ... kernel: [ 120.765230] INFO: task kworker/u32:26:4239 blocked for more than 20 seconds. kernel: [ 120.765238] Not tainted 5.10.90 #12 kernel: [ 120.765245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.765253] task:kworker/u32:26 state:D stack: 0 pid: 4239 ppid: 2 flags:0x00004080 kernel: [ 120.765284] Workqueue: phy0 ieee80211_iface_work [mac80211] kernel: [ 120.765295] Call Trace: kernel: [ 120.765306] __schedule+0x785/0x12fa kernel: [ 120.765316] ? find_held_lock+0x3d/0xb2 kernel: [ 120.765331] schedule+0x7e/0xa1 kernel: [ 120.765340] schedule_preempt_disabled+0x15/0x1e kernel: [ 120.765349] __mutex_lock_common+0x561/0xc0d kernel: [ 120.765375] ? ieee80211_sta_work+0x3e/0x1232 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.765390] mutex_lock_nested+0x20/0x26 kernel: [ 120.765416] ieee80211_sta_work+0x3e/0x1232 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.765430] ? skb_dequeue+0x54/0x5e kernel: [ 120.765456] ? ieee80211_iface_work+0x7b/0x339 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.765485] process_one_work+0x270/0x504 kernel: [ 120.765501] worker_thread+0x215/0x376 kernel: [ 120.765514] kthread+0x159/0x168 kernel: [ 120.765526] ? pr_cont_work+0x5b/0x5b kernel: [ 120.765536] ? kthread_blkcg+0x31/0x31 kernel: [ 120.765550] ret_from_fork+0x22/0x30 ... kernel: [ 120.765867] Showing all locks held in the system: ... kernel: [ 120.766164] 5 locks held by wpa_supplicant/924: kernel: [ 120.766172] #0: ffffffffb1e63eb0 (cb_lock){++++}-{3:3}, at: genl_rcv+0x19/0x36 kernel: [ 120.766197] #1: ffffffffb1e5b1c8 (rtnl_mutex){+.+.}-{3:3}, at: nl80211_pre_doit+0x2a/0x15c [cfg80211] kernel: [ 120.766238] #2: ffff99f08347cd08 (&wdev->mtx){+.+.}-{3:3}, at: nl80211_deauthenticate+0xde/0x123 [cfg80211] kernel: [ 120.766279] #3: ffff99f09df12a48 (&local->mtx){+.+.}-{3:3}, at: ieee80211_destroy_auth_data+0x9b/0xe6 [mac80211] kernel: [ 120.766321] #4: ffff99f09df12ce0 (&local->chanctx_mtx){+.+.}-{3:3}, at: ieee80211_vif_release_channel+0x5e/0x81 [mac80211] ... kernel: [ 120.766585] 3 locks held by kworker/u32:26/4239: kernel: [ 120.766593] #0: ffff99f04458f948 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0x19a/0x504 kernel: [ 120.766621] #1: ffffbad54b3cfe50 ((work_completion)(&sdata->work)){+.+.}-{0:0}, at: process_one_work+0x1c0/0x504 kernel: [ 120.766649] #2: ffff99f08347cd08 (&wdev->mtx){+.+.}-{3:3}, at: ieee80211_sta_work+0x3e/0x1232 [mac80211] With above info the issue is clear: First wmi_mgmt_tx_work is inserted to local->workqueue after sdata->work inserted, then wpa_supplicant acquires wdev->mtx in nl80211_deauthenticate and finally calls ath11k_mac_op_flush where it waits all mgmt. frames to be sent out by wmi_mgmt_tx_work. Meanwhile, sdata->work is blocked by wdev->mtx in ieee80211_sta_work, as a result wmi_mgmt_tx_work has no chance to run. Change to use ab->workqueue instead of local->workqueue to fix this issue. Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217084545.18844-1-quic_bqiang@quicinc.com
2022-02-21ath11k: Handle failure in qmi firmware readySeevalamuthu Mariappan1-1/+5
In some scenarios like firmware crashes during init time and hardware gets restarted after qmi firmware ready event. During restart, ath11k_core_qmi_firmware_ready() returns timeout. But, this failure is not handled and ATH11K_FLAG_REGISTERED is set. When hardware restart completed, firmware sends firmware ready event again. Since ATH11K_FLAG_REGISTERED is already set, ath11k handles this as core restart. Inits are not done because of previous timeout. But ath11k_core_restart does deinit's which causes NULL pointer crash. Fix this by handling failure from ath11k_core_qmi_firmware_ready(). Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-00881-QCAHKSWPL_SILICONZ-1 Signed-off-by: Seevalamuthu Mariappan <quic_seevalam@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1645079195-13564-1-git-send-email-quic_seevalam@quicinc.com
2022-02-21ath11k: Invalidate cached reo ring entry before accessing itRameshkumar Sundaram1-1/+1
REO2SW ring descriptor is currently allocated in cacheable memory. While reaping reo ring entries on second trial after updating head pointer, first entry is not invalidated before accessing it. This results in host reaping and using cached descriptor which is already overwritten in memory by DMA device (HW). Since the contents of descriptor(buffer id, peer info and other information bits) are outdated host throws errors like below while parsing corresponding MSDU's and drops them. [347712.048904] ath11k_pci 0004:01:00.0: msdu_done bit in attention is not set [349173.355503] ath11k_pci 0004:01:00.0: frame rx with invalid buf_id 962 Move the try_again: label above ath11k_hal_srng_access_begin() so that first entry will be invalidated and prefetched. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: 6452f0a3d565 ("ath11k: allocate dst ring descriptors from cacheable memory") Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/1645000354-32558-1-git-send-email-quic_ramess@quicinc.com
2022-02-21ath: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva1-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194915.GA904081@embeddedor
2022-02-21ath6kl: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva1-13/+13
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194857.GA904059@embeddedor
2022-02-21ath11k: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva5-11/+11
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194836.GA904035@embeddedor
2022-02-21ath10k: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220216194807.GA904008@embeddedor
Powered by cgit, Gruvboxed by Blaster4385.