summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw89/mac80211.c
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
2025-05-10wifi: rtw89: add MLO track for MLSR switch decisionPo-Hao Huang
Add MLSR switch mechanism based on tracking RSSI. Switch to a 2 GHz link (if any) when average RSSI is lower than threshold -53. And, switch out from a 2 GHz link when average RSSI is larger than threshold -38. The sequence of MLSR switch handling is like the following. 1. initialize target link and configure to PS mode 2. configure current designated link to PS mode 3. configure target link to non-PS mode 4. deinitialize currently active links except target link The above flow also implies that target link becomes new designated link. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250505072440.45113-7-pkshih@realtek.com
2025-05-05wifi: rtw89: introduce helper to get designated link for MLOZong-Zhe Yang
A link bound to HW band 0 was previously always assumed to exist, because it's true on non-MLD connection, and MLO connection is not supported yet. Now, start to consider MLO cases and prepare to enable MLO support in the following. Add skeleton of designated link. For single-link cases, helper returns the one. For multi-link cases, priorities can be scheduled. Then, drop assumption of link bound to HW band 0. One exception is that MCC doesn't work with MLD yet, so it still expects link on HW band 0 somewhere. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-11-pkshih@realtek.com
2025-04-28wifi: rtw89: don't re-randomize TSF of AP/GOZong-Zhe Yang
When APs or GOs are up, their TSF start point are randomized to avoid collisions. However, the TSF of an existing AP/GO would be randomized multiple times. It caused the TSF is discontinuous to the corresponding STA/GC sides. So, once TSF has been randomized, don't re-randomize it unless SER (system error recovery) happens unfortunately. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-7-pkshih@realtek.com
2025-04-28wifi: rtw89: refactor flow that hw scan handles channel listZong-Zhe Yang
FW has a limited amount of channels that can be dealt with by one HW scan H2C command. Based on the limit, channels in scan request might be parsed into SW structure piece by piece along with multiple HW scan H2C commands. But, in order to estimate things of entire HW scan process, it's required to have the whole parsed channel list when HW scan is going to start. So, tweak HW scan flow to prepare the whole channel list ahead. Still, each HW scan H2C command takes allowed amount of channels from the list according to the limit. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250422014620.18421-5-pkshih@realtek.com
2025-03-13wifi: rtw89: set force HE TB mode when connecting to 11ax APDian-Syuan Yang
Some of 11ax AP set the UL HE-SIG-A2 reserved subfield to all 0s, which will cause the 11be chip to recognize trigger frame as EHT. We propose a method to bypass the "UL HE-SIG-A2 reserved subfield" and always uses HE TB in response to the AP's trigger frame. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250306021144.12854-6-pkshih@realtek.com
2025-02-03wifi: rtw89: manual cosmetic along lockdep_assert_wiphy()Ping-Ke Shih
With spatch script, already remove most driver mutex and generate lockdep_assert_wiphy(), and some are needed to refine manually further to be expected: - lockdep_assert_wiphy() always be the first statement in function - return directly rather than unnecessary goto - change assert from mutex to wiphy lock, which script can't convert automatically. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-9-pkshih@realtek.com
2025-02-03wifi: rtw89: remove consumers of driver mutexPing-Ke Shih
All need lock have taken both driver mutex and wiphy lock, so we can remove driver mutex safely by below spatch script. Also, check every lockdep_assert_wiphy() is executed without locks warning at runtime. @ rule1_1 @ @@ - lockdep_assert_held(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); @ rule1_2 @ @@ - guard(mutex)(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); @ rule2_1 @ @@ - mutex_lock(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); ... - mutex_unlock(&rtwdev->mutex); @ rule2_2 @ @@ - mutex_unlock(&rtwdev->mutex); + lockdep_assert_wiphy(rtwdev->hw->wiphy); ... - mutex_lock(&rtwdev->mutex); @ rule3_1 @ type t; identifier fn; @@ t fn(struct wiphy *wiphy, ...) { ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(wiphy); ... } @ rule3_1_1 @ type t; identifier fn; @@ t fn(...) { ... struct wiphy *wiphy = ...; ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(wiphy); ... } @ rule3_2 @ type t; identifier fn; @@ t fn(struct ieee80211_hw *hw, ...) { ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(hw->wiphy); ... } @ rule3_2_1 @ type t; identifier fn; @@ t fn(...) { ... struct ieee80211_hw *hw = ...; ... - lockdep_assert_wiphy(rtwdev->hw->wiphy); + lockdep_assert_wiphy(hw->wiphy); ... } The compiler warnings will be fixed manually by latter patch: rtw89/mac80211.c:371:1: warning: statement expected after label Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-8-pkshih@realtek.com
2025-02-03wifi: rtw89: use wiphy_work() to replace ieee802111_work()Ping-Ke Shih
For certain works protected by driver mutex, use wiphy_work() directly to have wiphy lock held naturally. Then every this kind of works is protected by both wiphy lock and driver mutex. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250122060310.31976-3-pkshih@realtek.com
2025-01-12wifi: rtw89: fix race between cancel_hw_scan and hw_scan completionPing-Ke Shih
The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250107114254.6769-1-pkshih@realtek.com
2025-01-12wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failedChih-Kang Chang
If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered without removing the interface first. Then the mgnt_entry list init again, causing the list_empty() check in rtw89_chanctx_ops_assign_vif() useless, and list_add_tail() again. Therefore, we have added a check to prevent double adding of the list. rtw89_8852ce 0000:01:00.0: failed to check wow status disabled rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw rtw89_8852ce 0000:01:00.0: failed to disable wow rtw89_8852ce 0000:01:00.0: failed to resume for wow -110 rtw89_8852ce 0000:01:00.0: MAC has already powered on i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs list_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:34! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024 Workqueue: events_unbound async_run_entry_fn RIP: 0010:__list_add_valid_or_report+0x9f/0xb0 Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ... RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400 RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40 R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060 FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x68/0xb0 ? die+0xaa/0xd0 ? do_trap+0x9f/0x170 ? __list_add_valid_or_report+0x9f/0xb0 ? __list_add_valid_or_report+0x9f/0xb0 ? handle_invalid_op+0x69/0x90 ? __list_add_valid_or_report+0x9f/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x9f/0xb0 rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] ? __mutex_unlock_slowpath+0xa0/0xf0 rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] dpm_run_callback+0x37/0x1e0 device_resume+0x26d/0x4b0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 worker_thread+0x397/0x970 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103024500.14990-1-pkshih@realtek.com
2024-12-05wifi: rtw89: refine link handling for link_sta_rc_updateZong-Zhe Yang
The original handling will iterate all active links under the given sta and apply the changes to each. Now, stack tweaks ops from sta_rc_update to link_sta_rc_update, which means targeting a given link. Then, our link iteration looks redundant. So, refine it to apply the changes to the link directly. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-6-pkshih@realtek.com
2024-11-27wifi: rtw89: apply MLD pairwise key to dynamically active linksZong-Zhe Yang
In MLD connection, a pairwise key should work on all active links. And, we take just one entry in security CAM for one pairwise key. (It means we will reuse one single entry for all links.) Originally, we already applied the security CAM entry of pairwise key to deflink's address CAM. However, links can be activated dynamically. So now for pairwise keys, each rtw89_sta records the IDs of the security CAM entries. Then, when driver is notified that some links are active via change_sta_links(), we apply target pairwise keys to them according to the record. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241120034054.13575-5-pkshih@realtek.com
2024-11-27wifi: rtw89: implement ops of change vif/sta linksZong-Zhe Yang
To support MLO, implement change_vif_links() and change_sta_links() ops. Basically, we follow arguments to set/clear links. One special thing is that when vif is idle, i.e. no connection, link id 0 is set up by us for default uses. So, when bitmap of vif links change from 0x0 to non-zero, we clear the default one first. And when bitmap of vif links change from non-zero to 0x0, we set up a default one at the end. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241120034054.13575-4-pkshih@realtek.com
2024-11-27wifi: rtw89: register ops of can_activate_linksZong-Zhe Yang
Register mac80211 ops of can_activate_links which is required when we are ready to enable multiple active links. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241120034054.13575-3-pkshih@realtek.com
2024-11-27wifi: rtw89: 8922a: configure AP_LINK_PS if FW supportsZong-Zhe Yang
After FW v0.35.46.0, for AP mode, RTL8922A FW supports a new FW feature, called NOTIFY_AP_INFO, to notify driver information related to AP mode. And, one function of it is to monitor PS states of remote stations. Once one of them changes, FW will send a C2H event to tell driver. With this FW feature, we can declare AP_LINK_PS. For now, driver still needs to determine if a frame is ps-poll or U-APSD trigger. So, add the corresponding RX handling in driver, which activates only when at least one AP is running. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241120034054.13575-2-pkshih@realtek.com
2024-11-11Merge tag 'rtw-next-2024-11-06' of https://github.com/pkshih/rtwKalle Valo
rtw-next patches for v6.13 Major changes are listed: rtw88: - support two USB adapters 8821au and 8812au rtw89: - add thermal protection - fine tune BT-coexsitence to improve user experience - firmware secure boot for WiFi 6 chip - more materials for MLO
2024-10-29wifi: rtw89: chan: manage active interfacesZong-Zhe Yang
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
2024-10-25wifi: rtw89: unlock on error path in rtw89_ops_unassign_vif_chanctx()Dan Carpenter
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
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-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-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 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-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-02wifi: rtw89: pass rtwvif to RFK channelZong-Zhe Yang
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_channel prototype and pass rtwvif ahead. 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-5-pkshih@realtek.com
2024-08-02wifi: rtw89: rename sub_entity to chanctxZong-Zhe Yang
Originally, we planed to fill MAC_0/1 indicators with chanctx and use sub_entity_xxx for these things. However, there are some reasons listed below which make us give up this plan after we know our Wi-Fi 7 HW design. 1. one link is bound to one HW band during its life time but, one link might change chanctx dynamically 2. in concurrent mode, assume 1st vif is MLD 1st vif's 2nd link might use the same chanctx as 2nd vif but, they are not on the same HW band So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be more readable, we rename sub_entity related words to chanctx. 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/20240727080650.12195-4-pkshih@realtek.com
2024-08-02wifi: rtw89: fix typo of rtw89_phy_ra_updata_XXXZong-Zhe Yang
`updata` should be `update` Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-5-pkshih@realtek.com
2024-08-02wifi: rtw89: add support for hardware rfkillKuan-Chung Chen
Add support for ieee80211::rfkill_poll ops. This enables periodic monitoring of the hardware rfkill state, triggering updates when the status changes. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-3-pkshih@realtek.com
2024-07-09Merge tag 'rtw-next-2024-07-05' of https://github.com/pkshih/rtwKalle Valo
rtw-next patches for v6.11 Some cleanups of rtl8xxxu and rtlwifi, and some fixes of rtw88. The major change is to develop WoWLAN and preparation of RTL8852BE-VT listed below: rtw89: - preparation of RTL8852BE-VT * add RF calibration code * move shared code with RTL8852BE to common module - add WoWLAN for WiFi 6 chips - support 36-bit PCI DMA
2024-07-02wifi: rtw89: constrain TX power according to Transmit Power EnvelopeZong-Zhe Yang
Calculate a TX power constraint based on content of ieee80211 Transmit Power Envelope (TPE). Since HW control registers aren't designed as many as all kinds of TPE fields, we strictly intersect all TPE inputs in driver. Then, according to result, constrain TX power via TX power limit/limit_RU. Besides, extend dbgfs txpwr_table to show info about 6 GHz regulatory. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240626023237.7901-1-pkshih@realtek.com
2024-06-26wifi: mac80211: inform the low level if drv_stop() is a suspendEmmanuel Grumbach
This will allow the low level driver to take different actions for different flows. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618192529.739036208b6e.Ie18a2fe8e02bf2717549d39420b350cfdaf3d317@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-05-14wifi: rtw89: switch to register vif_cfg_changed and link_info_changedZong-Zhe Yang
For impending MLO support, we drop bss_info_changed callback ahead and switch to register new callbacks, vif_cfg_changed and link_info_changed, which are introduced by mac80211 for multi-link point of view. Besides, there is a place where we called ieee80211_find_sta() under station mode. To work on both non-MLD and MLD connection, we should call ieee80211_find_sta() with vif->cfg.ap_addr. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240509090646.35304-4-pkshih@realtek.com
2024-05-04wifi: rtw89: correct aSIFSTime for 6GHz bandPing-Ke Shih
aSIFSTime is 10us for 2GHz band and 16us for 5GHz and 6GHz bands. Originally, it doesn't consider 6GHz band and use wrong value, so correct it accordingly. Cc: stable@vger.kernel.org Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240430020515.8399-1-pkshih@realtek.com
2024-05-04wifi: rtw89: wow: add ARP offload featureChin-Yen Lee
Add H2C command and offload template packet to allow firmware send ARP response in WoWLAN mode. Then, firmware in WoWLAN mode can interactive with peer that issue ARP request to query MAC address. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240502022505.28966-13-pkshih@realtek.com
2024-05-04wifi: rtw89: wow: construct EAPoL packet for GTK rekey offloadChih-Kang Chang
We construct EAPoL packet with various encryption method, and download to firmware. Also we add Key Encryption Key (KEK) and Key Confirmation Key (KCK) to H2C command. Once firmware received EAPoL group rekey packet(1/2) can TX EAPoL group rekey packet(2/2) when suspend. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240502022505.28966-8-pkshih@realtek.com
2024-02-12wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by selfZong-Zhe Yang
Some of our calculation during concurrent mode depend on last beacon TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will be restricted once we declare MLO. Since we are about to consider the MLO stuffs, so sync beacon TSF by ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY. 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://msgid.link/20240206030624.23382-2-pkshih@realtek.com
2024-01-23wifi: rtw89: fix null pointer access when abort scanPo-Hao Huang
During cancel scan we might use vif that weren't scanning. Fix this by using the actual scanning vif. 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://msgid.link/20240119081501.25223-6-pkshih@realtek.com
2024-01-18wifi: rtw89: fw: update TX AMPDU parameter to CMAC tablePing-Ke Shih
The CMAC table is used to define how hardware TX a certain packet, and we can specify TX AMPDU size, so hardware can prepare proper retry window buffer. Otherwise, it can't transmit with expected aggregation number. Since each TID could have different aggregation number, the smallest number is adopted to prevent over peer's receiving buffer. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-5-pkshih@realtek.com
2024-01-18wifi: rtw89: fw: add chip_ops to update CMAC table to associated stationPing-Ke Shih
For WiFi 7 chips, we add H2C command with rich fields to support MLO, so add a chip_ops to generalize calling of update CMAC table. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115033742.16372-4-pkshih@realtek.com
2024-01-12wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operationPing-Ke Shih
Since coming WiFi 7 and existing chips use different update_beacon() format, add to abstract selection of H2C command. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091359.67636-1-pkshih@realtek.com
2024-01-12wifi: rtw89: add chip_ops::h2c_ba_cam() to configure BA CAMPing-Ke Shih
Since chips could use different version of BA CAM H2C command, add a chip_ops to abstract the operation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091134.67007-4-pkshih@realtek.com
2023-12-01wifi: rtw89: fix misbehavior of TX beacon in concurrent modeChih-Kang Chang
In concurrent mode, when STA interface is scanning, it causes AP interface TX beacon on wrong channel. We modified it to scan with the operating channel when one of the interfaces is already connected. Additionally, STA interface need to stop scan when AP interface is starting to avoid TX beacon on wrong channel. Finally, AP interface need to stop TX beacon when STA interface is scanning and switching to non-OP channel,This prevent other device to get beacons on wrong channel. 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-5-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-10-14wifi: rtw89: mac: add registers of MU-EDCA parameters for WiFi 7 chipsPing-Ke Shih
According to chip generation, set MU-EDCA parameters from mac80211 when connected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231012021455.19816-4-pkshih@realtek.com
2023-09-18wifi: rtw89: mcc: deal with beacon NoA if GO existsZong-Zhe Yang
In MCC STA+GO mode, we calculate NoA information and fill it into the beacon of P2P GO. Since NoA uses only 32 bits to describe time things, we need to deal with renewal when TSF[63:32] is carried. We trigger FW to notify that. Then, we can update NoA information for new time period once we get notification from FW. 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/20230908031145.20931-9-pkshih@realtek.com
2023-09-18wifi: rtw89: mcc: deal with P2P PS changeZong-Zhe Yang
MCC fills duration limit of a role according to NoA description. If P2P PS changes during MCC, we don't process P2P PS via normal flow. Instead, we re-fill duration limit of the role for new NoA description, and then we do MCC update. 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/20230908031145.20931-7-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-07-25 17:05:02 +0000