[PATCH rtw-next v2 0/5] wifi: rtl8xxxu: 40 MHz fixes

[PATCH rtw-next v2 0/5] wifi: rtl8xxxu: 40 MHz fixes

[Bitterblue Smith]

All the chips should work with 40 MHz width now.

v2:
 - Patch 4/5:
   - Compare rxmcs with the legacy OFDM rates for better clarity.

Bitterblue Smith (5):
  wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU
  wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz width
  wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BU
  wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FU
  wifi: rtl8xxxu: Enable 40 MHz width by default

 drivers/net/wireless/realtek/rtl8xxxu/core.c | 52 ++++++++++++--------
 1 file changed, 31 insertions(+), 21 deletions(-)

-- 
2.51.1

[PATCH rtw-next v2 1/5] wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU

[Bitterblue Smith]

Flip the response rate subchannel. It was backwards, causing low
speeds when using 40 MHz channel width. "iw dev ... station dump"
showed a low RX rate, 11M or less.

Also fix the channel width field of RF6052_REG_MODE_AG.

Tested only with RTL8192CU, but these settings are identical for
RTL8723AU.

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 | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index d82cb7714314..be8ee6c30034 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -1252,7 +1252,7 @@ void rtl8xxxu_gen1_config_channel(struct ieee80211_hw *hw)
 		opmode &= ~BW_OPMODE_20MHZ;
 		rtl8xxxu_write8(priv, REG_BW_OPMODE, opmode);
 		rsr &= ~RSR_RSC_BANDWIDTH_40M;
-		if (sec_ch_above)
+		if (!sec_ch_above)
 			rsr |= RSR_RSC_UPPER_SUB_CHANNEL;
 		else
 			rsr |= RSR_RSC_LOWER_SUB_CHANNEL;
@@ -1321,9 +1321,8 @@ void rtl8xxxu_gen1_config_channel(struct ieee80211_hw *hw)
 
 	for (i = RF_A; i < priv->rf_paths; i++) {
 		val32 = rtl8xxxu_read_rfreg(priv, i, RF6052_REG_MODE_AG);
-		if (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40)
-			val32 &= ~MODE_AG_CHANNEL_20MHZ;
-		else
+		val32 &= ~MODE_AG_BW_MASK;
+		if (hw->conf.chandef.width != NL80211_CHAN_WIDTH_40)
 			val32 |= MODE_AG_CHANNEL_20MHZ;
 		rtl8xxxu_write_rfreg(priv, i, RF6052_REG_MODE_AG, val32);
 	}
-- 
2.51.1

Re: [PATCH rtw-next v2 1/5] wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:

> Flip the response rate subchannel. It was backwards, causing low
> speeds when using 40 MHz channel width. "iw dev ... station dump"
> showed a low RX rate, 11M or less.
> 
> Also fix the channel width field of RF6052_REG_MODE_AG.
> 
> Tested only with RTL8192CU, but these settings are identical for
> RTL8723AU.
> 
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>

5 patch(es) applied to rtw-next branch of rtw.git, thanks.

5511ba3de434 wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU
bdb4c850c368 wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz width
fc44314a377a wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BU
41a21d0ff3a0 wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FU
dbf9b7bb0edf wifi: rtl8xxxu: Enable 40 MHz width by default

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

[PATCH rtw-next v2 2/5] wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz width

[Bitterblue Smith]

Set the required fields in the TX descriptor to allow these chips to
transmit with 40 MHz channel width when the access point supports it.

Tested only with RTL8192CU, but these settings are identical for
RTL8723AU.

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 | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index be8ee6c30034..7700e4074dc3 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -5221,9 +5221,19 @@ rtl8xxxu_fill_txdesc_v1(struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
 		tx_desc->txdw5 |= cpu_to_le32(TXDESC32_RETRY_LIMIT_ENABLE);
 	}
 
-	if (ieee80211_is_data_qos(hdr->frame_control))
+	if (ieee80211_is_data_qos(hdr->frame_control)) {
 		tx_desc->txdw4 |= cpu_to_le32(TXDESC32_QOS);
 
+		if (conf_is_ht40(&hw->conf)) {
+			tx_desc->txdw4 |= cpu_to_le32(TXDESC_DATA_BW);
+
+			if (conf_is_ht40_minus(&hw->conf))
+				tx_desc->txdw4 |= cpu_to_le32(TXDESC_PRIME_CH_OFF_UPPER);
+			else
+				tx_desc->txdw4 |= cpu_to_le32(TXDESC_PRIME_CH_OFF_LOWER);
+		}
+	}
+
 	if (short_preamble)
 		tx_desc->txdw4 |= cpu_to_le32(TXDESC32_SHORT_PREAMBLE);
 
-- 
2.51.1

[PATCH rtw-next v2 3/5] wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BU

[Bitterblue Smith]

rtl8xxxu_gen2_config_channel() was missing the subchannel setting.
This function is used by RTL8192EU and RTL8723BU.

This change seems to make no difference in my testing on channel 13
with either chip.

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 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index 7700e4074dc3..739456640ca8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -1373,9 +1373,11 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw)
 		    hw->conf.chandef.chan->center_freq) {
 			sec_ch_above = 1;
 			channel += 2;
+			subchannel = 2;
 		} else {
 			sec_ch_above = 0;
 			channel -= 2;
+			subchannel = 1;
 		}
 
 		val32 = rtl8xxxu_read32(priv, REG_FPGA0_RF_MODE);
-- 
2.51.1

[PATCH rtw-next v2 4/5] wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FU

[Bitterblue Smith]

The other chips report the RX channel width in the RX descriptor,
but this one doesn't.

Get the RX channel width from the PHY status.

Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
---
v2:
 - Compare rxmcs with the legacy OFDM rates for better clarity.
---
 drivers/net/wireless/realtek/rtl8xxxu/core.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index 739456640ca8..a18f73aea837 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -5701,7 +5701,7 @@ static void jaguar2_rx_parse_phystats_type1(struct rtl8xxxu_priv *priv,
 			 !rtl8xxxu_is_sta_sta(priv) &&
 			 (rtl8xxxu_is_packet_match_bssid(priv, hdr, 0) ||
 			  rtl8xxxu_is_packet_match_bssid(priv, hdr, 1));
-	u8 pwdb_max = 0;
+	u8 pwdb_max = 0, rxsc;
 	int rx_path;
 
 	if (parse_cfo) {
@@ -5716,6 +5716,16 @@ static void jaguar2_rx_parse_phystats_type1(struct rtl8xxxu_priv *priv,
 		pwdb_max = max(pwdb_max, phy_stats1->pwdb[rx_path]);
 
 	rx_status->signal = pwdb_max - 110;
+
+	if (rxmcs >= DESC_RATE_6M && rxmcs <= DESC_RATE_54M)
+		rxsc = phy_stats1->l_rxsc;
+	else
+		rxsc = phy_stats1->ht_rxsc;
+
+	if (phy_stats1->rf_mode == 0 || rxsc == 1 || rxsc == 2)
+		rx_status->bw = RATE_INFO_BW_20;
+	else
+		rx_status->bw = RATE_INFO_BW_40;
 }
 
 static void jaguar2_rx_parse_phystats_type2(struct rtl8xxxu_priv *priv,
-- 
2.51.1

RE: [PATCH rtw-next v2 4/5] wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FU

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> The other chips report the RX channel width in the RX descriptor,
> but this one doesn't.
> 
> Get the RX channel width from the PHY status.
> 
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>

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

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

[Bitterblue Smith]

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.
 */

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;
-- 
2.51.1

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

[Linux regression tracking (Thorsten Leemhuis)]

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

"""
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

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

[Bitterblue Smith]

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