| Age | Commit message (Collapse) | Author |
|---|
|
RTL8811AU stops responding during the firmware download on some systems:
[ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0
[ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0
[ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110
[ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110
[ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110
Maybe it takes too long when writing the firmware 4 bytes at a time.
Write 196 bytes at a time for RTL8821AU, RTL8811AU, and RTL8812AU,
and 254 bytes at a time for RTL8723DU. These are the sizes used in
their official drivers. Tested with all these chips.
Cc: stable@vger.kernel.org
Link: https://github.com/lwfinger/rtw88/issues/344
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/43f1daad-3ec0-4a3b-a50c-9cd9eb2c2f52@gmail.com
|
|
Use the same RX aggregation size and timeout used by the out-of-tree
RTL8723DS driver. Also set mystery bit 31 of REG_RXDMA_AGG_PG_TH. This
improves the RX speed from ~44 Mbps to ~67 Mbps.
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/4c79fdc1-54bc-4986-9931-bb3ceb418b97@gmail.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: 65371a3f14e7 ("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-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: 65371a3f14e7 ("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
|
|
'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
|
|
These structs and arrays are never modified, so make them const:
rtw_band_2ghz
rtw_band_5ghz
rtw_pci_tx_queue_idx_addr
rtw_pci_ops
rtw_cck_rates
rtw_ofdm_rates
rtw_ht_1s_rates
rtw_ht_2s_rates
rtw_vht_1s_rates
rtw_vht_2s_rates
rtw_rate_section
rtw_rate_size
rtw_sdio_ops
rtw_usb_ops
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/502f124e-ccf3-4c09-80a4-1e5c5304822b@gmail.com
|
|
This is the equivalent of commit 28818b4d871b ("wifi: rtw88: usb: Fix
disconnection after beacon loss") for SDIO chips.
Tested on Pinephone (RTL8723CS), random disconnections became rare,
instead of a frequent nuisance.
Cc: stable@vger.kernel.org
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # Tested on Pinebook
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250106135434.35936-1-fiona.klute@gmx.de
|
|
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
|
|
rtw8703b_query_rx_desc(), rtw8723d_query_rx_desc(),
rtw8821c_query_rx_desc(), rtw8822b_query_rx_desc(), and
rtw8822c_query_rx_desc() are almost identical, so replace them all with
a single function, rtw_rx_query_rx_desc().
Also, access the RX descriptor using a struct with __le32 members and
le32_get_bits().
Tested with RTL8811CU, RTL8811AU, and RTL8812AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Tested-by: Ping-Ke Shih <pkshih@realtek.com> # RTL8723DE and RTL8822CE
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/913f1747-38fc-4409-85a4-57bb9cee506b@gmail.com
|
|
When removing kernel modules by:
rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core
Driver uses skb_queue_purge() to purge TX skb, but not report tx status
causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue()
to correct this.
Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing
between TX work and purge TX queue, flush and destroy TX work in advance.
wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local
choice (Reason: 3=DEAUTH_LEAVING)
------------[ cut here ]------------
Have pending ack frames!
WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691
ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
CPU: 3 PID: 9232 Comm: rmmod Tainted: G C
6.10.1-200.fc40.aarch64 #1
Hardware name: pine64 Pine64 PinePhone Braveheart
(1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
sp : ffff80008c1b37b0
x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000
x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0
x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff
x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000
x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000
x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964
x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0
x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000
Call trace:
ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
idr_for_each+0x74/0x110
ieee80211_free_hw+0x44/0xe8 [mac80211]
rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]
sdio_bus_remove+0x44/0x180
device_remove+0x54/0x90
device_release_driver_internal+0x1d4/0x238
driver_detach+0x54/0xc0
bus_remove_driver+0x78/0x108
driver_unregister+0x38/0x78
sdio_unregister_driver+0x2c/0x40
rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]
__do_sys_delete_module.isra.0+0x190/0x338
__arm64_sys_delete_module+0x1c/0x30
invoke_syscall+0x74/0x100
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x3c/0x158
el0t_64_sync_handler+0x120/0x138
el0t_64_sync+0x194/0x198
---[ end trace 0000000000000000 ]---
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Closes: https://lore.kernel.org/linux-wireless/CALeDE9OAa56KMzgknaCD3quOgYuEHFx9_hcT=OFgmMAb+8MPyA@mail.gmail.com/
Tested-by: Ping-Ke Shih <pkshih@realtek.com> # 8723DU
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240822014255.10211-2-pkshih@realtek.com
|
|
Enable USB RX aggregation when there is at least 1 Mbps RX or TX
traffic, otherwise disable it.
USB RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. Before: 28 Mbps, after: 231 Mbps.
It also improves the RX speed of RTL8822CU on some x86_64 systems.
Before: ~200 Mbps, after: ~300 Mbps.
The official drivers for these chips use the same logic for SDIO, but
for some reason the SDIO driver in rtw88 always enables RX aggregation,
so this patch only toggles aggregation for USB devices.
RTL8703B is likely not found in USB devices, and RTL8723DU doesn't like
aggregation.
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/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com
|
|
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
|
|
Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes
with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth
combo card. The error he observed is identical to what has been fixed
in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST
bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem.
Lukas found that disabling or limiting RX aggregation works around the
problem for some time (but does not fully fix it). In the following
discussion a few key topics have been discussed which have an impact on
this problem:
- The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller
which prevents DMA transfers. Instead all transfers need to go through
the controller SRAM which limits transfers to 1536 bytes
- rtw88 chips don't split incoming (RX) packets, so if a big packet is
received this is forwarded to the host in it's original form
- rtw88 chips can do RX aggregation, meaning more multiple incoming
packets can be pulled by the host from the card with one MMC/SDIO
transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH
register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will
be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation
and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)
Use multiple consecutive reads in rtw_sdio_read_port() and limit the
number of bytes which are copied by the host from the card in one
MMC/SDIO transfer. This allows receiving a buffer that's larger than
the hosts max_req_size (number of bytes which can be transferred in
one MMC/SDIO transfer). As a result of this the skb_over_panic error
is gone as the rtw88 driver is now able to receive more than 1536 bytes
from the card (either because the incoming packet is larger than that
or because multiple packets have been aggregated).
In case of an receive errors (-EILSEQ has been observed by Lukas) we
need to drain the remaining data from the card's buffer, otherwise the
card will return corrupt data for the next rtw_sdio_read_port() call.
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Reported-by: Lukas F. Hartmann <lukas@mntre.com>
Closes: https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/
Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Lukas F. Hartmann <lukas@mntre.com>
Reported-by: Lukas F. Hartmann <lukas@mntre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Lukas F. Hartmann <lukas@mntre.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231120115726.1569323-1-martin.blumenstingl@googlemail.com
|
|
There are a number of upcoming things in both the stack and
drivers that would otherwise conflict, so merge wireless to
wireless-next to be able to avoid those conflicts.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
rtw_sdio_rx_isr() is responsible for receiving data from the wifi chip
and is called from the SDIO interrupt handler when the interrupt status
register (HISR) has the RX_REQUEST bit set. After the first batch of
data has been processed by the driver the wifi chip may have more data
ready to be read, which is managed by a loop in rtw_sdio_rx_isr().
It turns out that there are cases where the RX buffer length (from the
REG_SDIO_RX0_REQ_LEN register) does not match the data we receive. The
following two cases were observed with a RTL8723DS card:
- RX length is smaller than the total packet length including overhead
and actual data bytes (whose length is part of the buffer we read from
the wifi chip and is stored in rtw_rx_pkt_stat.pkt_len). This can
result in errors like:
skbuff: skb_over_panic: text:ffff8000011924ac len:3341 put:3341
(one case observed was: RX buffer length = 1536 bytes but
rtw_rx_pkt_stat.pkt_len = 1546 bytes, this is not valid as it means
we need to read beyond the end of the buffer)
- RX length looks valid but rtw_rx_pkt_stat.pkt_len is zero
Check if the RX_REQUEST is set in the HISR register for each iteration
inside rtw_sdio_rx_isr(). This mimics what the RTL8723DS vendor driver
does and makes the driver only read more data if the RX_REQUEST bit is
set (which seems to be a way for the card's hardware or firmware to
tell the host that data is ready to be processed).
For RTW_WCPU_11AC chips this check is not needed. The RTL8822BS vendor
driver for example states that this check is unnecessary (but still uses
it) and the RTL8822CS drops this check entirely.
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230522202425.1827005-2-martin.blumenstingl@googlemail.com
|
|
The Allwinner sunxi-mmc controller cannot handle word (16 bit)
transfers. So and sdio_{read,write}w fails with messages like the
following example using an RTL8822BS (but the same problems were also
observed with RTL8822CS and RTL8723DS chips):
rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13
sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2
sunxi-mmc 4021000.mmc: map DMA failed
rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22
Use two consecutive single byte accesses for word operations instead. It
turns out that upon closer inspection this is also what the vendor
driver does, even though it does have support for sdio_{read,write}w. So
we can conclude that the rtw88 chips do support word access but only on
SDIO controllers that also support it. Since there's no way to detect if
the controller supports word access or not the rtw88 sdio driver
switches to the easiest approach: avoiding word access.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/
Reported-by: Rudi Heitbaum <rudi@heitbaum.com>
Link: https://github.com/LibreELEC/LibreELEC.tv/pull/7837#issue-1708469467
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230515195043.572375-1-martin.blumenstingl@googlemail.com
|
|
Add a sub-driver for SDIO based chipsets which implements the following
functionality:
- register accessors for 8, 16 and 32 bits for all states of the card
(including usage of 4x 8 bit access for one 32 bit buffer if the card
is not fully powered on yet - or if it's fully powered on then 1x 32
bit access is used)
- checking whether there's space in the TX FIFO queue to transmit data
- transfers from the host to the device for actual network traffic,
reserved pages (for firmware download) and H2C (host-to-card)
transfers
- receiving data from the device
- deep power saving state
The transmit path is optimized so DMA-capable SDIO host controllers can
directly use the buffers provided because the buffer's physical
addresses are 8 byte aligned.
The receive path is prepared to support RX aggregation where the
chipset combines multiple MAC frames into one bigger buffer to reduce
SDIO transfer overhead.
Co-developed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-3-martin.blumenstingl@googlemail.com
|
