summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2024-10-25wifi: rtw89: coex: Set Wi-Fi/Bluetooth priority for Wi-Fi scan caseChing-Te Ku
The priority table should be changed according to what the in using Bluetooth application is. To avoid Bluetooth audio + HID (mouse) will trigger the lag experience, update the priority table. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241019063131.9462-1-pkshih@realtek.com
2024-10-25wifi: rtw89: fix -Wenum-compare-conditional warningsArnd Bergmann
This is one of three drivers that trigger -Wenum-compare-conditional warnings with clang: drivers/net/wireless/realtek/rtw89/core.c:1806:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional] 1806 | return eht ? NL80211_RATE_INFO_EHT_GI_0_8 : | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1807 | NL80211_RATE_INFO_HE_GI_0_8; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw89/core.c:1810:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional] 1810 | return eht ? NL80211_RATE_INFO_EHT_GI_1_6 : | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1811 | NL80211_RATE_INFO_HE_GI_1_6; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw89/core.c:1813:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional] 1813 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 : | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1814 | NL80211_RATE_INFO_HE_GI_3_2; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtw89/core.c:1818:15: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional] 1818 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 : | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1819 | NL80211_RATE_INFO_HE_GI_3_2; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this case, all four warnings can be easily avoided by splitting the function into two separate ones, in a way that helps readability as well, at the expense of a few extra source lines. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241018152311.4023979-1-arnd@kernel.org
2024-10-25wifi: rtlwifi: use MODULE_FIRMWARE() to declare used firmwarePing-Ke Shih
Some used firmware are missing to be added to MODULE_FIRMWARE(). Add them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241018055651.21166-1-pkshih@realtek.com
2024-10-25wifi: rtw88: Refactor looping in rtw_phy_store_tx_power_by_rateMohammed Anees
The previous implementation included an unnecessary else condition paired with a continue statement. Since a check is already performed to determine if the band is either 2G or 5G, the else condition will never be triggered. We can remove this check. Signed-off-by: Mohammed Anees <pvmohammedanees2003@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241017080638.13074-1-pvmohammedanees2003@gmail.com
2024-10-25wifi: rtw89: regd: block 6 GHz if marked as N/A in regd mapZong-Zhe Yang
If 6 GHz of a country is marked as N/A in our regd map, we block 6 GHz channels now. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241016134457.9375-1-pkshih@realtek.com
2024-10-25wifi: rtw89: pci: add quirks by PCI subsystem ID for thermal protectionPing-Ke Shih
Specific PCI subsystem ID (SSID) of WiFi cards is used by specific customer who want to enable various features with different arguments. Define PCI SSID quirks tables to enable thermal protection with two kinds of thermal values for 110 and 120 degree Celsius. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241016133735.7571-3-pkshih@realtek.com
2024-10-25wifi: rtw89: add thermal protectionPing-Ke Shih
To prevent chip overheating, reduce TX duty as the mechanism of thermal protection. When temperature is raising over a threshold, send a firmware command to reduce TX duty. If temperature is still raising, higher level is adopted to have lower active duration. The equation and unit of thermal values are different from chip to chip, so define constant thresholds of thermal value to corresponding absolute temperature of 110 and 120 degree Celsius. Latter patch will decide which thermal threshold is adopted, and current is still not enable thermal protection. For debugging, add a flag to disable_dm that thermal protection can be disabled to clarify low throughput in field. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241016133735.7571-2-pkshih@realtek.com
2024-10-23wifi: mac80211: call rate_control_rate_update() for link STAJohannes Berg
In order to update the right link information, call the update rate_control_rate_update() with the right link_sta, and then pass that through to the driver's sta_rc_update() method. The software rate control still doesn't support it, but that'll be skipped by not having a rate control ref. Since it now operates on a link sta, rename the driver method. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241007144851.5851b6b5fd41.Ibdf50d96afa4b761dd9b9dfd54a1147e77a75329@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-20wifi: rtw89: sar: add supported UNII-4 frequency range along with UNII-3 of ↵Ping-Ke Shih
SAR subband The UNII-4 uses the same SAR value of UNII-3, so add UNII-4 frequency range and change the enum name to represent UNII-3 and UNII-4. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009071619.16841-1-pkshih@realtek.com
2024-10-20wifi: rtw89: 8852c: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih
The return type of error code of rtw8852c_pwr_{on,off}_func() and its callee is 'int'. Correct it. Addresses-Coverity-ID: 1626056 ("Overflowed constant") Addresses-Coverity-ID: 1627945 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-7-pkshih@realtek.com
2024-10-20wifi: rtw89: 8852bt: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih
The return type of error code of rtw8852bt_pwr_{on,off}_func() and its callee is 'int'. Correct it. Addresses-Coverity-ID: 1630962 ("Overflowed constant") Addresses-Coverity-ID: 1632126 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-6-pkshih@realtek.com
2024-10-20wifi: rtw89: 8852b: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih
The return type of error code of rtw8852b_pwr_{on,off}_func() and its callee is 'int'. Correct it. Addresses-Coverity-ID: 1622433 ("Overflowed constant") Addresses-Coverity-ID: 1630710 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-5-pkshih@realtek.com
2024-10-20wifi: rtw89: 8851b: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih
The return type of error code of rtw8851b_pwr_{on,off}_func() and its callee is 'int'. Correct it. Addresses-Coverity-ID: 1624679 ("Overflowed constant") Addresses-Coverity-ID: 1630970 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-4-pkshih@realtek.com
2024-10-20wifi: rtw89: pci: use 'int' as return type of error code in ↵Ping-Ke Shih
poll_{tx,rx}dma_ch_idle() The return type of error code of read_poll_timeout() and rtw89_pci_poll_{tx,rx}dma_ch_idle_ax() and must be 'int'. Correct them accordingly. Addresses-Coverity-ID: 1622341 ("Overflowed constant") Addresses-Coverity-ID: 1627296 ("Overflowed constant") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-3-pkshih@realtek.com
2024-10-20wifi: rtw89: wow: cast nd_config->delay to u64 in tsf arithmeticPing-Ke Shih
The type of tsf arithmetic is u64 += u16 * int; When (u16 * int) is larger than 0x7FFFFFFF, the value casting to u64 with sign-extension will become all 1 in upper 32 bits part. To meet the case, u16 value should be larger than 20491 (0x7FFFFFFF / 104800). Fortunately the meaning of 20491 is delay time of WoWLAN net detection in unit of second, so 20491 seconds (5.7 hours) might not a real case we can meet. Addresses-Coverity-ID: 1620910 ("Unintended sign extension") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241009004300.8144-2-pkshih@realtek.com
2024-10-17wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171Bitterblue Smith
This ID appears to be RTL8188SU, not RTL8192DU. This is the wrong driver for RTL8188SU. The r8712u driver from staging handles this ID. I think this ID comes from the original rtl8192du driver from Realtek. I don't know if they added it by mistake, or it was actually used for two different chips. RTL8188SU with this ID exists in the wild. RTL8192DU with this ID probably doesn't. Fixes: b5dc8873b6ff ("wifi: rtlwifi: Add rtl8192du/sw.c") Cc: stable@vger.kernel.org # v6.11 Closes: https://github.com/lwfinger/rtl8192du/issues/105 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/40245564-41fe-4a5e-881f-cd517255b20a@gmail.com
2024-10-17wifi: rtw88: Fix the RX aggregation in USB 3 modeBitterblue Smith
RTL8822CU, RTL8822BU, and RTL8821CU don't need BIT_EN_PRE_CALC. In fact, RTL8822BU in USB 3 mode doesn't pass all the frames to the driver, resulting in much lower download speed than normal: $ iperf3 -c 192.168.0.1 -R Connecting to host 192.168.0.1, port 5201 Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 43062 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 26.9 MBytes 225 Mbits/sec [ 5] 1.00-2.00 sec 7.50 MBytes 62.9 Mbits/sec [ 5] 2.00-3.00 sec 8.50 MBytes 71.3 Mbits/sec [ 5] 3.00-4.00 sec 8.38 MBytes 70.3 Mbits/sec [ 5] 4.00-5.00 sec 7.75 MBytes 65.0 Mbits/sec [ 5] 5.00-6.00 sec 8.00 MBytes 67.1 Mbits/sec [ 5] 6.00-7.00 sec 8.00 MBytes 67.1 Mbits/sec [ 5] 7.00-8.00 sec 7.75 MBytes 65.0 Mbits/sec [ 5] 8.00-9.00 sec 7.88 MBytes 66.1 Mbits/sec [ 5] 9.00-10.00 sec 7.88 MBytes 66.1 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.02 sec 102 MBytes 85.1 Mbits/sec 224 sender [ 5] 0.00-10.00 sec 98.6 MBytes 82.7 Mbits/sec receiver Don't set BIT_EN_PRE_CALC. Then the speed is much better: % iperf3 -c 192.168.0.1 -R Connecting to host 192.168.0.1, port 5201 Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 39000 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 52.8 MBytes 442 Mbits/sec [ 5] 1.00-2.00 sec 71.9 MBytes 603 Mbits/sec [ 5] 2.00-3.00 sec 74.8 MBytes 627 Mbits/sec [ 5] 3.00-4.00 sec 75.9 MBytes 636 Mbits/sec [ 5] 4.00-5.00 sec 76.0 MBytes 638 Mbits/sec [ 5] 5.00-6.00 sec 74.1 MBytes 622 Mbits/sec [ 5] 6.00-7.00 sec 74.0 MBytes 621 Mbits/sec [ 5] 7.00-8.00 sec 76.0 MBytes 638 Mbits/sec [ 5] 8.00-9.00 sec 74.4 MBytes 624 Mbits/sec [ 5] 9.00-10.00 sec 63.9 MBytes 536 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 717 MBytes 601 Mbits/sec 24 sender [ 5] 0.00-10.00 sec 714 MBytes 599 Mbits/sec receiver Fixes: 002a5db9a52a ("wifi: rtw88: Enable USB RX aggregation for 8822c/8822b/8821c") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/afb94a82-3d18-459e-97fc-1a217608cdf0@gmail.com
2024-10-17wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hostsPing-Ke Shih
The early chips including RTL8852A, RTL8851B, RTL8852B and RTL8852BT have interoperability problems of 36-bit DMA with some PCI hosts. Rollback to 32-bit DMA by default, and only enable 36-bit DMA for tested platforms. Since all Intel platforms we have can work correctly, add the vendor ID to white list. Otherwise, list vendor/device ID of bridge we have tested. Fixes: 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address") Reported-by: Marcel Weißenbach <mweissenbach@ignaz.org> Closes: https://lore.kernel.org/linux-wireless/20240918073237.Horde.VLueh0_KaiDw-9asEEcdM84@ignaz.org/T/#m07c5694df1acb173a42e1a0bab7ac22bd231a2b8 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Marcel Weißenbach <mweissenbach@ignaz.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240924021633.19861-1-pkshih@realtek.com
2024-10-10wifi: rtw89: wow: do not configure CPU IO to receive packets for old firmwareChin-Yen Lee
The older firmware of 8852A and 8852B can't receive packets via CPU IO function and will lead to WoWLAN fail if calling it. So use firmware feature to distinguish. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241004065408.10261-1-pkshih@realtek.com
2024-10-10wifi: rtw89: coex: Add function to reorder Wi-Fi firmware report indexChing-Te Ku
To parsing firmware report correctly, driver need to re-order the report index to match with different chips and different Wi-Fi firmware version. Use wrong index to parse the report will lead the coexistence run into wrong mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241003105140.10867-5-pkshih@realtek.com
2024-10-10wifi: rtw89: coex: Solved BT PAN profile idle decrease Wi-Fi throughputChing-Te Ku
Some Bluetooth device will make up connection as PAN link, though the connection is idle, it will still report the PAN link is active. The coexistence mechanism will enable TDMA to protect the PAN, it makes Wi-Fi throughput degrade at least 50%. But the link is idle, don't need so much bandwidth. Add TDMA case to let Wi-Fi can do traffic 80% bandwidth. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241003105140.10867-4-pkshih@realtek.com
2024-10-10wifi: rtw89: coex: Reorder Bluetooth info related logicChing-Te Ku
Reorder Bluetooth firmware related event index, it should be the same with Wi-Fi firmware definition. To fix coexistence can not recognize Bluetooth PAN(Personal area network) profile correctly, modified the related logic. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241003105140.10867-3-pkshih@realtek.com
2024-10-10wifi: rtw89: coex: Update priority setting for Wi-Fi is scanningChing-Te Ku
Update coexistence priority setting for Wi-Fi scanning channel, the new setting will allow Wi-Fi do RX while Bluetooth audio is not busy. Forced to set new TDMA policy while RF calibration request come, to make sure the calibration can do well, and switch to normal setting while the calibration is done. Remove the code that no longer use. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241003105140.10867-2-pkshih@realtek.com
2024-10-05wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabledMartin Kaistra
In STA+AP concurrent mode, performing a scan operation on one vif temporarily stops beacons on the other. When the scan is completed, beacons are enabled again with BSS_CHANGED_BEACON_ENABLED. We can observe that no beacons are being sent when just rtl8xxxu_start_tx_beacon() is being called. Thus, also perform update_beacon_work in order to restore beaconing. Fixes: cde8848cad0b ("wifi: rtl8xxxu: Add beacon functions") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240930084955.455241-1-martin.kaistra@linutronix.de
2024-10-05wifi: rtw89: debug: add beacon RSSI for debuggingPing-Ke Shih
In range test, the RSSI is helpful to check attenuation of cable and align difference between environments. Since data packets can be transmitted with different rate and power, the RSSI of all packets can be variant. Oppositely beacon is transmitted with the same rate and power, so beacon RSSI will be relatively invariant, and more helpful to diagnose problems. The output of beacon RSSI in unit of dBm looks like: Beacon: 19 (-33 dBm), TF: 0 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240927013512.7106-1-pkshih@realtek.com
2024-10-01wifi: rtw89: handle entity active flag per PHYZong-Zhe Yang
Originally, we have an active flag to record whether we have set PHY once. After impending MLO support, there will be dual-PHY and they can be set individually on Wi-Fi 7 chips. So, we now have active flag per PHY and handle them individually. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925020119.13170-3-pkshih@realtek.com
2024-10-01wifi: rtw89: initialize dual HW bands for MLO and control them by linkZong-Zhe Yang
To support MLO, we initialize things on dual HW bands of Wi-Fi 7 chip. And, each link will indicate which HW band it's bound to. So, in link control flow, we control major things based on target link's HW band instead of hardcode like RTW89_PHY_X or RTW89_MAC_X. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925020119.13170-2-pkshih@realtek.com
2024-10-01wifi: rtw89: 8852ce: set offset K of PCI PHY EQ to manual mode to improve ↵Ping-Ke Shih
compatibility Read calibration value of PCI RX offset, and set to manual mode as the value at PCI probe to prevent abnormal calibration results at runtime. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925013901.9835-5-pkshih@realtek.com
2024-10-01wifi: rtw89: 8852ce: fix gray code conversion for filter out EQPing-Ke Shih
To use manual mode to set value of filter out EQ, read the source value of filter out EQ coded in gray code, and write to the target register in binary number. The function to convert from gray code to binary number is wrong originally, causing unexpected EQ, so fix it. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925013901.9835-4-pkshih@realtek.com
2024-10-01wifi: rtw89: 8922ae: disable PCI PHY EQ to improve compatibilityPing-Ke Shih
For adaption EQ circuit, this HW design and affected by EIEOS (Electrical Idle Exit Order Set) amplitude from platform and process from IC, so disable EQ to improve that. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925013901.9835-3-pkshih@realtek.com
2024-10-01wifi: rtw89: pci: consolidate PCI basic configurations for probe and resumePing-Ke Shih
The PCI settings aren't always persistent after chip suspends, so reconfigure the settings after chip resumes. Since most of these settings are the same, consolidate them into a function to avoid missing somewhere. Fix the missing case of 8922AE resume flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240925013901.9835-2-pkshih@realtek.com
2024-09-26wifi: rtw88: Parse the RX descriptor with a single functionBitterblue Smith
rtw8703b_query_rx_desc(), rtw8723d_query_rx_desc(), rtw8821c_query_rx_desc(), rtw8822b_query_rx_desc(), and rtw8822c_query_rx_desc() are almost identical, so replace them all with a single function, rtw_rx_query_rx_desc(). Also, access the RX descriptor using a struct with __le32 members and le32_get_bits(). Tested with RTL8811CU, RTL8811AU, and RTL8812AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Ping-Ke Shih <pkshih@realtek.com> # RTL8723DE and RTL8822CE Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/913f1747-38fc-4409-85a4-57bb9cee506b@gmail.com
2024-09-26wifi: rtw89: 8852c: rfk: remove unnecessary assignment of return value of ↵Ping-Ke Shih
_dpk_dgain_read() The return value of _dpk_dgain_read() is not used afterward, so remove it safely. Addresses-Coverity-ID: 1504753 ("Unused value") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240919081216.28505-4-pkshih@realtek.com
2024-09-26wifi: rtw89: coex: initialize local .dbcc_2g_phy in _set_btg_ctrl()Ping-Ke Shih
For the case of DBCC enabled and fwrole version 0, the local variable wl_rinfo.dbcc_2g_phy might not be set by following for-loop, leading uninitialized variable before using. Addresses-Coverity-ID: 1586724 ("Uninitialized scalar variable") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240919081216.28505-3-pkshih@realtek.com
2024-09-26wifi: rtw89: check return value of ieee80211_probereq_get() for RNRPing-Ke Shih
The return value of ieee80211_probereq_get() might be NULL, so check it before using to avoid NULL pointer access. Addresses-Coverity-ID: 1529805 ("Dereference null return value") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240919081216.28505-2-pkshih@realtek.com
2024-09-24wifi: rtw89: tweak driver architecture for impending MLO supportZong-Zhe Yang
The drv_priv hooked to mac80211 become as below. (drv_priv) (instance-0) +---------------+ +-----------+ +----------------+ | ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link | +---------------+ +-----------+ | +----------------+ | | (instance-1) | +----------------+ +---> | rtw89_vif_link | +----------------+ (drv_priv) (instance-0) +---------------+ +-----------+ +----------------+ | ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link | +---------------+ +-----------+ | +----------------+ | | (instance-1) | +----------------+ +---> | rtw89_sta_link | +----------------+ The relation bewteen mac80211 link_id and our link instance is like below. |\ (link_id) | \ 0 -------- | | 1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0 2 -------- | | ... | | ------ instance-1 (link_id: Y) -> work on HW band 1 14 -------- | | | / |/ N.B. For cases of non-MLD connection, we set our link instance-0 active with link_id 0. So, our code flow can be compatible between non-MLD connection and MLD connection. Based on above, we tweak entire driver architecture first. But, we don't dynamically enable multiple links here. That will be handled separately. Most of the things changed here are changing flows to iterate all active links and read bss_conf/link_sta data according to target link. And, for cases of scan, ROC, WOW, we use instance-0 to deal with the request. There are some things listed below, which work for now but need to extend before multiple active links. 1. tx path select suitable link instance among multiple active links 2. rx path determine rx link by PPDU instead of always link instance-0 3. CAM apply MLD pairwise key to any active links dynamically Besides, PS code cannot easily work along with tweaking architecture. With supporting MLO flag (currently false), we disable PS first and will fix it by another commit in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-24wifi: rtw89: refactor STA related func ahead for MLOZong-Zhe Yang
Refactor STA related functions, e.g. add/assoc/disassoc/disconnect/remove to separate most link stuffs into sub-functions for MLO reuse. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-7-pkshih@realtek.com
2024-09-24wifi: rtw89: refactor VIF related func ahead for MLOZong-Zhe Yang
Refactor VIF related functions, e.g. add/remove/assoc/mapping to separate most link stuffs into sub-functions for MLO reuse. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-6-pkshih@realtek.com
2024-09-24wifi: rtw89: read link_sta corresponding to the linkZong-Zhe Yang
Tweak code to not always access sta->deflink directly. Instead, according to link_id, read target link_sta from sta->link[]. For now, rtwsta_link->link_id keeps 0. When driver starts to support MLO, the link_id will be assigned. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-5-pkshih@realtek.com
2024-09-24wifi: rtw89: read bss_conf corresponding to the linkZong-Zhe Yang
Tweak code to not always access vif->bss_conf directly. Instead, according to link_id, read target bss_conf from vif->link_conf[]. For now, rtwvif_link->link_id keeps 0. When driver starts to support MLO, the link_id will be assigned. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-4-pkshih@realtek.com
2024-09-24wifi: rtw89: rename rtw89_sta to rtw89_sta_link ahead for MLOZong-Zhe Yang
This is an intermediate version that is separated from subsequent major MLO changes, so some functions' namings are not really determined here. e.g. struct rtw89_sta_link *sta_to_rtwsta_safe(struct ieee80211_sta *sta) No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-3-pkshih@realtek.com
2024-09-24wifi: rtw89: rename rtw89_vif to rtw89_vif_link ahead for MLOZong-Zhe Yang
This is an intermediate version that is separated from subsequent major MLO changes, so some functions' namings are not really determined here. e.g. struct rtw89_vif_link *vif_to_rtwvif_safe(struct ieee80211_vif *vif) No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240916053158.47350-2-pkshih@realtek.com
2024-09-20wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skbPing-Ke Shih
When removing kernel modules by: rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core Driver uses skb_queue_purge() to purge TX skb, but not report tx status causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue() to correct this. Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing between TX work and purge TX queue, flush and destroy TX work in advance. wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local choice (Reason: 3=DEAUTH_LEAVING) ------------[ cut here ]------------ Have pending ack frames! WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691 ieee80211_free_ack_frame+0x5c/0x90 [mac80211] CPU: 3 PID: 9232 Comm: rmmod Tainted: G C 6.10.1-200.fc40.aarch64 #1 Hardware name: pine64 Pine64 PinePhone Braveheart (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211] sp : ffff80008c1b37b0 x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0 x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000 x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000 x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964 x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0 x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000 Call trace: ieee80211_free_ack_frame+0x5c/0x90 [mac80211] idr_for_each+0x74/0x110 ieee80211_free_hw+0x44/0xe8 [mac80211] rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio] sdio_bus_remove+0x44/0x180 device_remove+0x54/0x90 device_release_driver_internal+0x1d4/0x238 driver_detach+0x54/0xc0 bus_remove_driver+0x78/0x108 driver_unregister+0x38/0x78 sdio_unregister_driver+0x2c/0x40 rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs] __do_sys_delete_module.isra.0+0x190/0x338 __arm64_sys_delete_module+0x1c/0x30 invoke_syscall+0x74/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 ---[ end trace 0000000000000000 ]--- Reported-by: Peter Robinson <pbrobinson@gmail.com> Closes: https://lore.kernel.org/linux-wireless/CALeDE9OAa56KMzgknaCD3quOgYuEHFx9_hcT=OFgmMAb+8MPyA@mail.gmail.com/ Tested-by: Ping-Ke Shih <pkshih@realtek.com> # 8723DU Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240822014255.10211-2-pkshih@realtek.com
2024-09-20wifi: rtw88: Constify some arrays and structsBitterblue Smith
These are never modified, so make them const: card_enable_flow_8703b card_disable_flow_8703b rtw8703b_ops rtw8723d_ops card_enable_flow_8723d card_disable_flow_8723d trans_carddis_to_cardemu_8821c trans_cardemu_to_act_8821c trans_act_to_cardemu_8821c trans_cardemu_to_carddis_8821c card_enable_flow_8821c card_disable_flow_8821c rtw8821c_dig page_table_8821c rqpn_table_8821c prioq_addrs_8821c rtw8821c_ops card_enable_flow_8822b card_disable_flow_8822b prioq_addrs_8822b rtw8822b_ops rtw8822b_edcca_th card_enable_flow_8822c card_disable_flow_8822c prioq_addrs_8822c rtw8822c_ops rtw8822c_edcca_th Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/dae7994f-3491-40de-b537-ebf68df084bb@gmail.com
2024-09-20wifi: rtw89: rfk: update firmware debug log of DACK to v2Ping-Ke Shih
Update DACK (digital-to-analog converters calibration) log to v2 by firmware C2H events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-6-pkshih@realtek.com
2024-09-20wifi: rtw89: rfk: add firmware debug log of IQKPing-Ke Shih
Print out IQ signal calibration log from firmware C2H events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-5-pkshih@realtek.com
2024-09-20wifi: rtw89: rfk: add firmware debug log of TSSIPing-Ke Shih
TSSI is short for transmitter signal strength indication. Print out the TSSI log from firmware C2H events. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-4-pkshih@realtek.com
2024-09-20wifi: rtw89: 8922a: rfk: support firmware command RX DCK v1 formatPing-Ke Shih
RX DCK stands for receiver DC calibration. The v1 format adds a field to indicate the calibration is for operation channel or an average value for all scanning channels. Update the format accordingly, and increase firmware format sequence to 2. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-3-pkshih@realtek.com
2024-09-20wifi: rtw89: 8922a: rfk: enlarge TSSI timeout time to 20msPing-Ke Shih
Firmware needs more time to execute TSSI calibration command. Enlarge timeout time accordingly, otherwise driver throws messages: rtw89_8922ae 0000:03:00.0: failed to wait RF TSSI Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240913071340.41822-2-pkshih@realtek.com
2024-09-20wifi: rtlwifi: make read-only arrays static constColin Ian King
Don't populate the read-only arrays params, toshiba_smid1, toshiba_smid2, samsung_smid and lenovo_smid on the stack at run time, instead make them static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240912135335.590464-1-colin.i.king@gmail.com