The security section can be a common parser for v0 and v1 format of
firmware header, so move retrieval code of v1 MSSC from the function, and
then sharing becomes possible.
Not logic change at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030022135.11688-7-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
For RTL8852B, when current firmware is secure boot, the security section
needs a special treatment that shrink its size to 960.
As figure below, not only shrink the amount of download size of security
section (2), but also need to modify the section size in firmware header
(1) that is also downloaded to chip.
+---------------------------+
| firmware header |
| |
| +-----------------------+ |
| | section type, size N -|-|-------+
| | ... (1) | | |
| +-----------------------+ | |
+---------------------------+ | 2048 shrink to 960
: : |
+---------------------------+ -\ |
| security section type 9 | | |
| (2) | | <--+
| | |
+---------------------------+ -/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030022135.11688-5-pkshih@realtek.com
WiFi 6 chips could program secure information in v0 or v1 format. Use
existing v1 parser or newly added v0 parser to recognize firmware key
that is going to be used.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241030022135.11688-4-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
Set pause_data to all of the scan channels, excluding the OP channel,
to prevent data frame transmission to the scan channels, which causes
retransmission. Additionally, this flag won't affect the transmission
of probe requests from the scan channels.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241026022143.7304-1-pkshih@realtek.com
In WoWLAN mode, driver will disable interrupt after calling H2C command
for entering PS mode, but it may lead to failing to enter deep PS mode by
firmware because the done-ack of the H2C from firmware is not handled by
driver. In fact, the done-ack for entering PS is not necessary for driver
to check, so remove it.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241024055509.8000-1-pkshih@realtek.com
The RTL8812AU has a reception problem, maybe only in the 5 GHz band.
Sometimes, in some positions, it stops receiving anything even though
the distance to the AP is only ~3 meters and there are no obstacles.
Moving it a few centimeters fixes it.
Switch the initial gain to maximum coverage when there is beacon loss.
This only helps sometimes. This is similar to what the official driver
does.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/203f5043-4fe1-4f35-8b8f-d3b6f44e1fd9@gmail.com
The RTL8821AU firmware sends C2H_BT_INFO by itself when bluetooth
headphones are connected, but not when they are disconnected. This leads
to the coexistence code still using the A2DP algorithm long after the
headphones are disconnected, which means the wifi speeds are much lower
than they should be. Work around this by asking for updates every two
seconds if the chip is RTL8821AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/358acdd2-6aae-46c1-9c66-fcce4e700b96@gmail.com
All the chips currently supported have a "scoreboard": the chip keeps
track of certain things related to bluetooth, for example, whether
bluetooth is active. The information can be read from register 0xaa.
RTL8821AU doesn't have this. Implement bluetooth activity detection in
rtw_coex_monitor_bt_enable() based on the bluetooth TX/RX counters.
This is mostly important for RTL8811AU, the version of RTL8821AU without
bluetooth. Without this change, the driver thinks bluetooth is active
and the wifi speeds are low.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/5058f23d-2086-42cd-82ad-eef31a348467@gmail.com
The driver is supposed to avoid entering LPS (power saving) when there
is beacon loss, but only RTL8822C detects the beacon loss (because it
has beacon filtering in the firmware).
Detect beacon loss with the other chips by checking if we received less
than half the expected number of beacons in the last 2-second interval.
This gets rid of the occasional "failed to get tx report from firmware"
warnings with RTL8821AU. It may also avoid some disconnections.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f52b2fcf-bf94-48bc-89bd-e55ebc3a2f2d@gmail.com
"ls" meaning "last segment". Without this RTL8812AU can't upload the
reserved page in USB 2 mode. (Somehow it's fine in USB 3 mode.)
Also tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8723DU, RTL8811AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/e443f5d9-4b53-4f64-985c-64313ec80bef@gmail.com
RTL8812AU uses one set of TX power tracking tables for RFE 3, and
another set for everything else.
Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in
order to load the right set of tables for each RFE (RF front end) type.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com
All the chips supported so far have a TX page size of 128 bytes.
Change the type of the page_size member of struct rtw_chip_info from u8
to u16 in order to support RTL8821AU (page size of 256 bytes) and
RTL8812AU (page size of 512 bytes). Also change the types of several
related variables and function parameters from u8 to u16.
The TX page size is used, among other things, to construct the beacon,
null data, QOS null data, and PS poll templates which are uploaded to
the chip's reserved page. Each template needs to be aligned on a
multiple of the TX page size. Power saving can't work if the TX page
size is wrong.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/acdefbb1-3daf-4349-9e03-9472754d5f1e@gmail.com
txagc_remnant_ofdm member of struct rtw_dm_info should be different for
each RF path, so make it an array of size RTW_RF_PATH_MAX (4).
Until now all the chips using this had only one RF path, but RTL8812AU
has two, and RTL8814AU has four.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/68571ba9-e504-4b2d-bfa1-62f468753649@gmail.com
RTL8811AU fails to perform the 4-way handshake when the AP is too far
because it transmits the EAPOL frames at MCS9 and when that doesn't
work it retries 48 times with the same rate, to no avail.
Retrying 48 times with the same rate seems pointless. Set the
appropriate field in the TX descriptor to allow it to use lower rates
when retrying.
Set it for RTL8723D and RTL8703B because they interpret this field the
same way as RTL8811A.
The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in
the TX descriptor differently, so leave it alone for those chips.
Tested with RTL8811AU and RTL8723DU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com
RTL8821AU and RTL8812AU have to do some things differently, so let
them have full control.
The other chips use the same functions as before.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
RTL8821A doesn't have this. Trying to use it results in error messages,
so don't try if ltecoex_addr is NULL.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com
The chips supported so far only use the first condition, and so the
parsing code ignores the second condition. RTL8812AU's init tables use
the second condition also. Make the parsing code check it.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com
The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes.
Avoid the "invalid ra report c2h length" error.
Also, use a struct and u8_get_bits() to access the RA report C2H.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
Add 8821A and 8812A chip type enums.
Add cck_high_power member to struct rtw_hal. This will be used to
calculate the RX signal strength of RTL8812AU.
Add various register definitions which will be used by the new drivers.
Move some existing register definitions from rtw8821c.h and rtw8822b.h.
They were duplicated in those headers and will also be used by the new
drivers.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com
RTL8811CU doesn't report the signal strength for many (any?) data
frames. When the signal strength is not known, set
RX_FLAG_NO_SIGNAL_VAL in order to avoid reporting a signal
strength of 0.
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/f7e1e448-2c9b-498f-b8b1-a14dd967d7d3@gmail.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
Setting of channel and TX power depend on channel contexts, but original
code cannot handle combination of MCC (multi-channel concurrency) and MLO
well. So according to active interfaces, we generate a table for current
channel contexts. And then based on entity mode, we get the corresponding
channel context to apply during channel or TX power setting. When MLO is
supported, there will be dual-PHY and we will apply the channel context of
the 2nd link to the 2nd PHY.
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-5-pkshih@realtek.com
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
In order to make encryption/decryption work properly with MLO
connections, MLD address needs to be filled in so circuits can
operate with the correct information.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-3-pkshih@realtek.com
For MLO connections, this setting replaces 802.11 header addresses
to according link addresses based on each packet's destination.
The fields most likely to be replaced would be both A1 and A2.
For legacy connections, it's the same with or without the conversion.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-2-pkshih@realtek.com
We need to call mutex_unlock() on this error path.
Fixes: aad0394e7a ("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
There might be some racing between BT and WiFi after scan. Since
one of the TX related register will be modified by both FW and
rtw89_set_channel() in driver, which could cause Tx fail. Reorder
the calling sequence to only notify coexistence mechanism after
rtw89_set_channel() is called, so that there are no concurrent
operations.
Fixes: 5f499ce69b ("wifi: rtw89: pause/proceed MCC for ROC and HW scan")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241021063219.22613-1-pkshih@realtek.com
The priority table should be changed according to what the in using
Bluetooth application is. To avoid Bluetooth audio + HID (mouse) will
trigger the lag experience, update the priority table.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241019063131.9462-1-pkshih@realtek.com
This is one of three drivers that trigger -Wenum-compare-conditional warnings
with clang:
drivers/net/wireless/realtek/rtw89/core.c:1806:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1806 | return eht ? NL80211_RATE_INFO_EHT_GI_0_8 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1807 | NL80211_RATE_INFO_HE_GI_0_8;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1810:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1810 | return eht ? NL80211_RATE_INFO_EHT_GI_1_6 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1811 | NL80211_RATE_INFO_HE_GI_1_6;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1813:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1813 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1814 | NL80211_RATE_INFO_HE_GI_3_2;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1818:15: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1818 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1819 | NL80211_RATE_INFO_HE_GI_3_2;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this case, all four warnings can be easily avoided by splitting the
function into two separate ones, in a way that helps readability as well,
at the expense of a few extra source lines.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241018152311.4023979-1-arnd@kernel.org
The previous implementation included an unnecessary else
condition paired with a continue statement. Since a check
is already performed to determine if the band is either
2G or 5G, the else condition will never be triggered.
We can remove this check.
Signed-off-by: Mohammed Anees <pvmohammedanees2003@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241017080638.13074-1-pvmohammedanees2003@gmail.com
Specific PCI subsystem ID (SSID) of WiFi cards is used by specific
customer who want to enable various features with different arguments.
Define PCI SSID quirks tables to enable thermal protection with two kinds
of thermal values for 110 and 120 degree Celsius.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-3-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
The return type of error code of rtw8852c_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1626056 ("Overflowed constant")
Addresses-Coverity-ID: 1627945 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-7-pkshih@realtek.com
The return type of error code of rtw8852bt_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1630962 ("Overflowed constant")
Addresses-Coverity-ID: 1632126 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-6-pkshih@realtek.com
The return type of error code of rtw8852b_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1622433 ("Overflowed constant")
Addresses-Coverity-ID: 1630710 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-5-pkshih@realtek.com
The return type of error code of rtw8851b_pwr_{on,off}_func() and its
callee is 'int'. Correct it.
Addresses-Coverity-ID: 1624679 ("Overflowed constant")
Addresses-Coverity-ID: 1630970 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-4-pkshih@realtek.com
The return type of error code of read_poll_timeout() and
rtw89_pci_poll_{tx,rx}dma_ch_idle_ax() and must be 'int'.
Correct them accordingly.
Addresses-Coverity-ID: 1622341 ("Overflowed constant")
Addresses-Coverity-ID: 1627296 ("Overflowed constant")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-3-pkshih@realtek.com
The type of tsf arithmetic is
u64 += u16 * int;
When (u16 * int) is larger than 0x7FFFFFFF, the value casting to u64 with
sign-extension will become all 1 in upper 32 bits part.
To meet the case, u16 value should be larger than 20491
(0x7FFFFFFF / 104800). Fortunately the meaning of 20491 is delay time of
WoWLAN net detection in unit of second, so 20491 seconds (5.7 hours)
might not a real case we can meet.
Addresses-Coverity-ID: 1620910 ("Unintended sign extension")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241009004300.8144-2-pkshih@realtek.com
No big change at this point. Regular development and fixes are listed:
rtl8xxxu:
- correct beaconing for the case of STA + AP
rtw88:
- consolidate parser of RX descriptor as preparation to support coming
chips
rtw89:
- update BT-coexistence to improve user experience for RTL8852BE and
RTL8852BE-VT
- correct RTL8922AE RF calibration timeout time and print out firmware
log
- set proper PCI EQ value for RTL8852CE and RTL8922AE
- adjust to support MLO continuously
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmcHKC4ACgkQjlvZYmhs
hd9p4hAArKllxcVcSpX0mOXFMhbFJV3dpsJZ9VZQ3u2FsBq88zLdX0manRsepEbQ
78DlgHaNzE3CflyAFp6xOf8XAucdJndksluVZapnWvRGVJHzFent/MgfLgQyRQWK
iY4hAUtwnwrlvc3oKM5L0ZKAn8BinPf9VkdXu5xY3MnlphWqNwfl4wMs8Qqgj/8/
F+7+TFL1hjecMMzY+0fnXo1WyoEfK6yUoLwgo19WaikV3tVe4MWF9Hghhoat94C8
YOcjOF2xIkKCdKdzQuZz1julSX1ga9nKNPKpobiSGoHG8Clo0BPUMCf7mA4uGyj5
nUxqUqfYpfcDXhCGWyemd07H09CQ85fxW/Q3SkdyB/Fx8c+/V1flUqCA+1hUJX7/
p6vll1udFMpUgR3RF0IYOesmVmV7m2Qg7SKZjOf05YdD3+biAOXrrMgDBLhuYdZz
aOLIQIeblD0JtNL1wgQmSWscXjWmiSbEROqxIy9vq0vEhYG+1rURz8sv+zRp03oB
9lEkAj+dPN1mObph8pdqcW7TSkihGglhTd0g8KiID1OEMPgUErf5U5U+dJUCSZPt
8Hu2wI6t5K6x8BkbbXVPZLJo+HfhNOv3x9xHuOtO48q0CY93SK7PGZXNqOjA2c+7
Z4L4COSeAsDauL3eBrC54AmMfarOF9OwY/mPrXHlGJSw0NtdTuI=
=qbTP
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2024-10-10' of https://github.com/pkshih/rtw
rtw-next patches for v6.13
No big change at this point. Regular development and fixes are listed:
rtl8xxxu:
- correct beaconing for the case of STA + AP
rtw88:
- consolidate parser of RX descriptor as preparation to support coming
chips
rtw89:
- update BT-coexistence to improve user experience for RTL8852BE and
RTL8852BE-VT
- correct RTL8922AE RF calibration timeout time and print out firmware
log
- set proper PCI EQ value for RTL8852CE and RTL8922AE
- adjust to support MLO continuously
cw1200_queue_requeue_all() has been unused since it was added in 2013 by commit
a910e4a94f ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241012203852.229151-1-linux@treblig.org
Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------
[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed.
Fixes: 5e6e3a92b9 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241007222301.24154-1-alpernebiyasak@gmail.com
brcms_debugfs_get_devdir() has been unused since it was added by commit
8e21df2389 ("brcmsmac: hardware info in debugfs")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241004004259.470853-1-linux@treblig.org
