[PATCH rtw] wifi: rtw89: hw_scan: Don't let the operating channel be last

[PATCH rtw] wifi: rtw89: hw_scan: Don't let the operating channel be last

[Bitterblue Smith]

Scanning can be offloaded to the firmware. To that end, the driver
prepares a list of channels to scan, including periodic visits back to
the operating channel, and sends the list to the firmware.

When the channel list is too long to fit in a single H2C message, the
driver splits the list, sends the first part, and tells the firmware to
scan. When the scan is complete, the driver sends the next part of the
list and tells the firmware to scan.

When the last channel that fit in the H2C message is the operating
channel something seems to go wrong in the firmware. It will
acknowledge receiving the list of channels but apparently it will not
do anything more. The AP can't be pinged anymore. The driver still
receives beacons, though.

One way to avoid this is to split the list of channels before the
operating channel.

Affected devices:

* RTL8851BU with firmware 0.29.41.3
* RTL8832BU with firmware 0.29.29.8
* RTL8852BU with firmware 0.29.29.8

https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
---
I didn't think a workaround would be needed in the kernel but 6.18
will be out soon and people still have this problem.
---
 drivers/net/wireless/realtek/rtw89/fw.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
index 96f0463e66d6..c35317abc7f5 100644
--- a/drivers/net/wireless/realtek/rtw89/fw.c
+++ b/drivers/net/wireless/realtek/rtw89/fw.c
@@ -7709,6 +7709,13 @@ int rtw89_hw_scan_add_chan_list_ax(struct rtw89_dev *rtwdev,
 	INIT_LIST_HEAD(&list);
 
 	list_for_each_entry_safe(ch_info, tmp, &scan_info->chan_list, list) {
+		/* The operating channel (tx_null == true) should
+		 * not be last in the list, to avoid breaking
+		 * RTL8851BU and RTL8832BU.
+		 */
+		if (list_len + 1 == RTW89_SCAN_LIST_LIMIT_AX && ch_info->tx_null)
+			break;
+
 		list_move_tail(&ch_info->list, &list);
 
 		list_len++;
-- 
2.51.1

RE: [PATCH rtw] wifi: rtw89: hw_scan: Don't let the operating channel be last

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Scanning can be offloaded to the firmware. To that end, the driver
> prepares a list of channels to scan, including periodic visits back to
> the operating channel, and sends the list to the firmware.
> 
> When the channel list is too long to fit in a single H2C message, the
> driver splits the list, sends the first part, and tells the firmware to
> scan. When the scan is complete, the driver sends the next part of the
> list and tells the firmware to scan.
> 
> When the last channel that fit in the H2C message is the operating
> channel something seems to go wrong in the firmware. It will
> acknowledge receiving the list of channels but apparently it will not
> do anything more. The AP can't be pinged anymore. The driver still
> receives beacons, though.
> 
> One way to avoid this is to split the list of channels before the
> operating channel.
> 
> Affected devices:
> 
> * RTL8851BU with firmware 0.29.41.3
> * RTL8832BU with firmware 0.29.29.8
> * RTL8852BU with firmware 0.29.29.8

We don't see this problem with the same firmware on RTL8852BE and RTL8852CE,
and I'd spend some time to check if this impact scan time. Or could you share?

Otherwise, it looks good to me, so give my ACK in advance

Acked-by: Ping-Ke Shih <pkshih@realtek.com>


> 
> https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> ---
> I didn't think a workaround would be needed in the kernel but 6.18
> will be out soon and people still have this problem.
> ---
>  drivers/net/wireless/realtek/rtw89/fw.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
> index 96f0463e66d6..c35317abc7f5 100644
> --- a/drivers/net/wireless/realtek/rtw89/fw.c
> +++ b/drivers/net/wireless/realtek/rtw89/fw.c
> @@ -7709,6 +7709,13 @@ int rtw89_hw_scan_add_chan_list_ax(struct rtw89_dev *rtwdev,
>         INIT_LIST_HEAD(&list);
> 
>         list_for_each_entry_safe(ch_info, tmp, &scan_info->chan_list, list) {
> +               /* The operating channel (tx_null == true) should
> +                * not be last in the list, to avoid breaking
> +                * RTL8851BU and RTL8832BU.
> +                */
> +               if (list_len + 1 == RTW89_SCAN_LIST_LIMIT_AX && ch_info->tx_null)
> +                       break;
> +
>                 list_move_tail(&ch_info->list, &list);
> 
>                 list_len++;
> --
> 2.51.1

Re: [PATCH rtw] wifi: rtw89: hw_scan: Don't let the operating channel be last

[Bitterblue Smith]

On 18/11/2025 04:17, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> Scanning can be offloaded to the firmware. To that end, the driver
>> prepares a list of channels to scan, including periodic visits back to
>> the operating channel, and sends the list to the firmware.
>>
>> When the channel list is too long to fit in a single H2C message, the
>> driver splits the list, sends the first part, and tells the firmware to
>> scan. When the scan is complete, the driver sends the next part of the
>> list and tells the firmware to scan.
>>
>> When the last channel that fit in the H2C message is the operating
>> channel something seems to go wrong in the firmware. It will
>> acknowledge receiving the list of channels but apparently it will not
>> do anything more. The AP can't be pinged anymore. The driver still
>> receives beacons, though.
>>
>> One way to avoid this is to split the list of channels before the
>> operating channel.
>>
>> Affected devices:
>>
>> * RTL8851BU with firmware 0.29.41.3
>> * RTL8832BU with firmware 0.29.29.8
>> * RTL8852BU with firmware 0.29.29.8

I made a mistake here. It should be:

RTL8851BU
RTL8832BU
RTL8852BE

The report about the RTL8852BE came from a user who doesn't have the
card anymore, unfortunately.

Actually, since I wrote that commit message I acquired RTL8851BE and
I can reproduce the problem with that.

> 
> We don't see this problem with the same firmware on RTL8852BE and RTL8852CE,
> and I'd spend some time to check if this impact scan time. Or could you share?
> 

I tested with RTL8832AU and RTL8832CU, which work fine even without
this patch. The scans take about the same time with and without this
patch.

RTL8832CU without the patch:

[2025-11-18 23:17:37.481439]: wlp3s0f3u4 (phy #17): scan started
[2025-11-18 23:17:43.965465]: wlp3s0f3u4 (phy #17): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""
[2025-11-18 23:29:22.624860]: wlp3s0f3u4 (phy #17): scan started
[2025-11-18 23:29:29.129461]: wlp3s0f3u4 (phy #17): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""
[2025-11-18 23:31:19.535787]: wlp3s0f3u4 (phy #17): scan started
[2025-11-18 23:31:26.054462]: wlp3s0f3u4 (phy #17): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""

6.48
6.50
6.51 seconds

RTL8832AU without the patch:

[2025-11-18 23:05:47.163418]: wlp3s0f3u4 (phy #15): scan started
[2025-11-18 23:05:53.690694]: wlp3s0f3u4 (phy #15): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825, ""
[2025-11-18 23:09:37.668990]: wlp3s0f3u4 (phy #15): scan started
[2025-11-18 23:09:44.178517]: wlp3s0f3u4 (phy #15): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825, ""
[2025-11-18 23:10:42.260908]: wlp3s0f3u4 (phy #15): scan started
[2025-11-18 23:10:48.810650]: wlp3s0f3u4 (phy #15): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825, ""

6.52
6.50
6.54 seconds

RTL8832CU with the patch:

[2025-11-18 23:38:50.296919]: wlp3s0f3u4 (phy #18): scan started
[2025-11-18 23:38:56.822416]: wlp3s0f3u4 (phy #18): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""
[2025-11-18 23:41:21.157569]: wlp3s0f3u4 (phy #18): scan started
[2025-11-18 23:41:27.675412]: wlp3s0f3u4 (phy #18): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""
[2025-11-18 23:45:05.087628]: wlp3s0f3u4 (phy #18): scan started
[2025-11-18 23:45:11.615630]: wlp3s0f3u4 (phy #18): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""

6.52
6.51
6.52 seconds

RTL8832AU with the patch:

[2025-11-19 00:03:04.643389]: wlp3s0f3u4 (phy #20): scan started
[2025-11-19 00:03:11.183441]: wlp3s0f3u4 (phy #20): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825, ""
[2025-11-19 00:08:56.944636]: wlp3s0f3u4 (phy #20): scan started
[2025-11-19 00:09:03.504852]: wlp3s0f3u4 (phy #20): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825, ""
[2025-11-19 00:10:10.207836]: wlp3s0f3u4 (phy #20): scan started
[2025-11-19 00:10:16.766985]: wlp3s0f3u4 (phy #20): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825, ""

6.54
6.56
6.55 seconds

> Otherwise, it looks good to me, so give my ACK in advance
> 
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> 
> 
>>
>> https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>> ---
>> I didn't think a workaround would be needed in the kernel but 6.18
>> will be out soon and people still have this problem.
>> ---
>>  drivers/net/wireless/realtek/rtw89/fw.c | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
>> index 96f0463e66d6..c35317abc7f5 100644
>> --- a/drivers/net/wireless/realtek/rtw89/fw.c
>> +++ b/drivers/net/wireless/realtek/rtw89/fw.c
>> @@ -7709,6 +7709,13 @@ int rtw89_hw_scan_add_chan_list_ax(struct rtw89_dev *rtwdev,
>>         INIT_LIST_HEAD(&list);
>>
>>         list_for_each_entry_safe(ch_info, tmp, &scan_info->chan_list, list) {
>> +               /* The operating channel (tx_null == true) should
>> +                * not be last in the list, to avoid breaking
>> +                * RTL8851BU and RTL8832BU.
>> +                */
>> +               if (list_len + 1 == RTW89_SCAN_LIST_LIMIT_AX && ch_info->tx_null)
>> +                       break;
>> +
>>                 list_move_tail(&ch_info->list, &list);
>>
>>                 list_len++;
>> --
>> 2.51.1
> 

RE: [PATCH rtw] wifi: rtw89: hw_scan: Don't let the operating channel be last

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 18/11/2025 04:17, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> Scanning can be offloaded to the firmware. To that end, the driver
> >> prepares a list of channels to scan, including periodic visits back to
> >> the operating channel, and sends the list to the firmware.
> >>
> >> When the channel list is too long to fit in a single H2C message, the
> >> driver splits the list, sends the first part, and tells the firmware to
> >> scan. When the scan is complete, the driver sends the next part of the
> >> list and tells the firmware to scan.
> >>
> >> When the last channel that fit in the H2C message is the operating
> >> channel something seems to go wrong in the firmware. It will
> >> acknowledge receiving the list of channels but apparently it will not
> >> do anything more. The AP can't be pinged anymore. The driver still
> >> receives beacons, though.
> >>
> >> One way to avoid this is to split the list of channels before the
> >> operating channel.
> >>
> >> Affected devices:
> >>
> >> * RTL8851BU with firmware 0.29.41.3
> >> * RTL8832BU with firmware 0.29.29.8
> >> * RTL8852BU with firmware 0.29.29.8
> 
> I made a mistake here. It should be:
> 
> RTL8851BU
> RTL8832BU
> RTL8852BE

I'll re-spin commit message with this information.

> 
> The report about the RTL8852BE came from a user who doesn't have the
> card anymore, unfortunately.
> 
> Actually, since I wrote that commit message I acquired RTL8851BE and
> I can reproduce the problem with that.
> 

I don't know why our site can't reproduce this issue. Since this patch
can help your and no obvious increasing scan time, I will take this
patch and send pull-request to 6.18-rc6.

Re: [PATCH rtw] wifi: rtw89: hw_scan: Don't let the operating channel be last

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:

> Scanning can be offloaded to the firmware. To that end, the driver
> prepares a list of channels to scan, including periodic visits back to
> the operating channel, and sends the list to the firmware.
> 
> When the channel list is too long to fit in a single H2C message, the
> driver splits the list, sends the first part, and tells the firmware to
> scan. When the scan is complete, the driver sends the next part of the
> list and tells the firmware to scan.
> 
> When the last channel that fit in the H2C message is the operating
> channel something seems to go wrong in the firmware. It will
> acknowledge receiving the list of channels but apparently it will not
> do anything more. The AP can't be pinged anymore. The driver still
> receives beacons, though.
> 
> One way to avoid this is to split the list of channels before the
> operating channel.
> 
> Affected devices:
> 
> * RTL8851BU with firmware 0.29.41.3
> * RTL8832BU with firmware 0.29.29.8
> * RTL8852BU with firmware 0.29.29.8
> 
> https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>

1 patch(es) applied to rtw branch of rtw.git, thanks.

e837b9091b27 wifi: rtw89: hw_scan: Don't let the operating channel be last

---
https://github.com/pkshih/rtw.git