summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/ps.h
AgeCommit message (Collapse)Author
2025-05-16wifi: rtw89: mcc: deal with non-periodic NoAZong-Zhe Yang
Originally, MCC just took periodic NoA into account. When the connected GO announces non-periodic NoA and GC side is during MCC, sometimes GC cannot receive beacons well if the MCC scheduling conflicts with the non-periodic NoA planning. After the loss exceeds the tolerable amount, beacon filter will report connection loss. However, in this case, the loss is acceptable. So now, MCC will calculate the range of non-periodic NoA. And then, don't care beacon loss during the range. Besides, rtw89_mcc_fill_role_limit() only makes sense for GC. Remove the redundant check of GO. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-6-pkshih@realtek.com
2024-12-12wifi: rtw89: ps: refactor PS flow to support MLOPing-Ke Shih
Firmware can only support PS on single one VIF operating in station mode, so argument of PS entry rtw89_enter_lps() should be rtwvif insetad of rtwvif_link. To enter PS under MLO, for each rtwvif, driver sends H2C command to tell firmware which mac_id will enter PS one by one, and afterward asks firmware to enter deep PS. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-2-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_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
2023-12-01wifi: rtw89: refine remain on channel flow to improve P2P connectionChih-Kang Chang
We add a scanning check to avoid entering IPS after ROC (remain on channel) during scanning. Additionally, When P2P scanning, the flow is `1. p2p_listen step` and `2. configure filter` and `3. p2p_scan starts` in wpas, but in kernel, cfg80211 uses another workqueue to notify driver the filter change, so sometimes we see (1 > 3 > 2), that will cause Rx filter related to scan to be cleared. Therefore, we add a scanning check when configure filter to avoid scan results to be filtered. Finally, we cancel the ROC delayed workqueue before entering ROC to avoid entering twice, which might cause leaving ROC too early. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231129070046.18443-4-pkshih@realtek.com
2023-08-25wifi: rtw89: provide functions to configure NoA for beacon updateZong-Zhe Yang
Callers call renew function when wanting to generate a new P2P NoA information element, and call append function to append NoA attribute one by one. Then, updating beacon work will fetch the P2P NoA information element configured by callers and add it to beacon. The use case of MCC (multi-channel concurrent) <GO + STA> for example: * start MCC - GO part renew P2P NoA append period NoA after calculation * download beacon for GO fetch P2P NoA and add to beacon content * stop MCC - GO part renew P2P NoA (reset) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230816082133.57474-6-pkshih@realtek.com
2023-06-01wifi: rtw89: correct PS calculation for SUPPORTS_DYNAMIC_PSPing-Ke Shih
This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or turn on dynamic PS controlled by driver and firmware. Though this would be incorrect, it did work before because the flag is always recalculated until the commit 28977e790b5d ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS") is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS. Correct this by doing recalculation while BSS_CHANGED_PS is changed and interface is added or removed. For now, it is allowed to enter PS only if single one station vif is working, and it could possible to have PS per vif after firmware can support it. Without this fix, driver doesn't enter PS anymore that causes higher power consumption. Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Cc: stable@vger.kernel.org # 6.1+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527082939.11206-3-pkshih@realtek.com
2023-04-17wifi: rtw89: fix power save function in WoWLAN modeChih-Kang Chang
In WoWLAN Mode, it's expected that WiFi chip could enter power save mode only after all setting is finished, but current wow_enter_lps function break the rule and may lead to WoWLAN function fail in low probability, so fix it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230410053438.10682-2-pkshih@realtek.com
2023-04-14wifi: rtw89: add ieee80211::remain_on_channel opsPo-Hao Huang
Add support of remain on channel ops. Since channel context is required to enable multi-channel concurrent(MCC) and the current ROC in mac80211 don't support more than 1 channel context, add this to let P2P and other protocols relying on this work as expected. The off-channel duration and cancel timing is purely controlled by upper layers. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230411124832.14965-4-pkshih@realtek.com
2022-11-01wifi: rtw89: add WoWLAN function supportChin-Yen Lee
WoWLAN is a feature which allows devices to be woken up from suspend state through WLAN events. When user enables WoWLAN feature and then let the device enter suspend state, WoWLAN firmware will be loaded by the driver and periodically monitors WiFi packets. Power consumption of WiFi chip will be reduced in this state. We now implement WoWLAN function in rtw8852ae and rtw8852ce chip. Currently supported WLAN events include receiving magic packet, rekey packet and deauth packet, and disconnecting from AP. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-7-pkshih@realtek.com
2022-09-24wifi: rtw89: support for processing P2P power savingDian-Syuan Yang
Support P2P client to process Notice of Absence (NoA) mechanism when it connects with P2P GO applying an NoA schedule. We define some action types including init, update, remove and terminate in h2c function to enable/disable NoA schedule. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922010435.12167-6-pkshih@realtek.com
2022-09-24wifi: rtw89: set wifi_role of P2PPing-Ke Shih
Consider vif->p2p to set wifi_role to let firmware know current vif is running as GC or GO. And, allow GC to enter PS mode, but disallow to enter deep PS for now. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220922010435.12167-4-pkshih@realtek.com
2021-10-13rtw89: add Realtek 802.11ax driverPing-Ke Shih
This driver named rtw89, which is the next generation of rtw88, supports Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC, Spatial reuse, TWT and BSS coloring; now some of them aren't implemented though. The chip architecture is entirely different from the chips supported by rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges are totally redefined, so it's impossible to reuse register definition. To communicate with firmware, new H2C/C2H format is proposed. In order to have better utilization, TX DMA flow is changed to two stages DMA. To provide rich RX status information, additional RX PPDU packets are added. Since there are so many differences mentioned above, we decide to propose a new driver. It has many authors, they are listed in alphabetic order: Chin-Yen Lee <timlee@realtek.com> Ping-Ke Shih <pkshih@realtek.com> Po Hao Huang <phhuang@realtek.com> Tzu-En Huang <tehuang@realtek.com> Vincent Fann <vincent_fann@realtek.com> Yan-Hsuan Chuang <tony0620emma@gmail.com> Zong-Zhe Yang <kevin_yang@realtek.com> Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com