summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89
AgeCommit message (Collapse)Author
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-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: 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: 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: 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-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-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-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: 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
generated by cgit (git 2.34.1) at 2025-05-08 20:16:56 +0000