summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2024-09-09Merge tag 'rtw-next-2024-09-05' of https://github.com/pkshih/rtwKalle Valo
rtw-next patches for v6.12 The rtw89 is continuously adjusting code to support MLO. The major changes are listed below: rtw88: * fix USB not transmitting beacon in AP mode rtw89: * complete BT-coexistence code for RTL8852BT * fix throughput degrade of VHT rate for RTL8851B/8852A/8852B/8852BT * enable WoWLAN net-detect for more one chip, RTL8922A
2024-09-05wifi: rtw89: avoid reading out of bounds when loading TX power FW elementsZong-Zhe Yang
Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240902015803.20420-1-pkshih@realtek.com
2024-09-05wifi: rtw89: use frequency domain RSSIEric Huang
To get more accurate RSSI, this commit includes frequency domain RSSI info in RSSI calculation. Add correspond physts parsing and macro to get frequency domain RSSI information for supported IC. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-3-pkshih@realtek.com
2024-09-05wifi: rtw89: adjust DIG threshold to reduce false alarmEric Huang
Use RSSI without subtracting offset as packet detection lower bound and set an absolute minimal threshold. It's equivalent to setting a higher noise floor, thereby reducing false alarm and improving interference endurance. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240828055217.10263-2-pkshih@realtek.com
2024-09-04Merge tag 'wireless-next-2024-09-04' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== pull-request: wireless-next-2024-09-04 here's a pull request to net-next tree, more info below. Please let me know if there are any problems. ==================== Conflicts: drivers/net/wireless/ath/ath12k/hw.c 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850") 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only") https://lore.kernel.org/87msldyj97.fsf@kernel.org Link: https://patch.msgid.link/20240904153205.64C11C4CEC2@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-09-02wifi: rtw89: wow: add scan interval option for net-detectChin-Yen Lee
The scan interval option is the period in unit of second for WoWLAN firmware to do each scan. We get the option from cfg80211 and practice it. If the interval is too short for firmware to finish one scan, the firmware will start next scan immediately after finishing one and the WiFi chip could never enter idle mode to reduce power consumption. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240826090439.17242-5-pkshih@realtek.com
2024-09-02wifi: rtw89: wow: add net-detect support for 8922aeChin-Yen Lee
Enable net-detect in WoWLAN stub of 8922a, and declare net-detect support up to 8 SSIDs. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240826090439.17242-4-pkshih@realtek.com
2024-09-02wifi: rtw89: wow: add wait for H2C of FW-IPS modeChin-Yen Lee
The C2H packet of FW-IPS mode is not handled by driver in the suspend flow, and lead to WoWLAN firmware fail to enter PS mode and even some SER happen. So add wait function for H2C of FW-IPS mode to check driver handle the C2H packet before disabling interrupt and make the net-detect function work fine. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240826090439.17242-3-pkshih@realtek.com
2024-09-02wifi: rtw89: wow: fix wait condition for AOAC report requestZong-Zhe Yang
Each condition binding to the same wait should be unique. AOAC code misused the wait of FW offload series and broke the above rule. It added another macro to generate wait condition of WoWLAN/AOAC, but the results conflict to the ones of FW offload series. It means that we might be completed wrongly in logic. We don't want things work/read like this and should have avoided this. Fix this by adding another wait which aims for WoWLAN functions. Fixes: ff53fce5c78b ("wifi: rtw89: wow: update latest PTK GTK info to mac80211 after resume") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240826090439.17242-2-pkshih@realtek.com
2024-09-02wifi: rtw88: assign mac_id for vif/sta and update to TX descPing-Ke Shih
A mac_id as an instance in firmware has to be assigned for each station including AP and connected stations. Firmware will use the mac_id to control TX rate and do statistics. Assignment rule is to assign mac_id to each vif when adding vif. For station mode, sta->mac_id will reuse vif->mac_id. For AP mode, dynamically allocate an sta->mac_id to a station, and vif->mac_id is used to send broadcast/multicast packets which are not belong to a station. For example, vif->mac_id sta->mac_id vif0 (STA mode) 0 0 vif1 (AP mode) 1 2... By the way, remove unused RTW_BC_MC_MACID, which was planed to send broadcast/multicast packets on fixed mac_id. Tested-on RTL8822CE with STA + AP SCC mode. Link: https://lore.kernel.org/linux-wireless/e4be0a75-43b2-4ae5-9aab-5c4a88e78097@gmail.com/ Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819025248.17939-1-pkshih@realtek.com
2024-09-02wifi: rtw88: Fix USB/SDIO devices not transmitting beaconsBitterblue Smith
All USB devices supported by rtw88 have the same problem: they don't transmit beacons in AP mode. (Some?) SDIO devices are also affected. The cause appears to be clearing BIT_EN_BCNQ_DL of REG_FWHW_TXQ_CTRL before uploading the beacon reserved page, so don't clear the bit for USB and SDIO devices. Tested with RTL8811CU and RTL8723DU. Cc: <stable@vger.kernel.org> # 6.6.x Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/49de73b5-698f-4865-ab63-100e28dfc4a1@gmail.com
2024-08-27wifi: rtw89: introduce chip support link number and driver MLO capabilityZong-Zhe Yang
Configure supported link number by chip. And, introduce driver capability flag for MLO. Driver should depend on runtime FW features and chip info to determine whether to set the MLO capability flag or not. Once the MLO flag is set, driver will consider/register/initialize things for MLO usages. However, we just add the driver MLO capability flag ahead and don't really set it. Then, we can start to tweak driver architecture for MLO. Some code should depend on this flag. And after tweaking driver architecture is done, we will set it based on runtime conditions as mentioned above. Besides, MLD number supported by HW should be chip supported mac_id number / chip supported link number Without driver MLO capability flag, we allocate stations based on supported mac_id number. With driver MLO capability flag, we allocate stations based on supported MLD number. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-9-pkshih@realtek.com
2024-08-27wifi: rtw89: rename roc_entity_idx to roc_chanctx_idxZong-Zhe Yang
The target enum has been renamed to rtw89_"chanctx"_idx. So for readability, rename roc_entity_idx to roc_"chanctx"_idx to align. 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/20240819091724.33730-8-pkshih@realtek.com
2024-08-27wifi: rtw89: 8922a: use right chanctx whenever possible in RFK flowZong-Zhe Yang
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible. Instead, obtain the right chanctx from somewhere and use it in RTL8922A RFK (RF calibration) related code. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-7-pkshih@realtek.com
2024-08-27wifi: rtw89: 8852c: use right chanctx whenever possible in RFK flowZong-Zhe Yang
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible. Instead, obtain the right chanctx from somewhere and use it in RTL8852C RFK (RF calibration) related code. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-6-pkshih@realtek.com
2024-08-27wifi: rtw89: 8852bx: use right chanctx whenever possible in RFK flowZong-Zhe Yang
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible. Instead, obtain the right chanctx from somewhere and use it in RTL8852BX RFK (RF calibration) related code. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-5-pkshih@realtek.com
2024-08-27wifi: rtw89: 8852a: use right chanctx whenever possible in RFK flowZong-Zhe Yang
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible. Instead, obtain the right chanctx from somewhere and use it in RTL8852A RFK (RF calibration) related code. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-4-pkshih@realtek.com
2024-08-27wifi: rtw89: 8851b: use right chanctx whenever possible in RFK flowZong-Zhe Yang
No longer access chan with hard-code RTW89_CHANCTX_X whenever possible. Instead, obtain the right chanctx from somewhere and use it in RTL8851B RFK (RF calibration) related code. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240819091724.33730-3-pkshih@realtek.com
2024-08-27wifi: rtw89: pass chan to rfk_band_changed()Zong-Zhe Yang
Originally, all chips have implemented rfk_band_changed() and access chan with hard-code RTW89_CHANCTX_0 in it. But, it's problematic when the chip supports multiple channels. So, change the prototype of rfk_band_changed() and pass chan ahead. And, we will refine the implementation of each chip 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/20240819091724.33730-2-pkshih@realtek.com
2024-08-22wifi: rtw89: coex: Add new Wi-Fi role format condition for function usingChing-Te Ku
There are many features need the information those record at Wi-Fi role structure. Implement the corresponding code for using. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240816124614.25592-5-pkshih@realtek.com
2024-08-22wifi: rtw89: coex: Bluetooth hopping map for Wi-Fi role version 7Ching-Te Ku
To get Wi-Fi channel & bandwidth information from new Wi-Fi role format. Bluetooth will negotiate which channel to do TX/RX with connected device. And Bluetooth will maintain a hopping map, that describe the usable channels. To avoid the interference from Wi-Fi 2.4GHz/Bluetooth each other, Bluetooth must not to hop into Wi-Fi channel. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240816124614.25592-4-pkshih@realtek.com
2024-08-22wifi: rtw89: coex: Update Wi-Fi role info version 7Ching-Te Ku
This version included new introduced Wi-Fi DBCC information related to WiFi role. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240816124614.25592-3-pkshih@realtek.com
2024-08-22wifi: rtw89: coex: Update report version of Wi-Fi firmware 0.29.90.0 for ↵Ching-Te Ku
RTL8852BT Add the firmware related version code for RTL8852BT version 0.29.90.0. And add the version 7 report control structure format. Firmware will collect counters like mailbox count, RF on/off count, and some Bluetooth related counters into this structure and pass to driver periodically. It will help to understand how the firmware mechanism working. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240816124614.25592-2-pkshih@realtek.com
2024-08-22wifi: rtw89: limit the PPDU length for VHT rate to 0x40000Chia-Yuan Li
If the PPDU length for VHT rate exceeds 0x40000, calculating the PSDU length will overflow. TMAC will determine the length to be too small and as a result, all packets will be sent as ZLD (Zero Length Delimiter). Fixes: 5f7e92c59b8e ("wifi: rtw89: 8852b: set AMSDU limit to 5000") Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240815134054.44649-1-pkshih@realtek.com
2024-08-22wifi: rtw89: debugfs: support multiple adapters debuggingPing-Ke Shih
The rtw89 uses debugfs to access registers and driver states. To get a range of registers, the range value is set and stored to a variable, and get the set of register values by the stored range. However, the variable is a static global variable, which multiple adapters will be a problem, so move the variable to adapter context rtw89_dev. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240816115700.17390-1-pkshih@realtek.com
2024-08-16wifi: rtw88: remove CPT execution branch never usedDmitry Kandybka
In 'rtw_coex_action_bt_a2dp_pan', 'wl_cpt_test' and 'bt_cpt_test' are hardcoded to false, so corresponding 'table_case' and 'tdma_case' assignments are never met. Also 'rtw_coex_set_rf_para(rtwdev, chip->wl_rf_para_rx[1])' is never executed. Assuming that CPT was never fully implemented, remove lookalike leftovers. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 76f631cb401f ("rtw88: coex: update the mechanism for A2DP + PAN") Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809085310.10512-1-d.kandybka@gmail.com
2024-08-16wifi: rtw89: 8852a: adjust ANA clock to 12MChin-Yen Lee
To reduce the I/O time from power save mode for 8852a, adjust ANA clock from 500k to 12M. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-6-pkshih@realtek.com
2024-08-16wifi: rtw89: correct base HT rate mask for firmwarePing-Ke Shih
Coverity reported that u8 rx_mask << 24 will become signed 32 bits, which casting to unsigned 64 bits will do sign extension. For example, putting 0x80000000 (signed 32 bits) to a u64 variable will become 0xFFFFFFFF_80000000. The real case we meet is: rx_mask[0...3] = ff ff 00 00 ra_mask = 0xffffffff_ff0ff000 After this fix: rx_mask[0...3] = ff ff 00 00 ra_mask = 0x00000000_ff0ff000 Fortunately driver does bitwise-AND with incorrect ra_mask and supported rates (1ss and 2ss rate only) afterward, so the final rate mask of original code is still correct. Addresses-Coverity-ID: 1504762 ("Unintended sign extension") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-5-pkshih@realtek.com
2024-08-16wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to ↵Ping-Ke Shih
prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 ("Out-of-bounds read") Fixes: ff53fce5c78b ("wifi: rtw89: wow: update latest PTK GTK info to mac80211 after resume") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-4-pkshih@realtek.com
2024-08-16wifi: rtw89: 8922a: add digital compensation to avoid TX EVM degradeKuan-Chung Chen
TX EVM will significantly decrease for long packets when the TX idle time increases. Introduce digital compensation based on TX idle time, to mitigate TX EVM degradation, and TX throughput improved from 1871 to 1947 Mbps. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-3-pkshih@realtek.com
2024-08-16wifi: rtw89: 8852c: support firmware with fw_elementKuan-Chung Chen
Firmware from v1 will include fw_element so that the driver will loading parameters of BB and RF, TX power related tables from firmware. For the current flow, if fw_element is present, the driver will prioritize loading parameters and tables from firmware; otherwise, it will revert to the original loading method. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240809072012.84152-2-pkshih@realtek.com
2024-08-09wifi: rtw88: Enable USB RX aggregation for 8822c/8822b/8821cBitterblue Smith
Enable USB RX aggregation when there is at least 1 Mbps RX or TX traffic, otherwise disable it. USB RX aggregation improves the RX speed of RTL8811CU on certain ARM systems, like the NanoPi NEO Core2. Before: 28 Mbps, after: 231 Mbps. It also improves the RX speed of RTL8822CU on some x86_64 systems. Before: ~200 Mbps, after: ~300 Mbps. The official drivers for these chips use the same logic for SDIO, but for some reason the SDIO driver in rtw88 always enables RX aggregation, so this patch only toggles aggregation for USB devices. RTL8703B is likely not found in USB devices, and RTL8723DU doesn't like aggregation. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com
2024-08-09wifi: rtw88: usb: Support RX aggregationBitterblue Smith
The chips can be configured to aggregate several frames into a single USB transfer. Modify rtw_usb_rx_handler() to support this case. RX aggregation improves the RX speed of RTL8811CU on certain ARM systems, like the NanoPi NEO Core2. It also improves the RX speed of RTL8822CU on some x86_64 systems. Currently none of the chips are configured to aggregate frames. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/f845826d-de71-492d-9a22-e48c07989a1f@gmail.com
2024-08-09wifi: rtw88: usb: Update the RX stats after every frameBitterblue Smith
Update the number of received unicast data frames and bytes every time a frame is received. This is what the PCI and SDIO drivers do. This has an influence on the power saving, bluetooth coexistence, and (in a future patch) the use of RX aggregation. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/75a2ca52-8f01-45c5-926f-d3a68ae3b284@gmail.com
2024-08-09wifi: rtw88: usb: Init RX burst length according to USB speedBitterblue Smith
This is needed in order to make USB RX aggregation work with RTL8811CU (and presumably RTL8822BU and RTL8822CU also). I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN are doing. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. The RX speed is unchanged in my tests. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
2024-08-09wifi: rtl8xxxu: add missing rtl8192cu USB IDsPeter Robinson
The rtl8xxxu has all the rtl8192cu USB IDs except for the following 3 so add them to the untested section so they can be used with the rtl8xxxu as the rtl8192cu are well supported. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240806082233.3837436-1-pbrobinson@gmail.com
2024-08-09wifi: rtl8xxxu: drop reference to staging driversPeter Robinson
The Kconfig notes mention staging drivers that have since been removed so update the driver's description so it no longer references the staging rtl8723au and rtl8192u drivers which have now been deleted. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805221910.3765214-1-pbrobinson@gmail.com
2024-08-09wifi: rtw89: wow: add net-detect support for 8852cChin-Yen Lee
Enable net-detect in WoWLan stub of 8852c, and declare net-detect support up to 8 SSIDs. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-6-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: add delay option for net-detectChin-Yen Lee
The delay option is the period in unit of second for WoWLAN firmware to wait before the first scan. We get the option from cfg80211 and practice it. Another, in some platform, WoWLAN firmware may found configured network and then trigger resume process, before suspend process is completed, lead to the wakeup function failed. So the default value is set one to avoid the issue. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-5-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: add WoWLAN net-detect supportChin-Yen Lee
Net-detect is an option of WoWLAN to allow the device to be woken up from suspend mode when configured network is detected. When user enables net-detect and lets the device enter suspend state, WoWLAN firmware will periodically scan until beacon or probe response of configured networks are received. If configured networks are detected, WoWLAN firmware will trigger resume process. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-4-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: implement PS mode for net-detectChin-Yen Lee
When net-detect is enabled, WoWLAN firmware will periodically scan until beacon or probe response of configured networks are received. To reduce power consumption, the FW-IPS mode is implemented to keep WiFi chip in idle mode between each scan. The FW-IPS is controlled by WoWLAN firmware to turn of some critical electrical components, and is different from the original IPS mode which most electrical components are turned off. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-3-pkshih@realtek.com
2024-08-09wifi: rtw89: 8852c: support firmware format up to v1Ping-Ke Shih
Driver has supported different WoWLAN reason code by commit 0e5210217768 ("wifi: rtw89: wow: update WoWLAN reason register for different FW") since firmware version 0.27.80.0. The old driver can't support two kinds of WoWLAN reason, so increase firmware format to v1. Also driver tables of BB and RF registers and power values will be added into v1 format. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-2-pkshih@realtek.com
2024-08-07wifi: rtlwifi: rtl8192du: Initialise value32 in ↵Bitterblue Smith
_rtl92du_init_queue_reserved_page GCC complains: In file included from include/linux/ieee80211.h:21, from include/net/mac80211.h:20, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/../wifi.h:14, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:4: In function 'u32p_replace_bits', inlined from '_rtl92du_init_queue_reserved_page.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:225:2: >> include/linux/bitfield.h:189:18: warning: 'value32' is used uninitialized [-Wuninitialized] Part of the variable is indeed left uninitialised. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408062100.DWhN0CYH-lkp@intel.com/ Fixes: e769c67105d3 ("wifi: rtlwifi: Add rtl8192du/hw.{c,h}") 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/2a808244-93d0-492c-b304-ae1974df5df9@gmail.com
2024-08-07wifi: rtw89: correct VHT TX rate on 20MHz connectionDian-Syuan Yang
It may get wrong bitrate when connecting to AP set VHT 20MHz, and thus we fix it to follow Wi-Fi spec. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-6-pkshih@realtek.com
2024-08-07wifi: rtw89: add support for HW encryption in unicast management framesKuan-Chung Chen
Add hardware encryption support for unicast management frames for 8922AE and 8852CE. Other chips will continue to use software encryption for unicast management frames. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
2024-08-07wifi: rtw89: avoid to add interface to list twice when SERChih-Kang Chang
If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]--- Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-4-pkshih@realtek.com
2024-08-07wifi: rtw89: 8922a: Add new fields for scan offload H2C commandPo-Hao Huang
Update scan offload H2C format to fit firmware version 35.21. The new fields indicate lengths of variable length members, so when driver and firmware are using mismatch version, FW could handle the parsing better. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com
2024-08-07wifi: rtw89: 8922a: new implementation for RFK pre-notify H2CKuan-Chung Chen
For firmware version 0.35.31 and above, update H2C RFK pre-notify to new implementation. Rename existing H2C to v0 for backward compatibility. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com
2024-08-02wifi: rtw89: pass chanctx_idx to rtw89_btc_{path_}phymap()Zong-Zhe Yang
Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip supports multiple channels. So, change their prototype and pass chanctx_idx ahead. Let callers still pass RTW89_CHANCTX_0 for now, but we will refine callers 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/20240727080650.12195-8-pkshih@realtek.com
2024-08-02wifi: rtw89: fw: correct chan access in assoc_cmac_tbl_g7 and update_beacon_beZong-Zhe Yang
Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0. They are problematic when the chip supports multiple channels. So, correct them by accessing right chan under rtwvif. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com
generated by cgit v1.2.3-70-g09d2 (git 2.47.1) at 2024-12-28 16:09:35 +0000