| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
When the 'Disabled Subchannel Bitmap' within the EHT Operation
element is changed, mac80211 parse and pass it to the driver.
The driver is then updated with this puncturing bitmap to
optimize bandwidth usage and prevent interference from
degrading performance across the entire channel.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715035259.45061-4-pkshih@realtek.com
|
|
8852BT after FW 0.29.127, 8852B after FW 0.29.128 and 8922A after FW
0.35.79, the SER L2 flow determines different L2 types by parameter,
the zero value will trigger FW SER L2 assert.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-10-pkshih@realtek.com
|
|
Some FW features may have variants on how to deal with in leaf functions,
e.g. H2C commands. However, from SW component point of view, it might not
matter which variant is supported exactly. In some cases, SW component may
just care whether any of the variants is supported or not.
So, introduce a concept of FW feature group which can manage a set of FW
features and can easily be checked if at least one of them is supported.
Since CRASH_TRIGGER will have variants and then matches the case mentioned
above, so redefine CRASH_TRIGGER as a FW feature group and add a variant
of type 0 for original handling.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-9-pkshih@realtek.com
|
|
8852B after FW 0.29.127, 8852BT after FW 0.29.127 and 8922A after FW
0.35.76 driver check LPS H2C command received by FW using C2H reg instead
of done ack.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-8-pkshih@realtek.com
|
|
For some implementation acting as GO under MCC(GO+STA), the GO's TBTT
might change after STA roams to another AP. This could result the new GO
beacon TX at the STA timeslot of GC+STA, causing GC beacon loss.
Therefore, if the GC detects beacon loss, it will pause MCC and remain
on the GO side for 100 TU to detect the new TBTT beacon.
Additionally, some implementation acting as GO under MCC might TX beacon
too close to the NoA period. The GC calculates timeslot pattern the TOB
(time offset behind) or TOA(time offset ahead) less than the minimum
RX beacon time, which leads to beacon loss. Therefore, disable the
beacon filter in this case. Then, if the GO's TBTT changed, the pattern
TOB/TOA greater than the minimum RX beacon time, the beacon filter should
be retriggered during MCC update.
Moreover, if the beacon filter is disabled initially but the GO timeslot
change, causing QoS null data detection fail, also pause MCC to detect new
TBTT beacon.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-7-pkshih@realtek.com
|
|
HW scan of WiFi 7 chips supports multiple op channel configurations.
When concurrency, fill two channels info to HW scan to avoid packet
lost.
However, the OP chan timing is arranged by FW, and the actual stay
period depends on AP. It's hard to calculate total scan time for once
NoA in advance. Therefore, change the scan back to GO OP channel every
200TU and TX beacon to ensure GC doesn't beacon loss. Additionally, add
a period NoA with large duration to ensure GC doesn't TX packet during
GO scanning and can still listen beacon at TBTT to update the new NoA
info after scan complete.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-6-pkshih@realtek.com
|
|
MCC stop might triggered by scan, and need to force to stay at GO role
to keep TX beacon. Also, AX chips need to TX more 3 beacons to ensure
GC can receive once NoA beacon before scan when GC in courtesy mode.
BE chips no needs to TX 3 more beacon because it can TX beacon every
200TU during scan, even GC in courtesy mode can receive beacon every
600TU.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-5-pkshih@realtek.com
|
|
The PD lower bound set after one interface is connected, If second
interface needs to connect, packets might not be detected because the
PD lower bound is too high. Therefore, a DIG suspend/resume flow is
added to decrease the PD lower bound during scanning or connection,
and the original PD level is resumed afterward.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-3-pkshih@realtek.com
|
|
Process ACPI DSM function 11 to get 6 GHz VLP support by country. If
not allowed, return error to block the connection. By default, i.e.
ACPI DSM function is not configured, disallow 6 GHz VLP on country US
and country CA, because some platform-level certifications are needed
in FCC regulation before operating on 6 GHz VLP connection.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250709065006.32028-5-pkshih@realtek.com
|
|
Currently the driver allows the WiFi chip enter power save mode
by checking the transmitting and receiving traffic is very low
per two seconds. But it's hard for some applications to enter
power save mode, like video streaming, which sends burst traffic
regularly for other side to buffer and only send little traffic
at most time. So adjust the criteria to enter power save while
lower than 10Mbps and check it per 100ms. Thus WiFi chip could
reduce power consumption under these applications.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250701073839.31905-1-pkshih@realtek.com
|
|
A few unnecessary error messages are printed when the device is
unplugged. "read swsi busy" in particular can appear ~1000 times when
RTL8851BU is unplugged.
Add a new flag RTW89_FLAG_UNPLUGGED and print some error messages only
when this flag is not set. The new USB driver will set the flag when
the device is unplugged.
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/cc18b739-6f38-4c1a-a681-1e2a0d4ed60d@gmail.com
|
|
USB and SDIO will need different sets of values, so make hfc_param_ini
in struct rtw89_chip_info an array.
Also make param_ini a pointer instead of copying the struct.
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/1356f901-9ebf-451e-827f-50dd3efda534@gmail.com
|
|
USB 2, USB 3, and SDIO will need different sets of values compared to
PCIe.
Add a new dle_type member in struct rtw89_hci_info and make dle_mem in
struct rtw89_chip_info an array to hold the four different sets of
values.
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/c9152735-dbc4-4473-ae29-a79625cfbf78@gmail.com
|
|
To handle hardware characteristic of ADC, calibrate the function and add
a efuse field to record result, which driver uses it to set proper value
accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250627035201.16416-3-pkshih@realtek.com
|
|
Originally the type of path_ok is bool to denote that DPK is ready on
certain path and can be enabled. For RTL8851B, hardware design can support
more than one calibration set, so use type u8 instead to record the
hardware set in current use.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250627035201.16416-2-pkshih@realtek.com
|
|
Because when Wi-Fi/Bluetooth want to communicate with each other, their
contact window are their firmware. So the desired version code is more
reasonable to change with firmware version.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250616090252.51098-6-pkshih@realtek.com
|
|
Add firmware report to monitor Bluetooth TX power/gain settings, so that
we can check it works as expected or not.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250616090252.51098-4-pkshih@realtek.com
|
|
to firmware
In order to reduce driver I/O & some detail instant hardware control, some
of the necessary API offload to Wi-Fi firmware. Collect the reference
parameters to let firmware do decisions.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250611035523.36432-7-pkshih@realtek.com
|
|
Fix unexpected line warp. Collect firmware report format version and
driver support report format version code to check unexpected C2H report
exception.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250611035523.36432-6-pkshih@realtek.com
|
|
To make the logic can work well with WiFi 7 & before generations,
extend & add logic for WiFi 7.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250611035523.36432-4-pkshih@realtek.com
|
|
There were some driver API offloaded to firmware, and to recognize the
feature add a version tag for it.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250611035523.36432-3-pkshih@realtek.com
|
|
The auth retry only continue 40ms, but the GO might switch to STA role
50ms when MCC. Therefore, enlarge the TX retry count from 32 to 60 to
let GC TX time overlapping with GO timeslot.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610130034.14692-12-pkshih@realtek.com
|
|
HW scan leak to TX nulldata 0 to AP after scan completed, which allowed
AP start to TX packet to us. Therefore, driver TX nulldata 0 after scan
completed.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610130034.14692-7-pkshih@realtek.com
|
|
Stop TX during the MCC configuration period to prevent packet leakage.
The stop time is defined as 'start_tsf - tsf', which means the duration
from when MCC configuration begins until MCC starts.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610130034.14692-6-pkshih@realtek.com
|
|
MCC needs to wait at most 300ms to start. Additionally, if
scanning happens before MCC starts, it will miss some beacons,
which might cause beacon loss. Therefore, we reset beacon
filter when MCC start to let hardware reset beacon loss counter.
Additionally, GO is forbid to enter courtesy mode might cause
STA beacon loss. Therefore, disable beacon filter when GO+STA.
However, In WiFi 7 chip, even when GC+STA enable courtesy mode, the
beacon might loss because switching to courtesy timeslot will disable
TX/RX. If the TOB(time offset behind) or TOA(time offset ahead) is
too close to the edge of timeslot, the beacon might not be received.
Therefore, disable beacon filter when GC+STA in WiFi 7 chip.
Because disabling the beacon filter might prevent disconnection
when the AP power-off without sending a deauth. Therefore, driver
TX QOS nulldata periodically to detect the AP status, and the
connection is terminated if no ACK is received for 6 seconds.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610130034.14692-5-pkshih@realtek.com
|
|
The RF notify MCC H2C command format of 8852C different from other
chip, therefore add v0 format to update it.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610130034.14692-3-pkshih@realtek.com
|
|
HW scan flow has considered the timing when to get back op for the scanning
interface. But, when concurrency, there are two interfaces with connection.
The OP channel of another one was not back originally. It then easily lead
to connection loss when scanning during concurrency. So, HW scan flow is
extended to deal with second OP channel. And, H2C command is also extended
to fill second MAC ID.
The changes mentioned above are done for WiFi 6 chips first. HW scan has
different handling architectures including FW and driver on WiFi 7 chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610130034.14692-2-pkshih@realtek.com
|
|
The RF 0x18 register stores radio frequency domain parameters, including
band, center channel and bandwidth. This information is used in RF
domain. Add a chip_ops to retrieve the RF 0x18 value, which allows
driver to query for a specific channel.
No logic is changed.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020408.17035-1-pkshih@realtek.com
|
|
Add new IQK firmware command format v1 (with suffix), and rename original
command format to v0 for older firmware.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250606020302.16873-4-pkshih@realtek.com
|
|
To support channel switch on STA mode, declare IEEE80211_HW_CHANCTX_STA_CSA
and implement ieee80211_ops::switch_vif_chanctx. Handling of CSA procedure
still relies on mac80211 SW flow, since FW doesn't support chanctx offload.
To support channel switch on AP mode, declare WIPHY_FLAG_HAS_CHANNEL_SWITCH
and implement ieee80211_ops::channel_switch_beacon additionally.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250605114207.12381-4-pkshih@realtek.com
|
|
Rename RTW89_FLAG_FORBIDDEN_TRACK_WROK -> RTW89_FLAG_FORBIDDEN_TRACK_WORK.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250603153124.188755-1-pchelkin@ispras.ru
|
|
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
|
|
Add an dbgfs mlo_mode to get/set MLO mode. And, support to trigger MLSR
switching. Setting it will automatically disable MLO Dynamic Mechanism
(DM). Then MLO things can follow commands via dbgfs mlo_mode instead of
MLO DM. The disabled DM(s) can be checked/cleared via dbgfs disable_dm.
The following is an use example.
Read it to show current MLD status.
$ cat mlo_mode
MLD(s) status: (MLO DM: enable)
#0: MLO mode 0, valid 0x6, active 0x2
Write it to switch to MLSR on link id 2.
$ echo 0 2 > mlo_mode
$ cat mlo_mode
MLD(s) status: (MLO DM: disable)
#0: MLO mode 0, valid 0x6, active 0x4
Besides, to be safer, add RWLOCK attribute to dbgfs disable_dm.
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-11-pkshih@realtek.com
|
|
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
|
|
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
|
|
For data packets that can be sent on any band, fill in main mac_id
and let HW decide. For packets that we wish to transmit on specific
band, fill in sw_mld field so HW would only send it on that band.
Main mac_id is the corresponding mac_id on band 0.
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-3-pkshih@realtek.com
|
|
Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To
prevent signal distortion from excessive power increases, a dynamic
antenna power table limits the maximum adjustable TX power.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250430055157.13623-3-pkshih@realtek.com
|
|
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
|
|
Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link
which deals with the ROC process. Before enabling MLO support, it's fine
to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on
HW-0) is always active. But, for the impending enablement of MLO support,
tweak the leaf functions to dynamically handle ROC link instance index.
Besides, in the follow-up, ROC caller will get a designated link and will
then drop RTW89_ROC_BY_LINK_INDEX.
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-10-pkshih@realtek.com
|
|
For MLO connections, RX link ID is required to do address conversion.
Fill it in by the hardware info.
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-9-pkshih@realtek.com
|
|
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
|
|
MCC has a courtesy mechanism which allows one role to use another's
duration in a given cycle. Originally, this courtesy mechanism only
supports in one direction. However, in some field cases, both of MCC
roles may simultaneously have timing configurations that are not good
enough. So, support courtesy mechanism in both directions.
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-11-pkshih@realtek.com
|
|
There are two roles during MCC and the offset between their TBTT is called
beacon offset. Originally, when MCC runs GO+STA mode, it used fixed beacon
offset to simplify some logic because GO role can master its TSF. However,
if MCC is stopped and restarted before a same GO is down, its TSF might be
discontinuous. Then, there might be undefined behavior happens in GC sides.
So, to let a same GO have a continuous TSF, MCC no longer changes its TSF
to meet a fixed beacon offset. Instead, GO+STA mode also calculates beacon
offset dynamically as what GC+STA mode did.
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-8-pkshih@realtek.com
|
|
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
|
|
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
|
|
A new ACPI table entry format for TAS is defined, which includes
a "specific country" field. In this field, determine which
country can enable TAS.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-3-pkshih@realtek.com
|
|
Intermittent beacon loss from specific AP triggers disconnection
and reconnection. Increasing the beacon loss count will make the
connection more stable.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-2-pkshih@realtek.com
|
|
Before adopting regd_UK TX power settings, some certifications are needed
and might be platform-level. Without that, should adopt regd_ETSI TX power
settings. But for now, there is no way to inform driver of it yet. So, add
a flag first. But for now, comprehensively use regd_ETSI TX power settings
to restrict regd_UK.
Plan to define an ACPI DSM function to inform driver whether to use regd_UK
own TX power settings or not afterwards.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250416081241.36138-4-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
|
