- 24 Feb, 2022 17 commits
-
-
Wan Jiabing authored
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>
-
Lorenzo Bianconi authored
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:
-
Nicolas Cavallari authored
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:
-
Nicolas Cavallari authored
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 authored
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:
-
Felix Fietkau authored
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: -
Changcheng Deng authored
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:
-
MeiChia Chiu authored
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: 16bff457 ("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:
-
Ryder Lee authored
Add missing band idx check for DBDC cases. Signed-off-by:
-
Yang Li authored
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:
-
Chad Monroe authored
Newer chips such as MT7915 require up to 16-bits for this field. Fixes: 49126ac1 ("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 authored
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: c17780e7 ("mt76: mt7915: add txfree event v3") Signed-off-by:
-
Lorenzo Bianconi authored
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: 988845c9 ("mt76: mt7915: add support for passing chip/firmware debug data to user space") Signed-off-by:
-
Deren Wu authored
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:Deren Wu <deren.wu@mediatek.com> Signed-off-by:
-
Peter Chiu authored
Initialize smps mode to prevent firmware rate adaptation issue. Reviewed-by:
Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by:
-
Bo Jiao authored
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:
Shayne Chen <shayne.chen@mediatek.com> Signed-off-by:
Bo Jiao <Bo.Jiao@mediatek.com> Reviewed-by:
-
Bo Jiao authored
This adds MT7986 SoC integrated multi-band 4x4 WiFi 6/6E. Co-developed-by:
-
- 23 Feb, 2022 7 commits
-
-
Peter Chiu authored
Add an entry for MT7986 SoC. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Deren Wu authored
For non-mmio devices, should set fc values to proper txwi config Fixes: 48fab5bb ("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:
-
Shayne Chen authored
Free the skb of fw monitor packets. Signed-off-by:
-
Bo Jiao authored
Fix channel state update error issue due to wrong register access for mt7916. Signed-off-by:
-
Lorenzo Bianconi authored
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: dc5399a5 ("mt76: reverse the first fragmented frame to 802.11") Signed-off-by: -
Lorenzo Bianconi authored
Add SAR spec support to mt7615 driver to allow configuring SAR power limitations on the frequency ranges from the userland. Signed-off-by:
-
Johan Almbladh authored
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:
-
- 22 Feb, 2022 5 commits
-
-
Ping-Ke Shih authored
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
-
Yi-Tang Chiu authored
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:
-
Zong-Zhe Yang authored
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:
-
Zong-Zhe Yang authored
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:
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2022-02-18' of 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.
-
- 21 Feb, 2022 10 commits
-
-
Gustavo A. R. Silva authored
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/78Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Acked-by:
-
Gustavo A. R. Silva authored
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/78Signed-off-by:
-
Tom Rix authored
Remove the second 'info'. Replacements 'adventages' with 'advantages' 'strenth' with 'strength' 'atleast' with 'at least' 'thr'u'' with 'through' 'capabilty' with 'capability' 'controll' with 'control' 'ourself' with 'ourselves' 'noone' with 'no one' 'cores' to 'core's' and 'core' Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Jiri Kosina authored
ieee80211_tx_h_select_key() is performing a series of RCU dereferences, but rtw89_core_txq_push() is calling it (via ieee80211_tx_dequeue_ni()) without RCU read-side lock held; fix that. This addresses the splat below. ============================= WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E ----------------------------- net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/u33:0/184: #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660 #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660 stack backtrace: CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G E 5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x58/0x71 ieee80211_tx_h_select_key+0x2c0/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] process_one_work+0x2d8/0x660 worker_thread+0x39/0x3e0 ? process_one_work+0x660/0x660 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> ============================= WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E ----------------------------- net/mac80211/tx.c:607 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by kworker/u33:0/184: #0: ffff9c0b14811d38 ((wq_completion)rtw89_tx_wq){+.+.}-{0:0}, at: process_one_work+0x258/0x660 #1: ffffb97380cf3e78 ((work_completion)(&rtwdev->txq_work)){+.+.}-{0:0}, at: process_one_work+0x258/0x660 stack backtrace: CPU: 8 PID: 184 Comm: kworker/u33:0 Tainted: G E 5.17.0-rc4-00003-gccad664b7f14 #3 473b49ab0e7c2d6af2900c756bfd04efd7a9de13 Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021 Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] Call Trace: <TASK> dump_stack_lvl+0x58/0x71 ieee80211_tx_h_select_key+0x464/0x530 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] ieee80211_tx_dequeue+0x1a7/0x1260 [mac80211 911c23e2351c0ae60b597a67b1204a5ea955e365] rtw89_core_txq_work+0x1a6/0x420 [rtw89_core b39ba493f2e517ad75e0f8187ecc24edf58bbbea] process_one_work+0x2d8/0x660 worker_thread+0x39/0x3e0 ? process_one_work+0x660/0x660 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> Signed-off-by:Jiri Kosina <jkosina@suse.cz> Acked-by:
-
Ching-Te Ku authored
Enable Wi-Fi/BT mailbox 0x45 handshake and Wi-Fi MIMO power save mechanism for Bluetooth gaming controller. BTCOEX Version: 22020720-2020 Desired_BT_Coex_Ver: 0x20 Desired_WL_FW_Ver: 9.9.11 Signed-off-by:
Ching-Te Ku <ku920601@realtek.com> Signed-off-by:
-
Ching-Te Ku authored
In order to recognize the gaming controller HID, make a C2H/H2C/Mailbox handshake to collect all the connected information from BT. Signed-off-by:
-
Ching-Te Ku authored
To keep high sensitivity reaction, Bluetooth gaming controller will send packet very frequently, it will make WLAN performance very poor. To solve this situation, MIMO PS mechanism makes WLAN/BT own an antenna itself, WLAN quits 2SS performance but it can get a stable 1SS performance and Bluetooth gaming controller can keep sensitivity reaction at the same time. Signed-off-by:
-
Ching-Te Ku authored
If BT PTA counter can not update regularly, it will lead coex mechanism run into some unexpected state. Signed-off-by:
-
Ching-Te Ku authored
Disable power save TDMA mechanism under HFP COEX, so WLAN can TX/RX full time. Signed-off-by:
-
Chin-Yen Lee authored
In some case, wifi chip need to be configed to be TX/RX 1ss mode. For this mode, wifi components, such as MAC/BB/RF, need to be specially set, and driver need to send SMPS action frame to inform AP. Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
- 18 Feb, 2022 1 commit
-
-
Kees Cook authored
To avoid a run-time false positive in the stricter FORTIFY_SOURCE memcpy() checks, split the memcpy() into the struct and the data. Additionally switch the data member to a flexible array to follow modern language conventions. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
