summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* wifi: rtw88: Let each driver control the power on/off processBitterblue Smith2024-10-2910-9/+36
| | | | | | | | | | | RTL8821AU and RTL8812AU have to do some things differently, so let them have full control. The other chips use the same functions as before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
* wifi: rtw88: Allow rtw_chip_info.ltecoex_addr to be NULLBitterblue Smith2024-10-291-3/+11
| | | | | | | | | RTL8821A doesn't have this. Trying to use it results in error messages, so don't try if ltecoex_addr is NULL. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com
* wifi: rtw88: Extend the init table parsing for RTL8812AUBitterblue Smith2024-10-292-8/+69
| | | | | | | | | | The chips supported so far only use the first condition, and so the parsing code ignores the second condition. RTL8812AU's init tables use the second condition also. Make the parsing code check it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com
* wifi: rtw88: Allow different C2H RA report sizesBitterblue Smith2024-10-298-10/+34
| | | | | | | | | | | The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes. Avoid the "invalid ra report c2h length" error. Also, use a struct and u8_get_bits() to access the RA report C2H. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
* wifi: rtw88: Dump the HW features only for some chipsBitterblue Smith2024-10-297-0/+9
| | | | | | | | | RTL8821AU and RTL8812AU don't support this. They hit the "failed to read hw feature report" error. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8becd851-8760-4480-8e8c-c4869ce72507@gmail.com
* wifi: rtw88: Add some definitions for RTL8821AU/RTL8812AUBitterblue Smith2024-10-294-36/+177
| | | | | | | | | | | | | | | | | Add 8821A and 8812A chip type enums. Add cck_high_power member to struct rtw_hal. This will be used to calculate the RX signal strength of RTL8812AU. Add various register definitions which will be used by the new drivers. Move some existing register definitions from rtw8821c.h and rtw8822b.h. They were duplicated in those headers and will also be used by the new drivers. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com
* wifi: rtw88: Report the signal strength only if it's knownBitterblue Smith2024-10-291-4/+8
| | | | | | | | | | | | RTL8811CU doesn't report the signal strength for many (any?) data frames. When the signal strength is not known, set RX_FLAG_NO_SIGNAL_VAL in order to avoid reporting a signal strength of 0. 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/f7e1e448-2c9b-498f-b8b1-a14dd967d7d3@gmail.com
* wifi: rtw89: 8922a: extend RFK handling and consider MLOZong-Zhe Yang2024-10-295-44/+70
| | | | | | | | | Extend FW and driver handling on RFK to support it on both HW bands. Then, according to MLO cases, do the corresponding RF settings. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-6-pkshih@realtek.com
* wifi: rtw89: tweak setting of channel and TX power for MLOZong-Zhe Yang2024-10-294-65/+149
| | | | | | | | | | | | | | Setting of channel and TX power depend on channel contexts, but original code cannot handle combination of MCC (multi-channel concurrency) and MLO well. So according to active interfaces, we generate a table for current channel contexts. And then based on entity mode, we get the corresponding channel context to apply during channel or TX power setting. When MLO is supported, there will be dual-PHY and we will apply the channel context of the 2nd link to the 2nd PHY. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-5-pkshih@realtek.com
* wifi: rtw89: chan: manage active interfacesZong-Zhe Yang2024-10-294-13/+108
| | | | | | | | | | | | | | | | | To set channel well for combination of MCC (multi-channel concurrency) and impending MLO support, we need a method to manage relation between active interfaces and channel contexts. If an interface owns at least one active link, we call it an active interface. We add a list to manage active ones. Basically, the list follows the active order except for the below case. To be compatible with legacy behavior, the first interface that owns the first channel context will put at the first entry in the list when recalculating. Besides, MCC can also select and fill roles based on the above active list. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-4-pkshih@realtek.com
* wifi: rtw89: Add encryption support for MLO connectionsPo-Hao Huang2024-10-292-6/+69
| | | | | | | | | | In order to make encryption/decryption work properly with MLO connections, MLD address needs to be filled in so circuits can operate with the correct information. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-3-pkshih@realtek.com
* wifi: rtw89: Add header conversion for MLO connectionsPo-Hao Huang2024-10-292-0/+17
| | | | | | | | | | | For MLO connections, this setting replaces 802.11 header addresses to according link addresses based on each packet's destination. The fields most likely to be replaced would be both A1 and A2. For legacy connections, it's the same with or without the conversion. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241022083106.149252-2-pkshih@realtek.com
* wifi: rtw89: unlock on error path in rtw89_ops_unassign_vif_chanctx()Dan Carpenter2024-10-251-0/+1
| | | | | | | | | | We need to call mutex_unlock() on this error path. Fixes: aad0394e7a02 ("wifi: rtw89: tweak driver architecture for impending MLO support") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/8683a712-ffc2-466b-8382-0b264719f8ef@stanley.mountain
* wifi: rtw89: Fix TX fail with A2DP after scanningPo-Hao Huang2024-10-251-2/+2
| | | | | | | | | | | | | | There might be some racing between BT and WiFi after scan. Since one of the TX related register will be modified by both FW and rtw89_set_channel() in driver, which could cause Tx fail. Reorder the calling sequence to only notify coexistence mechanism after rtw89_set_channel() is called, so that there are no concurrent operations. Fixes: 5f499ce69b8d ("wifi: rtw89: pause/proceed MCC for ROC and HW scan") Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241021063219.22613-1-pkshih@realtek.com
* wifi: rtw89: coex: Set Wi-Fi/Bluetooth priority for Wi-Fi scan caseChing-Te Ku2024-10-251-1/+1
| | | | | | | | | | 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
* wifi: rtw89: fix -Wenum-compare-conditional warningsArnd Bergmann2024-10-251-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* wifi: rtlwifi: use MODULE_FIRMWARE() to declare used firmwarePing-Ke Shih2024-10-252-1/+5
| | | | | | | | 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
* wifi: rtw88: Refactor looping in rtw_phy_store_tx_power_by_rateMohammed Anees2024-10-251-3/+1
| | | | | | | | | | | | | 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
* wifi: rtw89: regd: block 6 GHz if marked as N/A in regd mapZong-Zhe Yang2024-10-251-5/+27
| | | | | | | | | 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
* wifi: rtw89: pci: add quirks by PCI subsystem ID for thermal protectionPing-Ke Shih2024-10-2510-0/+86
| | | | | | | | | | | 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
* wifi: rtw89: add thermal protectionPing-Ke Shih2024-10-2513-5/+138
| | | | | | | | | | | | | | | | | | | | 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
* wifi: rtw89: sar: add supported UNII-4 frequency range along with UNII-3 of ↵Ping-Ke Shih2024-10-202-4/+4
| | | | | | | | | | 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
* wifi: rtw89: 8852c: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih2024-10-201-2/+2
| | | | | | | | | | | 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
* wifi: rtw89: 8852bt: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih2024-10-201-2/+2
| | | | | | | | | | | 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
* wifi: rtw89: 8852b: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih2024-10-201-2/+2
| | | | | | | | | | | 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
* wifi: rtw89: 8851b: use 'int' as return type of error code pwr_{on,off}_func()Ping-Ke Shih2024-10-201-2/+2
| | | | | | | | | | | 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
* wifi: rtw89: pci: use 'int' as return type of error code in ↵Ping-Ke Shih2024-10-201-2/+4
| | | | | | | | | | | | | | 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
* wifi: rtw89: wow: cast nd_config->delay to u64 in tsf arithmeticPing-Ke Shih2024-10-201-1/+1
| | | | | | | | | | | | | | | | | | 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
* Merge tag 'rtw-next-2024-10-10' of https://github.com/pkshih/rtwKalle Valo2024-10-1750-2406/+4443
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rtw-next patches for v6.13 No big change at this point. Regular development and fixes are listed: rtl8xxxu: - correct beaconing for the case of STA + AP rtw88: - consolidate parser of RX descriptor as preparation to support coming chips rtw89: - update BT-coexistence to improve user experience for RTL8852BE and RTL8852BE-VT - correct RTL8922AE RF calibration timeout time and print out firmware log - set proper PCI EQ value for RTL8852CE and RTL8922AE - adjust to support MLO continuously
| * wifi: rtw89: wow: do not configure CPU IO to receive packets for old firmwareChin-Yen Lee2024-10-103-0/+9
| | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: coex: Add function to reorder Wi-Fi firmware report indexChing-Te Ku2024-10-102-13/+76
| | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: coex: Solved BT PAN profile idle decrease Wi-Fi throughputChing-Te Ku2024-10-101-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: coex: Reorder Bluetooth info related logicChing-Te Ku2024-10-102-33/+43
| | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: coex: Update priority setting for Wi-Fi is scanningChing-Te Ku2024-10-102-26/+33
| | | | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabledMartin Kaistra2024-10-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: debug: add beacon RSSI for debuggingPing-Ke Shih2024-10-054-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: handle entity active flag per PHYZong-Zhe Yang2024-10-014-13/+18
| | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: initialize dual HW bands for MLO and control them by linkZong-Zhe Yang2024-10-0112-72/+162
| | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: 8852ce: set offset K of PCI PHY EQ to manual mode to improve ↵Ping-Ke Shih2024-10-011-0/+24
| | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: 8852ce: fix gray code conversion for filter out EQPing-Ke Shih2024-10-011-10/+7
| | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: 8922ae: disable PCI PHY EQ to improve compatibilityPing-Ke Shih2024-10-013-1/+101
| | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: pci: consolidate PCI basic configurations for probe and resumePing-Ke Shih2024-10-013-9/+17
| | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw88: Parse the RX descriptor with a single functionBitterblue Smith2024-09-2611-271/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: 8852c: rfk: remove unnecessary assignment of return value of ↵Ping-Ke Shih2024-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | _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
| * wifi: rtw89: coex: initialize local .dbcc_2g_phy in _set_btg_ctrl()Ping-Ke Shih2024-09-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: check return value of ieee80211_probereq_get() for RNRPing-Ke Shih2024-09-261-0/+3
| | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: tweak driver architecture for impending MLO supportZong-Zhe Yang2024-09-2418-635/+1615
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: refactor STA related func ahead for MLOZong-Zhe Yang2024-09-2411-172/+261
| | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: refactor VIF related func ahead for MLOZong-Zhe Yang2024-09-248-81/+112
| | | | | | | | | | | | | | | | | | 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
| * wifi: rtw89: read link_sta corresponding to the linkZong-Zhe Yang2024-09-249-142/+362
| | | | | | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 19:47:22 +0100