Fast forward master to the latest master from upstream repo - #1
Open
thomas-slamcore wants to merge 197 commits into
Open
Fast forward master to the latest master from upstream repo#1thomas-slamcore wants to merge 197 commits into
thomas-slamcore wants to merge 197 commits into
Conversation
In AP mode, the firmware stops transmitting beacons if it receives
H2C_CMD_RA_INFO for macid 0.
Leave macid 0 unused in AP mode. Macid 1 is already reserved for
broadcast/multicast. That means the first connected client is now
assigned macid 2.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
1. Sort the directives "BUILT_MODULE_NAME[]" by module names. 2. Directive "DEST_MODULE_LOCATION[]" is ignored on Fedora, RHEL, OpenSuSE, Debian, Ubuntu, Arch Linux and some other distros, and built modules are always installed to /lib/modules/$(uname -r)/updates/dkms, so we install them to this place, too.
The leading sign "-" will tell make to ignore the exit staus of the command so that uninstallation wouldn't stop for any reason.
Very minor English language mods.
Since the rtw88_8812au and rtw88_8821au drivers will be going into mainline soon, we should blacklist them now so that we do not forget.
Added rtw88_8821a twice and left rtw88_8821au out. This is fixed now.
This new automatic blacklist works for in-kernel rtw88 driver but not for out-of-kernel vendor drivers.
Suppress error messages when running 'sudo make uninstall'
On Debian/Ubuntu and some other distros, the recipes in Makefile are executed by dash shell which doesn't support brace expansion, and this causes the modules won't be unloaded when removing the driver, so in this commit we use another way to unload them.
Fix module unloading when removing the driver
Final check and update prior to upstream.
Final check and update prior to upstream.
That's not supposed to be there. Fixes slow download with RTL8822BU in USB 3 mode. lwfinger#224 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Upstream commit d0bcb10e7b94861c714ab1e62c98bf8abaa37527. Embedding net_device into structures prohibits the usage of flexible arrays in the net_device structure. For more details, see the discussion at [1]. Un-embed the net_device from the private struct by converting it into a pointer. Then use the leverage the new alloc_netdev_dummy() helper to allocate and initialize dummy devices. [1] https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/ Tested with RTL8723DE and RTL8822CE. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240425082910.2824393-1-leitao@debian.org
Upstream commit 8db6c1ca64664ef9b071e6eeb646023ac5b240a8.
Originally in order to read partial registers from large area, we write
a range value stored into a static variable and read registers according
to the static variable.
However, if we install more than one adapters supported by this driver,
the static variables will be overwritten by latter adapters. To resolve
the problem, move the static variables to struct rtw_dev for each adapter.
With changes, smatch spends too much time to parse rtw_debugfs_init():
debug.c:1289 rtw_debugfs_init() parse error: turning off implications
after 60 seconds
Move stuffs of adding debugfs entries to three rtw_debugfs_add_xxx()
functions.
Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/cd6a2acf3c2c36d938b40140b52a779516f446a9.camel@realtek.com/T/#m27662022c70d9f893ba96f6c6a8dd8fce2434dfe
Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240718064155.38955-1-pkshih@realtek.com
… reports Upstream commit 53ed4b25a79aeec5991c2dc579e635b136ef7676. For CCK packets we could get incorrect reports from hardware. And this causes wrong frequencies being reported. Parse the channel information from IE if provided by AP to fix this. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724050501.7550-1-pkshih@realtek.com
Upstream commit 0e735a4c6137262bcefe45bb52fde7b1f5fc6c4d.
In 'rtw_wait_firmware_completion()', always wait for both (regular and
wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'
has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue
'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually
the wowlan one) is still in progress, causing UAF detected by KASAN.
Fixes: c8e5695 ("rtw88: load wowlan firmware if wowlan is supported")
Reported-by: syzbot+6c6c08700f9480c41fe3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6c6c08700f9480c41fe3
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240726114657.25396-1-dmantipov@yandex.ru
This reverts commit 98de16f. Will apply the upstream version in the next commit.
Upstream commit fbbd8cb347e25b68d25c4f3871821afc495ee7a9. This is needed in order to make USB RX aggregation work with RTL8811CU (and presumably RTL8822BU and RTL8822CU also). I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN are doing. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. The RX speed is unchanged in my tests. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
More or less upstream commit 002a5db9a52a0e7af0fa9a450d31049748435748.
Upstream commit df3d8f463b1dfc7cb8f4fb52b1b81d290b850d03.
Upstream commit 77c977327dfaa9ae2e154964cdb89ceb5c7b7cf1.
In 'rtw_coex_action_bt_a2dp_pan', 'wl_cpt_test' and 'bt_cpt_test' are
hardcoded to false, so corresponding 'table_case' and 'tdma_case'
assignments are never met.
Also 'rtw_coex_set_rf_para(rtwdev, chip->wl_rf_para_rx[1])' is never
executed. Assuming that CPT was never fully implemented, remove
lookalike leftovers. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 76f631c ("rtw88: coex: update the mechanism for A2DP + PAN")
Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240809085310.10512-1-d.kandybka@gmail.com
Sync with upstream commit faa2e484b393c56bc1243dca6676a70bc485f775. USB devices were fixed earlier.
This reverts commit 610e04f. A better fix in the next commit.
Upstream commit 902cb7b11f9a7ff07233cc4c626b54c3e4703149.
A mac_id as an instance in firmware has to be assigned for each station
including AP and connected stations. Firmware will use the mac_id to
control TX rate and do statistics.
Assignment rule is to assign mac_id to each vif when adding vif.
For station mode, sta->mac_id will reuse vif->mac_id. For AP mode,
dynamically allocate an sta->mac_id to a station, and vif->mac_id is
used to send broadcast/multicast packets which are not belong to
a station. For example,
vif->mac_id sta->mac_id
vif0 (STA mode) 0 0
vif1 (AP mode) 1 2...
By the way, remove unused RTW_BC_MC_MACID, which was planed to send
broadcast/multicast packets on fixed mac_id.
Tested-on RTL8822CE with STA + AP SCC mode.
Link: https://lore.kernel.org/linux-wireless/e4be0a75-43b2-4ae5-9aab-5c4a88e78097@gmail.com/
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240819025248.17939-1-pkshih@realtek.com
Avoid triggering the WARNING in ieee80211_rx_monitor(). For lwfinger#343. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
This reverts commit 9c44629. That was not well thought through. Some messages from the firmware are also discarded. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Avoid triggering the WARNING in ieee80211_rx_monitor(). For lwfinger#343. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
All the USB devices have a problem in AP mode: uploading the updated beacon to the chip's reserved page can randomly fail: [34996.474304] rtw88_8723du 1-2:1.2: error beacon valid [34996.474788] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [34999.956369] rtw88_8723du 1-2:1.2: error beacon valid [34999.956846] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [34999.956855] rtw88_8723du 1-2:1.2: failed to download beacon [35017.978296] rtw88_8723du 1-2:1.2: error beacon valid [35017.978805] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [35017.978823] rtw88_8723du 1-2:1.2: failed to download beacon [35023.200395] rtw88_8723du 1-2:1.2: error beacon valid [35023.200869] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [35023.200875] rtw88_8723du 1-2:1.2: failed to download beacon [35478.680547] rtw88_8723du 1-2:1.2: error beacon valid [35478.681023] rtw88_8723du 1-2:1.2: failed to download drv rsvd page It appears to be caused by some missing magic in rtw_fw_write_data_rsvd_page(). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
1. Refine the dkms installation instructions. 2. Stop teaching users to install the driver on a system with Secure Boot Enabled via make. 3. Refine the instructions to load/unload the driver. 4. Add the instructions to update the driver installed via DKMS. 5. Remove Q1 and Q5 in Q&A which are not useful.
1. Rename blacklist-rtw88.conf to rtw88.conf 2. Blacklist the in-kernel rtw88 drivers for 8814AE/8814AU. 3. Add config entries for all the module parameters available. 4. Enable flags which are useful for debugging by default.
If users encounter a recovery problem after sleep/hibernation, they can copy this script to /usr/lib/systemd/system-sleep/. It will unload/reload the rtw88 drivers on suspend/resume automatically.
The USB ID "2357:013c" does not seem to exist, so remove it.
EXTRA_CFLAGS is no longer supported since kernel 6.15, so replace it with ccflags-y. These 7 lines have no effect, remove them also. > ifeq ($(CONFIG_PCI), y) > EXTRA_CFLAGS += -DCONFIG_RTW88_8822BE=1 > EXTRA_CFLAGS += -DCONFIG_RTW88_8821CE=1 > EXTRA_CFLAGS += -DCONFIG_RTW88_8822CE=1 > EXTRA_CFLAGS += -DCONFIG_RTW88_8723DE=1 > endif > #EXTRA_CFLAGS += -DCONFIG_RTW88_REGD_USER_REG_HINTS
Just some random updates
When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to and correctly identify the char array as "not a C string" and thereby eliminate the warning. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-wireless@vger.kernel.org Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250310222257.work.866-kees@kernel.org
Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads
5 bytes:
void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
...
SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
...
SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));
Detected using the static analysis tool - Svace.
Fixes: 4136214 ("rtw88: add BT co-existence support")
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com
Sometimes PCIe Advanced Error Reporting(AER), like bad TLP or Data link protocol error, happens due to unstable pci signal or no response from PCI host. pcieport 0000:00:00.0: AER: Multiple Corrected error message received from 0000:00:00.0 pcieport 0000:00:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) pcieport 0000:00:00.0: AER: device [14c3:6786] error status/mask=000000c1/00006000 pcieport 0000:00:00.0: AER: [ 0] RxErr (First) pcieport 0000:00:00.0: AER: [ 6] BadTLP pcieport 0000:00:00.0: AER: [ 7] BadDLLP pcieport 0000:00:00.0: AER: Corrected error message received from 0000:00:00.0 pcieport 0000:00:00.0: AER: found no error details for 0000:00:00.0 pcieport 0000:00:00.0: AER: Multiple Corrected error message received from 0000:00:00.0 pcieport 0000:00:00.0: AER: found no error details for 0000:00:00.0 pcieport 0000:00:00.0: AER: Multiple Corrected error message received from 0000:00:00.0 pcieport 0000:00:00.0: AER: found no error details for 0000:00:00.0 Setup callback function to call SER function to reset driver to recover from these states Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250523062711.27213-2-pkshih@realtek.com
Add VID/PID 0411/03d1 for recently released BUFFALO WI-U2-866DM USB WiFi adapter. Signed-off-by: Yuuki NAGAO <wf.yn386@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250503003227.6673-1-wf.yn386@gmail.com
In 'rtw8822c_dpk_cal_coef1()', do not ignore error returned
by 'check_hw_ready()' but issue a warning to denote possible
DPK issue. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 5227c2e ("rtw88: 8822c: add SW DPK support")
Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250415090720.194048-1-dmantipov@yandex.ru
The rtw88-sdio do not work in AP mode due to the lack of TX status report
for management frames.
Map the management frames to queue TX_DESC_QSEL_MGMT, which enables the
chip to generate TX reports for these frames
Tested-on: rtl8723ds
Fixes: 65371a3 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250410154217.1849977-3-zhen.xin@nokia-sbell.com
The rtw88-sdio do not work in AP mode due to the lack of TX status report
for management frames.
Make the invocation of rtw_sdio_indicate_tx_status unconditional and cover
all packet queues
Tested-on: rtl8723ds
Fixes: 65371a3 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250410154217.1849977-2-zhen.xin@nokia-sbell.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 Note that in this repository the prefix is actually "rtw_", to distinguish from the built-in modules.
The RTW_WCPU_11AC and RTW_WCPU_11N enums are used to identify two types of microcontrollers used in Realtek chips, but these names are misleading. The "11AC" type was also used in 11n devices (e.g. RTL8733BU, not supported by rtw88), and the "11N" type was also used in 11ac devices (RTL8821AU, RTL8812AU). Rename RTW_WCPU_11AC to RTW_WCPU_3081 and RTW_WCPU_11N to RTW_WCPU_8051. (8051 is well known. It's less clear what 3081 is, but the out of tree drivers use this name.) Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/bfb1099c-db52-4b25-b111-17ab712e9404@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
Update to the version of the patch that went into the kernel. Upstream commit 80fe0bc1659c0ccc79d082e426fa376be5df9c04. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
It was already deactivated before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
To match the version that went into the kernel. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
To match the version that went into the kernel. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@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/20250324075910.407999-1-nichen@iscas.ac.cn
When working in station mode, a TDLS peer is assigned macid 0, even though 0 was already assigned to the AP. This causes the connection with the AP to stop working after the TDLS connection is torn down. Assign the next available macid to TDLS peers, same as client stations in AP mode. lwfinger#198 (comment) Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Some users report that the LED blinking breaks AP mode somehow. Most likely the LED code and the dynamic mechanism are trying to access the hardware registers at the same time. Lock rtwdev->mutex before setting the LED and unlock it after to prevent this. Link: lwfinger#305 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
thomas-slamcore
requested review from
jonathanponcelet-slamcore and
kax-slamcore
August 1, 2025 12:34
|
Do all of these changes need reviewing, or is it just a scan through for anything that looks out of place? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.