| Age | Commit message (Collapse) | Author |
|---|
|
8922A doesn't support broadcast/multicast traffic under MLO mode.
So let mac80211 do the encryption/decryption for us when the
connection is in MLO mode. Future BE ICs fixes this issue.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-3-pkshih@realtek.com
|
|
The RX DCK in firmware could retry 3 times if calibration value is not
stable. Roughly each calibration can be done within 16 ms, so expect
16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it
will do calibration on two path, so multiply 2.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250428112456.13165-2-pkshih@realtek.com
|
|
Set SAR configs to the corresponding CRs (control registers) according to
RF path. Then, declare to support SAR by antenna in chip info.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250326020643.14487-11-pkshih@realtek.com
|
|
Some SAR sources, e.g. ACPI, may allow different SAR configs by antenna.
Previously, the minimum config between antennas was taken. Because there
are differences between HW design, different chips might have different
solutions to achieve this. So, it cannot be done through a single common
handling. Now, add the relevant skeleton for this purpose ahead.
First, add a flag into chip info to describe whether it has implemented
this function or not. Second, support to query SAR config for a given RF
path. With it, each chip can implement its own handling. Then, if a chip
declares to support this function, when it queries SAR config without a
given RF path, it gets a maximum config between antennas.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250326020643.14487-10-pkshih@realtek.com
|
|
The 8922A now supports dynamic antenna gain. However, in firmware
before v0.35.64.0, different transmit powers cannot be applied to
each RF path. To comply with regulatory limits in these older
firmware, the lower of the two requested transmit powers will
be used for both paths when they differ.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250306021144.12854-5-pkshih@realtek.com
|
|
TAS state switching mechanism now incorporates the TX ratio as a
decision parameter. The average power calculation has been improved
by using a higher resolution conversion from dBm to linear. During
scan or MCC operations, TAS state is forced to static SAR and
suspend the average power calculation. Additionally, TAS window
size depends on the regulatory domain and band to ensure compliance.
TAS is enabled when permitted by the regulatory domain and is
currently supported on the 8852CE.
For debugging, add a flag to disable_dm that can stop TAS mechanism.
Co-developed-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250306021144.12854-3-pkshih@realtek.com
|
|
during scanning
For some packets, we could not get channel information from PPDU status.
And this causes wrong frequencies being reported. Parse the channel
information from IE if provided by AP to fix this.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250220064357.17962-1-pkshih@realtek.com
|
|
For 8852BTE, 8852CE, and 8922AE, TKIP encryption and decryption
will be handled by hardware. All other chips will retain their
existing software-based encryption and decryption.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250220062344.15836-1-pkshih@realtek.com
|
|
To ensure secure chip only runs expected secure firmware, stop using
obsolete firmware in blacklist which weakness or flaw was found.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217064308.43559-2-pkshih@realtek.com
|
|
BT-coexistence configure WiFi TX time to share time slots with Bluetooth
devices. Since the format is different from WiFi 6 chips, add the new
format accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250217063053.38936-3-pkshih@realtek.com
|
|
The registers of EDCCA log for PHY 1 isn't a simple offset, so define
them accordingly. Then the function use register set to access reports
according to phy_idx.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250117072828.16728-8-pkshih@realtek.com
|
|
RTL8922AE-VS is a variant of RTL8922AE, which is supported by firmware
version after 0.35.54.0 and only can support up to MCS11. Add a variant
struct to describe these requirements accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250108020955.14668-3-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
|
|
Extend the bitfield for duration in channel info to 16 bits.
Update the related format in H2C and C2H, then increase firmware
format sequence to 3.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241128055433.11851-2-pkshih@realtek.com
|
|
The dynamic antenna gain (DAG) may independently apply different TX
powers for each RF path. This can be accomplished by using the larger
TX power as the reference path and adjusting the TX power of the
other path based on the difference. Currently only 8852BE/8852BTE/
8852CE are supported.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241111065132.19587-4-pkshih@realtek.com
|
|
Dynamic Antenna Gain (DAG) adjusts the transmit power based on the
platform's antenna gain. This allows for higher transmit power when
the antenna gain is lower, while still complying with regulatory
limits. The driver reads the Realtek Antenna Gain (RTAG) data from
BIOS, and DAG is only enabled when the regulatory domain allows it.
Currently, it only supports 8852BE/8852BTE/8852CE.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241111065132.19587-3-pkshih@realtek.com
|
|
OP1dB stands for Output 1dB Compression Point. At this point, the power
amplifier starts to enter the saturation region, resulting in distortion.
The configuration of OP1dB can optimize the RX gain saturation region,
improving RX throughput from 573 to 675 Mbps.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030022903.13243-1-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
|
|
Extend FW and driver handling on RFK to support it on both HW bands.
Then, according to MLO cases, do the corresponding RF settings.
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-6-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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
TX EVM will significantly decrease for long packets when
the TX idle time increases. Introduce digital compensation
based on TX idle time, to mitigate TX EVM degradation, and
TX throughput improved from 1871 to 1947 Mbps.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240809072012.84152-3-pkshih@realtek.com
|
|
Add hardware encryption support for unicast management frames for
8922AE and 8852CE. Other chips will continue to use software
encryption for unicast management frames.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
|
|
Update scan offload H2C format to fit firmware version 35.21.
The new fields indicate lengths of variable length members, so
when driver and firmware are using mismatch version, FW could
handle the parsing better.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com
|
|
Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan
with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip
supports multiple channels.
So, change their prototype and pass chanctx_idx ahead. Let callers still
pass RTW89_CHANCTX_0 for now, but we will refine callers in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-8-pkshih@realtek.com
|
|
For chips supporting multiple channels, they need to get target info
from rtwvif, e.g. PHY index and Chanctx index.
So, change rfk_scan 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-6-pkshih@realtek.com
|
|
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
|
|
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
|
|
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
|
|
Need to update WoWLAN wakeup reason register after firmware version
0.35.22.0 for RTL8922A, and 0.27.80.0 for RTL8852CE.
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-3-pkshih@realtek.com
|
|
On 802.11be chips, to consider MLO, HW doesn't design number
of support mac_id as large as before. And, it might be various
according to chip. For example, old chips support mac_id up to
128, but RTL8922a only supports mac_id up to 32.
Besides, the mac_id acquiring function will be extended when
impending MLO support.
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-5-pkshih@realtek.com
|
|
When hal_reset on MAC_1/PHY_1, we should pass tx_en1 instead of tx_en0.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240417090058.42663-1-pkshih@realtek.com
|
|
rtw-next patches for v6.10
Some fixes and changes of capabilities detailed in following:
rtl8xxxu:
* enable MFP support
rtlwifi:
* some cleanups
rtw88:
* disable unsupported interface type of mesh point for all chips, and only
support station mode for SDIO chips.
rtw89:
* fixes of 8852b, 8852c and 8922a
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.10
The first "new features" pull request for v6.10 with changes both in
stack and in drivers. The big thing in this pull request is that
wireless subsystem is now almost free of sparse warnings. There's only
one warning left in ath11k which was introduced in v6.9-rc1 and will
be fixed via the wireless tree.
Realtek drivers continue to improve, now we have support for RTL8922AE
and RTL8723CS devices. ath11k also has long waited support for P2P.
This time we have a small conflict in iwlwifi, Stephen has an example
merge resolution which should help with fixing the conflict:
https://lore.kernel.org/all/20240326100945.765b8caf@canb.auug.org.au/
Major changes:
rtw89
* RTL8922AE Wi-Fi 7 PCI device support
rtw88
* RTL8723CS SDIO device support
iwlwifi
* don't support puncturing in 5 GHz
* support monitor mode on passive channels
* BZ-W device support
* P2P with HE/EHT support
ath11k
* P2P support for QCA6390, WCN6855 and QCA2066
* tag 'wireless-next-2024-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (122 commits)
wifi: mt76: mt7915: workaround dubious x | !y warning
wifi: mwl8k: Avoid -Wflex-array-member-not-at-end warnings
wifi: ti: Avoid a hundred -Wflex-array-member-not-at-end warnings
wifi: iwlwifi: mvm: fix check in iwl_mvm_sta_fw_id_mask
net: rfkill: gpio: Convert to platform remove callback returning void
wifi: mac80211: use kvcalloc() for codel vars
wifi: iwlwifi: reconfigure TLC during HW restart
wifi: iwlwifi: mvm: don't change BA sessions during restart
wifi: iwlwifi: mvm: select STA mask only for active links
wifi: iwlwifi: mvm: set wider BW OFDMA ignore correctly
wifi: iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD cmd v9
wifi: iwlwifi: mvm: Declare HE/EHT capabilities support for P2P interfaces
wifi: iwlwifi: mvm: Remove outdated comment
wifi: iwlwifi: add support for BZ_W
wifi: iwlwifi: Print a specific device name.
wifi: iwlwifi: remove wrong CRF_IDs
wifi: iwlwifi: remove devices that never came out
wifi: iwlwifi: mvm: mark EMLSR disabled in cleanup iterator
wifi: iwlwifi: mvm: fix active link counting during recovery
wifi: iwlwifi: mvm: assign link STA ID lookups during restart
...
====================
Link: https://lore.kernel.org/r/20240403093625.CF515C433C7@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
8922a FW supports RNR parsing, provide template probe requests and
let FW do the replacement for SSID/BSSID/short SSIDs.
Don't declare WIPHY_FLAG_SPLIT_SCAN_6GHZ so proper IEs such as
6 GHz capabilities can be passed down within the same scan request.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/20240328052656.18823-3-pkshih@realtek.com
|
|
Implement the chip operation function for 8922a, it related to TX power,
RX gain, antenna position, packet priority and so on. Also assign
coexistence priority table for hardware PTA using. Add settings to avoid
uncertainties propagation when Wi-Fi Rx due to RF gain mismatch.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240312013721.17452-6-pkshih@realtek.com
|
|
In order to control the hardware band and related protocol control,
add version 8 format and related logic to control the mechanism.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240312013721.17452-2-pkshih@realtek.com
|
|
WiFi 2x2 + BT combo cards can be two or three physical antenna. For two
antenna case, one antenna is shared by WiFi and BT, and different
configuration should be applied. Fix the typo.
This problem was found by Coccicheck, and actually that is a typo instead:
rtw8922a.c:2235:2-4: WARNING: possible condition with no effect (if == else)
Fixes: 652c9642eda6 ("wifi: rtw89: coex: add init_info H2C command format version 7")
Closes: https://lore.kernel.org/linux-wireless/20240308074539.04512f66@kernel.org/
Cc: Ching-Te Ku <ku920601@realtek.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240309001348.9906-1-pkshih@realtek.com
|
|
The WoWLAN reason register is used for driver to get the wakeup reason
for reporting to cfg80211, and it is different from chips. So put it
into chip information.
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-2-pkshih@realtek.com
|
|
To avoid using bit fields for H2C command, rearrange the structure.
And also patch the corresponding code for the using of this structure.
No logic changes for existing chips.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240229074514.219276-4-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
|
|
Reset hardware state to prevent hardware stays at abnormal state during
setting channel. Besides, add preparation for MLO/DBCC before setting
channel, and reconfigure registers after that.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240215055741.14148-5-pkshih@realtek.com
|
