The queued and obsoleted scan events can be wrongly treated as events of
new scan request, causing unexpected scan result. Attach a software
sequence number to scan request and its corresponding events. When a new
scan request is acknowledged by firmware, purge the scan events if its
sequence number is not belong to current request.
Normal case:
mac80211 event work event BH
------------- ---------- --------
scan req #1 ---->o
|
<----o <...........................o
o
|
<--------------------------+
ieee80211_scan_completed()
Abnormal case (late event work):
mac80211 event work event BH
------------- ---------- --------
scan req #1 ---->o
|
<----o <...........................o
o #1
scan cancel #2 ->o
|
<----o <...........................o
o #2
| (patch to avoid this)
scan req #3 ---->o |
| |
<----o <..........|................o
| o #3
<--------------------------+
ieee80211_scan_completed()
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-5-pkshih@realtek.com
Add rtw8851b_dle_mem_usb2 and rtw8851b_dle_mem_usb3 and their various
quotas and sizes in struct rtw89_mac_size_set.
"dle" could be "Data Link Engine" or "Double Link Engine". These are
some parameters needed for RTL8851BU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/91622304-614e-4e91-bf2f-7688cf44070b@gmail.com
When debugging or recovering system error recovery (SER), it's
necessary to dump internal memory to perform status inspection.
Since the memory page size differs between WiFi 6 and 7 chips,
define them accordingly.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250618124649.11436-2-pkshih@realtek.com
The newer firmware add new C2H event class 27, which is to report WiFi
role status. Since rtw89 doesn't use the status yet, add a dummy handler
to avoid warning:
rtw89_8922ae 0000:03:00.0: MAC c2h class 27 func 0 not support
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020302.16873-5-pkshih@realtek.com
The mlo_link_cfg H2C command is used to tell FW to enter/leave PS mode
on a given link. And, need to wait for status of C2H event to ensure if
FW deals with it successfully.
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-6-pkshih@realtek.com
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
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
The agg_limit and txcnt_limit are used by BT-coexistence to reduce
WiFi TX time at once to share time with Bluetooth devices. Since
these registers address are different from WiFi 6 and 7 chips, define
them accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217063053.38936-2-pkshih@realtek.com
Driver selects firmware by hardware version, which normally can be read
from registers before selecting firmware. However, certain chips such as
RTL8851B, it needs to read hardware version from efuse while doing
power_on, but do power_on after selecting firmware in current flow.
To resolve this flow problem, move power_on out from
rtw89_mac_partial_init(), and call rtw89_mac_pwr_on() separately at
proper places to have expected flow.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250203072911.47313-2-pkshih@realtek.com
The PPDU status of probe response will fail to parse the IE due to being
filtered by the to_self check. Therefore, we parse RSSI from PHY report in
RX descriptor.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241128055433.11851-5-pkshih@realtek.com
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
For WiFi 6 chips, firmware secure boot will run on a IDMEM mode specified
in firmware header. Retrieve the mode from firmware, and set to registers
accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030022135.11688-6-pkshih@realtek.com
The secure key used by certain hardware module is programmed in efuse, so
driver should read the information from efuse before downloading firmware.
Originally only RTL8922AE can support firmware secure boot, and read efuse
during chip power on. To extend to support all chips, move the caller to
common power on flow and add separate functions to read efuse for
WiFi 6 chips.
No logic change at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030022135.11688-2-pkshih@realtek.com
To prevent chip overheating, reduce TX duty as the mechanism of thermal
protection. When temperature is raising over a threshold, send a firmware
command to reduce TX duty. If temperature is still raising, higher level
is adopted to have lower active duration.
The equation and unit of thermal values are different from chip to chip,
so define constant thresholds of thermal value to corresponding absolute
temperature of 110 and 120 degree Celsius.
Latter patch will decide which thermal threshold is adopted, and current
is still not enable thermal protection.
For debugging, add a flag to disable_dm that thermal protection can be
disabled to clarify low throughput in field.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-2-pkshih@realtek.com
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
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
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
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
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
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
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: ff53fce5c7 ("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
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
Add chip_info of RTL8852BT accordingly, including firmware elements
support, MAC memory quota (WDE, PLE and etc), SER IMR used by firmware,
BTC registers, register based H2C/C2H, WoWLAN stub.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-4-pkshih@realtek.com
MRC (multi-role concurrency) has a C2H event for status report. Newer
FW will report some kinds of failures. We parse them now and show by
debug log.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240702124452.18747-1-pkshih@realtek.com
The 802.11ax chip also needs rtw89_mac_cpu_io_rx(), which notifies Firmware
to start or stop WoWLAN and waits until Firmware process over. Then,
the driver can continue processing to avoid unexpected behavior.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240620055825.17592-4-pkshih@realtek.com
When resume we parse AOAC report from firmware using H2C and C2H
registers before enable interrupt, then update PTK RX PN and GTK RX PN.
After enable interrupt, we parse AOAC report using H2C and C2H commands,
then update PTK TX PN and update new GTK key info if GTK rekey during
suspend. Furthermore, We update pattern match index if wakeup by pattern.
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-10-pkshih@realtek.com
The registers to configure mac function for WoWLAN mode that are different
from different generation, so update them.
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://msgid.link/20240302005828.13666-5-pkshih@realtek.com
The statue register is for driver to check if WoWLAN mode works or stops
successfully. It is changed for new generation, so update it.
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://msgid.link/20240302005828.13666-3-pkshih@realtek.com
Under some circumstances, coexistence mechanism want to keep grant BT or
WiFi, such as inquiry and WiFi is connecting, to ensure BT or WiFi can
transmit or receive data in that period.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240229074514.219276-3-pkshih@realtek.com
When hardware grant BT initially but transition to grant WiFi, the PLT
(polluted) bit is set to assist coexistence mechanism to debug if
grant signal is expected.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240229074514.219276-2-pkshih@realtek.com
Add handling of MRC (multiple role concurrent) C2H events including
TSF report and status report. Parse report data and then complete the
corresponding H2C commands, which will be implemented in the following.
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/20240213073514.23796-3-pkshih@realtek.com
For Wi-Fi 7 chips, FW supports MRC (multi-role concurrent) functions
including H2C commands and C2H events. We can consider FW MRC functions
as a superset of FW MCC (multi-channel concurrent) functions. And, MRC
functions can take MLO things into account.
Basically before MLO, SW can also manipulate FW MRC to work original
SW MCC flow. So, we add them first and implement the handling in the
following. And then, SW MCC will call different series of FW functions
according to chip later.
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/20240213073514.23796-2-pkshih@realtek.com
When there are OBSS that cannot interpret 26-tone RU transmissions,
we should disable 26-tone RU HE TB PPDU transmissions. So, add registers
accordingly.
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/20240209065229.34515-8-pkshih@realtek.com
DLE (data link engine) could hold quota when we are going to enable/disable
MAC-1 block, so trigger hardware to return all held quota.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240209065229.34515-4-pkshih@realtek.com
Add a chip_ops for WiFi 7 chips to set additional RF configurations
including MLO and PLL settings.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-12-pkshih@realtek.com
The ps_state register is used for driver to check if the WiFi chip leave
power save mode successfully. The register is changed for new generation,
so update it.
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://msgid.link/20240126063356.17857-7-pkshih@realtek.com
This adds support for hardware scan after FW version 0.34.35. Currently
we only support scanning on single hardware band and support of dual band
scan will be added in the future. Adjust the current flow to make driver
compatible with different generation ICs.
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/20240126063356.17857-5-pkshih@realtek.com
The channel field slightly differs between WiFi 6 and WiFi 7.
So we prepare some required functions in advance, this doesn't change
existing wifi 6 ICs behavior. This H2C prepares the channel list
to be scanned for. With layout as the following:
+--------+--------------------+-------------------+-----------------------+
| header | number of channels | channel info size | channel_info * number |
+--------+--------------------+-------------------+-----------------------+
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/20240126063356.17857-4-pkshih@realtek.com
To set TX/RX path or set channel, we need these helpers to stop TX and
restore settings. The sch_tx stands for scheduler TX channel, and the
cfg_ppdu is to stop reporting PPDU status, so we should stop them during
setting.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240124033637.12330-3-pkshih@realtek.com
When STA connects to an AP and doesn't receive any beacon yet, the
hardware scan is triggered. This scan begins with the default TSF
value. Once STA receives a beacon when switches back to the operating
channel, its TSF synchronizes with the AP. However, if there is a
significant difference in TSF values between the default value and
the synchronized value, it will cause firmware fail to trigger
interrupt, and the C2H won't be sent out. As a result, the scan
continues until a timeout occurs. To fix this issue, we disable TSF
synchronization during scanning to prevent drastic TSF changes, and
enable TSF synchronization after scan.
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://msgid.link/20240119081501.25223-8-pkshih@realtek.com
When aborting scan, wait until FW is done to keep both states aligned.
This prevents driver modifying channel then gets overwritten by FW.
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-7-pkshih@realtek.com
The new WiFi 7 chips change the design, so no need to disable/enable
BB/RF when core_start(). Keep the same logic for existing chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231211083341.118047-7-pkshih@realtek.com
Many existing MAC access functions are used by WiFi 6 chips only, so add
suffix _ax to be clearer. Some are common and can be used by WiFi 7, so
export this kind of functions. This patch doesn't change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231211083341.118047-5-pkshih@realtek.com
Before accessing CMAC and DMAC registers, we should ensure they have been
powered on, so add flag to determine the state. For old chips, we read
registers and check corresponding bit, but it takes extra cost to read.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231211083341.118047-4-pkshih@realtek.com
The power on/off functions are to turn on hardware function blocks and
to turn off them if we are going to stay in idle state.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231211083341.118047-3-pkshih@realtek.com
The XTAL SI is a serial interface to indirectly access registers of
analog hardware circuit. Since WiFi 7 chips use different registers, add
a ops to access them via common functions. This patch doesn't change logic
for existing chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231211083341.118047-2-pkshih@realtek.com
To diagnose the reason why firmware or hardware get abnormal, add to dump
MAC registers related to counters and interrupt masks. With these values,
people can classify problems and check if registers values are unexpected,
and then correct them. However, it could possible false alarm because
firmware triggers this SER event by wrong conditions that we should
correct it at firmware or register settings.
In field, SER might happen under special conditions, and very hard to
happen again, so dump lots of registers to provide rich information to
catch the problem.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
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/20231204080751.15354-5-pkshih@realtek.com
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
To share flow with WiFi 7 chips, abstract functions related hardware
engines and their quota, so use pointer to access them. This doesn't change
logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-8-pkshih@realtek.com
