Re: [PATCH rtw-next v2 5/5] wifi: rtl8xxxu: Enable 40 MHz width by default

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 23/04/2026 16:39, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 11/20/25 15:13, Bitterblue Smith wrote:
>> 40 MHz support is hidden behind the ht40_2g module parameter with
>> this comment:
>>
>> /*
>>  * Some APs will negotiate HT20_40 in a noisy environment leading
>>  * to miserable performance. Rather than defaulting to this, only
>>  * enable it if explicitly requested at module load time.
>>  */
> 
> FYI: this patch causes a regression that was reported to bugzilla
> (reporter CCed here): https://bugzilla.kernel.org/show_bug.cgi?id=221394
> 

Hi Thorsten,

Thanks for letting us know. I replied at the Bugzilla.

> """
> Since kernel 6.19.0, the rtl8xxxu driver fails to maintain a connection
> with the Realtek RTL8188FTV (0bda:f179) USB Wi-Fi adapter. The device
> gets stuck "configuring interface" and eventually times out, effectively
> disappearing from the network manager.
> 
> Regression Window:
> Works perfectly on: 6.12.x (LTS) and 6.18.x (LTS and non LTS).
> Broken on: 6.19.x, up through 7.0.0.
> 
> Notes:
> - The device remains visible on the USB bus (lsusb still shows 0bda:f179).
> - The wlan0 interface is created.
> - NetworkManager attempts to associate, but authentication times out.
> - Disabling USB autosuspend (usbcore.autosuspend=-1) does not resolve
> the issue.
> 
> Hardware:
> Bus 001 Device 002: ID 0bda:f179 Realtek Semiconductor Corp. RTL8188FTV
> 802.11b/g/n 1T1R 2.4G WLAN Adapter
> """
> 
> Then later:
> 
> """
> I confirmed that the Commit dbf9b7b "wifi: rtl8xxxu: Enable 40 MHz width
> by default" is the cause of the regression.
> 
> I tested passing cfg80211_disable_40mhz_24ghz=1 to the cfg80211 module
> on 6.19.x and 7.0, and the adapter works perfectly again.
> 
> In Windows, forcing the adapter to 20_40MHz causes it to be unable to
> connect to any AP, and it only works in 20MHz mode. In Linux 6.19+, it
> gets stuck configuring the interface and crashes. So this is most
> probably a hardware issue.
> """
> 
> Ciao, Thorsten
> 
>> This parameter was added in commit 26f1fad29ad9 ("New driver:
>> rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU
>> and the RTL8192CU family. It's entirely possible the miserable
>> performance was due to mistakes in the channel switching function,
>> which were fixed in a previous patch.
>>
>> Delete the ht40_2g module parameter. If someone still needs to
>> disable 40 MHz support, cfg80211 has the module parameter
>> cfg80211_disable_40mhz_24ghz. That works too.
>>
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
>> ---
>> v2:
>>  - Add Reviewed-by.
>> ---
>>  drivers/net/wireless/realtek/rtl8xxxu/core.c | 19 ++++---------------
>>  1 file changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
>> index a18f73aea837..c06ad064f37c 100644
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
>> @@ -20,7 +20,6 @@
>>  #define DRIVER_NAME "rtl8xxxu"
>>  
>>  int rtl8xxxu_debug;
>> -static bool rtl8xxxu_ht40_2g;
>>  static bool rtl8xxxu_dma_aggregation;
>>  static int rtl8xxxu_dma_agg_timeout = -1;
>>  static int rtl8xxxu_dma_agg_pages = -1;
>> @@ -45,8 +44,6 @@ MODULE_FIRMWARE("rtlwifi/rtl8192fufw.bin");
>>  
>>  module_param_named(debug, rtl8xxxu_debug, int, 0600);
>>  MODULE_PARM_DESC(debug, "Set debug mask");
>> -module_param_named(ht40_2g, rtl8xxxu_ht40_2g, bool, 0600);
>> -MODULE_PARM_DESC(ht40_2g, "Enable HT40 support on the 2.4GHz band");
>>  module_param_named(dma_aggregation, rtl8xxxu_dma_aggregation, bool, 0600);
>>  MODULE_PARM_DESC(dma_aggregation, "Enable DMA packet aggregation");
>>  module_param_named(dma_agg_timeout, rtl8xxxu_dma_agg_timeout, int, 0600);
>> @@ -4896,8 +4893,7 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
>>  				sgi = 1;
>>  
>>  			highest_rate = fls(ramask) - 1;
>> -			if (rtl8xxxu_ht40_2g &&
>> -			    (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
>> +			if (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
>>  				bw = RATE_INFO_BW_40;
>>  			else
>>  				bw = RATE_INFO_BW_20;
>> @@ -7851,7 +7847,8 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
>>  	sband->ht_cap.ht_supported = true;
>>  	sband->ht_cap.ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
>>  	sband->ht_cap.ampdu_density = IEEE80211_HT_MPDU_DENSITY_16;
>> -	sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40;
>> +	sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40 |
>> +			    IEEE80211_HT_CAP_SUP_WIDTH_20_40;
>>  	memset(&sband->ht_cap.mcs, 0, sizeof(sband->ht_cap.mcs));
>>  	sband->ht_cap.mcs.rx_mask[0] = 0xff;
>>  	sband->ht_cap.mcs.rx_mask[4] = 0x01;
>> @@ -7860,15 +7857,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
>>  		sband->ht_cap.cap |= IEEE80211_HT_CAP_SGI_40;
>>  	}
>>  	sband->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
>> -	/*
>> -	 * Some APs will negotiate HT20_40 in a noisy environment leading
>> -	 * to miserable performance. Rather than defaulting to this, only
>> -	 * enable it if explicitly requested at module load time.
>> -	 */
>> -	if (rtl8xxxu_ht40_2g) {
>> -		dev_info(&udev->dev, "Enabling HT_20_40 on the 2.4GHz band\n");
>> -		sband->ht_cap.cap |= IEEE80211_HT_CAP_SUP_WIDTH_20_40;
>> -	}
>> +
>>  	hw->wiphy->bands[NL80211_BAND_2GHZ] = sband;
>>  
>>  	hw->wiphy->rts_threshold = 2347;
> 
> #regzbot introduced: dbf9b7b
> #regzbot title: wifi: rtl8xxxu: 40 MHz mode breaks things (just like in
> Windows)
> #regzbot dup: https://bugzilla.kernel.org/show_bug.cgi?id=221394