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
Since FW cannot handle HW scan process and MCC (multi-channel concurrency)
mode simultaneously, if a HW scan is requested during MCC, MCC mode will be
paused temporarily. Then, the GO role if any might be absent. So, calculate
an estimated time for the requested HW scan process and search for existing
GO roles to fill one-time NoA.
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-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
These stuffs have no suffix, but not universal, and only work for Wi-Fi 6.
Since the corresponding HW scan struct/func of Wi-Fi 7 have suffix "_be",
to avoid misunderstanding and improve readability, also add suffix "_ax"
to these Wi-Fi 6 stuffs.
(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/20250422014620.18421-4-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
After firmware 0.27.125.0, it adds more fields to support firmware secure
boot. Though current driver has supported the format, old driver can't
recognize the new format, increase firmware format to 2 to avoid failed
to load the firmware by old driver.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250416081241.36138-2-pkshih@realtek.com
The rtw88 module names all start with the "rtw88_" prefix, but the
messages in dmesg mostly use the "rtw_" prefix. The messages from
rtw88_8723cs don't even have the underscore.
Use the KBUILD_MODNAME macro in every driver. This ensures that the
messages in dmesg will always use the module name.
Before:
Mar 17 15:54:19 ideapad2 kernel: rtw_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6
After:
Mar 17 16:33:35 ideapad2 kernel: rtw88_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/29cd29ba-bc51-4d5b-ad48-a43c6ce72d56@gmail.com
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
This was generated with coccinelle:
@@
expression E;
@@
- flush_workqueue(E);
destroy_workqueue(E);
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250324080303.408084-1-nichen@iscas.ac.cn
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
This was generated with coccinelle:
@@
expression E;
@@
- flush_workqueue(E);
destroy_workqueue(E);
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250324075910.407999-1-nichen@iscas.ac.cn
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
Support to load GEO (geography) SAR tables with ACPI RWGS method. When
SAR values could be different by regulatory, GEO SAR can be used. The
format of GEO SAR is like the following, where regulatory number, band
number, and delta number are determined by header of either static SAR
or dynamic SAR. (It also means that no GEO SAR will be considered when
neither static SAR nor dynamic SAR is configured.)
delta number
/ \
+ +-----+-----------------+
/ | | max | delta... | \
/ | +-----+-----------------+ band
/ | | max | delta... | number
/ | +-----+-----------------+
/ | |... | /
+ +-----+-----------------+
| | max | delta... | \
regulatory | +-----+-----------------+ band
number | | max | delta... | number
| +-----+-----------------+
| |... | /
+ +-----+-----------------+
\ | |... |
\ | |... |
\ | |... |
\ | | |
\ | | |
+ +-----+-----------------+
Each entry of GEO SAR contains delta field(s), which are offset(s) used
to tweak the loaded static/dynamic SAR table(s) by antenna, and one max
field, which describes the maximum of the final SAR values after tweaked.
Different entries should be configured based on both regulatory and band.
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-9-pkshih@realtek.com
Support to load dynamic SAR tables with ACPI RWRD method. The content
format of a single dynamic SAR table is basically the same as static
SAR table. However, it's able to carry multiple dynamic SAR tables at
one time. And, its header contains one more field to describe how many
dynamic SAR tables are filled in the content. Either static SAR table
or dynamic SAR tables can be supported, but not both simultaneously.
Besides, also support to load indicator of dynamic SAR with ACPI RWSI
method. The indicator will describe a target dynamic SAR table, which
should be followed currently, by antenna. It can be changed at runtime
according to platform mode. For example, tablet mode can use different
SAR from normal mode. So, track indicator configuration if dynamic SAR
is configured.
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-8-pkshih@realtek.com
Support to load static SAR table with ACPI WRDS method. The format of
a static SAR table is like the following, where according to header,
antenna number could be either 2 or 4 and subband number could either
contain 6 GHz or not. And then, an entry of it describes a TX power
limitation with a given unit, which is also based on header, for the
antenna under the subband. Though things can be determined by header,
still not all combinations are allowed in content. For the recognizing
flow, there is a list of allowed combinations.
+--------------------------------+
| header |
+--------------------------------+
+---+---+---+---+---+------------+ +
/ | | | | | | ... | | \
+---+---+---+---+---+------------+ |
antenna | | | | | | ... | |
number +---+---+---+---+---+------------+ | content
|...| | | | | ... | |
+---+---+---+---+---+------------+ |
\ |...| | | | | ... | | /
+---+---+---+---+---+------------+ +
\ /
subband number
Following the format above, try to load a static SAR table and normalize
its content into SW structure. If any recognized is loaded, SW SAR flow
is then set up with source from ACPI.
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-7-pkshih@realtek.com
To support SAR configuration in BIOS via ACPI, add related subbnad/band
converting/handling function and define SW format to store result after
parsing. Then, register a new SAR source, i.e. ACPI, into SAR flow and
implement its query function.
Besides, tweak priority of common SAR to be the highest. And, ACPI SAR
can just be configured once when no other sources is already working.
For now, evaluating SAR via ACPI returns -ENOENT, i.e. ACPI SAR doesn't
really work yet. The evaluating flow 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>
Link: https://patch.msgid.link/20250326020643.14487-5-pkshih@realtek.com
The following implementations will support SAR source from ACPI/BIOS.
And when querying, it needs to take more parameters into account. To
avoid changing function prototype of querying SAR everytime when new
SAR source is introduced, wrap query parameters into a structure first.
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-4-pkshih@realtek.com
The firmware->size is validated before using firmware->data, but Coverity
still reports:
Downcasting "firmware->data" from "u8 const *" to "struct rtw89_mfw_hdr"
implies that the data that this pointer points to is tainted."
Using &firmware->data[0] to avoid the warning. No change logic at all.
Addresses-Coverity-ID: 1494046 ("Untrusted loop bound")
Addresses-Coverity-ID: 1544385 ("Untrusted array index read")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250325025424.14079-1-pkshih@realtek.com
The 'continue' statements need to be under spinlock, since
the spinlock needs to be held as a loop invariant.
Fixes: 0762bdd302 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Felix Fietkau says:
====================
mt76 patches for 6.15
- preparation for mt7996 mlo support
- fixes
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
