[PATCH AUTOSEL 6.18-6.12] wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU

[PATCH AUTOSEL 6.18-6.12] wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU

[Sasha Levin]

From: Bitterblue Smith <rtl8821cerfe2@gmail.com>

[ Upstream commit 5511ba3de434892e5ef3594d6eabbd12b1629356 ]

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>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1f46571d-855b-43e1-8bfc-abacceb96043@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## COMPREHENSIVE ANALYSIS

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** "wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU,
RTL8723AU"

- Contains "Fix" keyword indicating a bug fix
- Describes specific affected hardware: RTL8192CU, RTL8723AU USB WiFi
  adapters
- Explains user-visible symptom: "low speeds when using 40 MHz channel
  width"
- Provides diagnostic evidence: "`iw dev ... station dump` showed a low
  RX rate, 11M or less"
- **No** "Cc: stable@vger.kernel.org" tag
- **No** "Fixes:" tag pointing to the original buggy commit
- **Has** "Reviewed-by: Ping-Ke Shih" (Realtek's kernel maintainer)
- **Has** "Tested only with RTL8192CU" - real-world testing performed

### 2. CODE CHANGE ANALYSIS

**Two distinct bugs are fixed:**

**Bug #1: RSR (Response Rate Set) subchannel configuration (lines
1255-1258):**
```c
// BEFORE (buggy):
if (sec_ch_above)
    rsr |= RSR_RSC_UPPER_SUB_CHANNEL;
else
    rsr |= RSR_RSC_LOWER_SUB_CHANNEL;

// AFTER (fixed):
if (!sec_ch_above)
    rsr |= RSR_RSC_UPPER_SUB_CHANNEL;
else
    rsr |= RSR_RSC_LOWER_SUB_CHANNEL;
```
The logic was inverted - when secondary channel is above, LOWER should
be set, not UPPER. Comparison with RTL8188E driver (8188e.c:462-465)
confirms the fix matches the correct pattern.

**Bug #2: RF6052_REG_MODE_AG bandwidth configuration (lines
1322-1328):**
```c
// BEFORE (buggy):
if (hw->conf.chandef.width == NL80211_CHAN_WIDTH_40)
    val32 &= ~MODE_AG_CHANNEL_20MHZ;
else
    val32 |= MODE_AG_CHANNEL_20MHZ;

// AFTER (fixed):
val32 &= ~MODE_AG_BW_MASK;  // Clear both bits 10 and 11
if (hw->conf.chandef.width != NL80211_CHAN_WIDTH_40)
    val32 |= MODE_AG_CHANNEL_20MHZ;
```
Two issues: (1) Only cleared bit 10, not the full bandwidth mask (bits
10-11), and (2) the logic flow was awkward - proper pattern is to clear
mask first, then set appropriate bit only when needed.

The gen2 driver (`rtl8xxxu_gen2_config_channel` at line 1446) already
uses `MODE_AG_BW_MASK` correctly, confirming this is the right approach.

### 3. CLASSIFICATION

- **Bug Type:** Logic error causing severe performance degradation
- **NOT a feature:** No new functionality added
- **NOT a quirk/workaround:** This is fixing incorrect code logic
- **Hardware affected:** RTL8192CU, RTL8723AU (older but still commonly
  used USB WiFi adapters)

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** ~8 lines modified
- **Files touched:** 1 file (core.c)
- **Complexity:** LOW - simple logic inversions and proper mask usage
- **Scope:** Confined to `rtl8xxxu_gen1_config_channel()` function, only
  affects 40MHz mode
- **Risk of regression:** LOW - brings gen1 config in line with gen2 and
  8188e implementations
- **Dependencies:** `MODE_AG_BW_MASK` exists since 2016 (commit
  c3f9506f2374), present in all stable kernels

### 5. USER IMPACT

- **Affected users:** Anyone using RTL8192CU or RTL8723AU USB WiFi
  adapters with 40MHz channels
- **Severity:** MODERATE-HIGH - WiFi functional but severely degraded
  speeds (capped at 11M vs expected 40MHz HT speeds which could be
  150-300Mbps)
- **Impact scope:** These are common, inexpensive USB WiFi adapters;
  many users in production environments
- **Visibility:** Users would notice unusably slow WiFi and might
  mistakenly blame their router or network

### 6. STABILITY INDICATORS

- Reviewed by Realtek's Linux kernel maintainer (Ping-Ke Shih)
- Tested on actual hardware (RTL8192CU)
- Consistent with how other chip variants in the same driver family
  handle this
- Small, surgical changes with clear correctness rationale

### 7. DEPENDENCY CHECK

- `MODE_AG_BW_MASK` macro is defined in regs.h since 2016
- No other commits needed for this fix to work
- The affected function `rtl8xxxu_gen1_config_channel()` exists in all
  stable kernels that have the rtl8xxxu driver

### VERDICT

**Positive factors:**
- Fixes a real, user-visible performance bug (severely degraded WiFi
  speeds)
- Small, contained changes (8 lines)
- Low regression risk - aligns with established patterns in related code
- Reviewed and tested
- No dependencies on other commits
- Affects real hardware that users own

**Negative factors:**
- No explicit "Cc: stable@" tag from maintainer
- No "Fixes:" tag to trace original bug introduction

**Risk vs Benefit:**
- Benefit: Restores proper HT40 performance for RTL8192CU/RTL8723AU
  users
- Risk: Very low - logic corrections that match other implementations in
  the same driver

This is a clear bug fix for user-visible performance degradation. The
changes are minimal, well-understood, properly reviewed, and consistent
with how other chip variants in the same driver family handle channel
configuration. The lack of explicit stable tags appears to be an
oversight rather than an intentional exclusion. Users with these common
USB WiFi adapters would benefit significantly from this fix.

**YES**

 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 3ded5952729fc..d2d3bbac2861f 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.0

[PATCH AUTOSEL 6.18-6.12] wifi: cfg80211: use cfg80211_leave() in iftype change

[Sasha Levin]

From: Johannes Berg <johannes.berg@intel.com>

[ Upstream commit 7a27b73943a70ee226fa125327101fb18e94701d ]

When changing the interface type, all activity on the interface has
to be stopped first. This was done independent of existing code in
cfg80211_leave(), so didn't handle e.g. background radar detection.
Use cfg80211_leave() to handle it the same way.

Note that cfg80211_leave() behaves slightly differently for IBSS in
wireless extensions, it won't send an event in that case. We could
handle that, but since nl80211 was used to change the type, IBSS is
rare, and wext is already a corner case, it doesn't seem worth it.

Link: https://patch.msgid.link/20251121174021.922ef48ce007.I970c8514252ef8a864a7fbdab9591b71031dee03@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## 2. CODE CHANGE ANALYSIS

Looking at the diff and comparing with `cfg80211_leave()`:

**Original inline switch did:**
- AP/P2P_GO: `cfg80211_stop_ap()`
- ADHOC: `cfg80211_leave_ibss(rdev, dev, false)` - note the `false`
  parameter
- STATION/P2P_CLIENT: `cfg80211_disconnect()`
- MESH_POINT: **nothing** (just a comment "mesh should be handled?")
- OCB: `cfg80211_leave_ocb()`

**`cfg80211_leave()` additionally does:**
1. `cfg80211_pmsr_wdev_down(wdev)` - **new cleanup**
2. `cfg80211_stop_background_radar_detection(wdev)` - **mentioned bug
   fix**
3. For ADHOC: uses `true` instead of `false` (changes wext event
   behavior)
4. For STATION/P2P_CLIENT: stops scheduled scans + wext cleanup
5. For MESH_POINT: `cfg80211_leave_mesh()` - **fixes the TODO bug**

## 3. CLASSIFICATION

This is primarily a **code refactoring/consolidation** that:
- Fixes bugs: background radar detection not stopped, MESH_POINT not
  handled
- Changes behavior: IBSS wext event, additional scheduled scan cleanup,
  pmsr cleanup
- The author explicitly acknowledges behavioral differences but
  considers them "not worth" fixing

## 4. SCOPE AND RISK ASSESSMENT

- **Lines:** Removes ~20 lines, replaces with single function call (net
  negative)
- **Files:** 1 file (net/wireless/util.c)
- **Risk:** Medium - introduces behavioral changes beyond the stated bug
  fixes

The behavioral differences acknowledged by the author are concerning for
stable:
- IBSS with wext will behave differently (no event sent)
- Additional cleanup operations are now performed

## 5. USER IMPACT

The bugs fixed (background radar detection, mesh point handling) are
real but:
- Not crashes or security issues
- More like "incomplete state cleanup" issues
- Impact is limited to users changing interface types

## 6. STABILITY INDICATORS

**Missing stable signals:**
- No `Cc: stable@vger.kernel.org` tag
- No `Fixes:` tag pointing to when bug was introduced
- Author explicitly noted behavioral differences but chose not to
  address them

## 7. DEPENDENCY CHECK

The change depends on `cfg80211_leave()` having the current
implementation with all the necessary handlers.

## Summary

While this commit does fix real issues (background radar detection not
stopped, MESH_POINT not handled), it's fundamentally a **code
consolidation** that:

1. **Introduces behavioral changes** beyond the bug fixes (IBSS wext
   events, additional cleanup operations)
2. **Lacks explicit stable request** from the maintainer (Johannes Berg)
3. **Author acknowledged** behavioral differences but chose not to fix
   them
4. The bugs fixed are **not crashes, security issues, or data
   corruption** - they're incomplete state cleanup issues

The maintainer deliberately did not add a `Cc: stable` or `Fixes:` tag,
suggesting this wasn't intended for backporting. The behavioral changes
(IBSS wext, scheduled scan cleanup, pmsr cleanup) go beyond the stated
bug fixes and could introduce unexpected regressions in stable trees.

This is code cleanup/improvement material, not targeted stable-critical
bug fix material.

**NO**

 net/wireless/util.c | 23 +----------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 56724b33af045..4eb028ad16836 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1203,28 +1203,7 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
 		dev->ieee80211_ptr->use_4addr = false;
 		rdev_set_qos_map(rdev, dev, NULL);
 
-		switch (otype) {
-		case NL80211_IFTYPE_AP:
-		case NL80211_IFTYPE_P2P_GO:
-			cfg80211_stop_ap(rdev, dev, -1, true);
-			break;
-		case NL80211_IFTYPE_ADHOC:
-			cfg80211_leave_ibss(rdev, dev, false);
-			break;
-		case NL80211_IFTYPE_STATION:
-		case NL80211_IFTYPE_P2P_CLIENT:
-			cfg80211_disconnect(rdev, dev,
-					    WLAN_REASON_DEAUTH_LEAVING, true);
-			break;
-		case NL80211_IFTYPE_MESH_POINT:
-			/* mesh should be handled? */
-			break;
-		case NL80211_IFTYPE_OCB:
-			cfg80211_leave_ocb(rdev, dev);
-			break;
-		default:
-			break;
-		}
+		cfg80211_leave(rdev, dev->ieee80211_ptr);
 
 		cfg80211_process_rdev_events(rdev);
 		cfg80211_mlme_purge_registrations(dev->ieee80211_ptr);
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] wifi: cfg80211: stop radar detection in cfg80211_leave()

[Sasha Levin]

From: Johannes Berg <johannes.berg@intel.com>

[ Upstream commit 9f33477b9a31a1edfe2df9f1a0359cccb0e16b4c ]

If an interface is set down or, per the previous patch, changes
type, radar detection for it should be cancelled. This is done
for AP mode in mac80211 (somewhat needlessly, since cfg80211 can
do it, but didn't until now), but wasn't handled for mesh, so if
radar detection was started and then the interface set down or
its type switched (the latter sometimes happning in the hwsim
test 'mesh_peer_connected_dfs'), radar detection would be around
with the interface unknown to the driver, later leading to some
warnings around chanctx usage.

Link: https://patch.msgid.link/20251121174021.290120e419e3.I2a5650c9062e29c988992dd8ce0d8eb570d23267@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Summary and Analysis

### What the Bug Fixes
This commit fixes a cleanup issue where radar detection (DFS CAC) was
not properly stopped when a mesh interface was brought down or changed
type. This left residual radar detection state that caused warnings
about chanctx (channel context) usage, since the driver thought radar
detection was still active for an interface that no longer existed.

### Technical Details
The fix:
1. Adds a new `cfg80211_stop_radar_detection()` function in `mlme.c`
   that iterates through all valid links, ends CAC via `rdev_end_cac()`,
   and sends `NL80211_RADAR_CAC_ABORTED` notification
2. Calls this new function in `cfg80211_leave()` (the cleanup path when
   interfaces go down)

### Critical Dependencies
The code uses **per-link DFS infrastructure** that was introduced in:
- **Commit 62c16f219a73c** ("wifi: cfg80211: move DFS related members to
  links[] in wireless_dev") - September 2024, **first in v6.12**

This commit accesses `wdev->links[link_id].cac_started` - this structure
only exists in 6.12+. In older kernels (6.11 and earlier), `cac_started`
was a simple top-level member of `wireless_dev`, not per-link.

### Stable Backport Assessment

**Against backporting:**
1. **No `Cc: stable@vger.kernel.org`** - The maintainer (Johannes Berg)
   did not request stable backporting
2. **No `Fixes:` tag** - No specific commit is identified as introducing
   the bug
3. **Dependencies on recent code** - The per-link DFS infrastructure
   only exists in kernel 6.12+
4. **Cannot apply to LTS trees** - Would require substantial rework for
   6.6.y, 6.1.y, 5.15.y, etc.
5. **Not critical severity** - The bug causes kernel warnings, not
   crashes, security issues, or data corruption
6. **Niche use case** - Mesh networking combined with DFS channels is
   relatively uncommon
7. **Very new feature** - The affected MLO/per-link DFS code is only one
   release old

**Supporting backporting:**
- Does fix a real bug that causes warnings
- Small, localized change (~25 lines)
- From a known/trusted maintainer

### Conclusion

This commit fixes a legitimate bug but does **not** meet stable kernel
criteria:
- The maintainer did not request stable backporting
- The affected code only exists in kernel 6.12+, making it only relevant
  to the most recent stable branch if any
- The bug severity (warnings, not crashes/corruption/security) does not
  warrant the backporting effort
- It cannot be cleanly applied to most stable trees due to structural
  code differences

**NO**

 net/wireless/core.c |  1 +
 net/wireless/core.h |  1 +
 net/wireless/mlme.c | 19 +++++++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 54a34d8d356e0..5e5c1bc380a89 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1365,6 +1365,7 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,
 
 	cfg80211_pmsr_wdev_down(wdev);
 
+	cfg80211_stop_radar_detection(wdev);
 	cfg80211_stop_background_radar_detection(wdev);
 
 	switch (wdev->iftype) {
diff --git a/net/wireless/core.h b/net/wireless/core.h
index b6bd7f4d6385a..d5d78752227af 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -489,6 +489,7 @@ cfg80211_start_background_radar_detection(struct cfg80211_registered_device *rde
 					  struct wireless_dev *wdev,
 					  struct cfg80211_chan_def *chandef);
 
+void cfg80211_stop_radar_detection(struct wireless_dev *wdev);
 void cfg80211_stop_background_radar_detection(struct wireless_dev *wdev);
 
 void cfg80211_background_cac_done_wk(struct work_struct *work);
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 46394eb2086f6..3fc175f9f8686 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -1295,6 +1295,25 @@ cfg80211_start_background_radar_detection(struct cfg80211_registered_device *rde
 	return 0;
 }
 
+void cfg80211_stop_radar_detection(struct wireless_dev *wdev)
+{
+	struct wiphy *wiphy = wdev->wiphy;
+	struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
+	int link_id;
+
+	for_each_valid_link(wdev, link_id) {
+		struct cfg80211_chan_def chandef;
+
+		if (!wdev->links[link_id].cac_started)
+			continue;
+
+		chandef = *wdev_chandef(wdev, link_id);
+		rdev_end_cac(rdev, wdev->netdev, link_id);
+		nl80211_radar_notify(rdev, &chandef, NL80211_RADAR_CAC_ABORTED,
+				     wdev->netdev, GFP_KERNEL);
+	}
+}
+
 void cfg80211_stop_background_radar_detection(struct wireless_dev *wdev)
 {
 	struct wiphy *wiphy = wdev->wiphy;
-- 
2.51.0

Re: [PATCH AUTOSEL 6.18-6.12] wifi: cfg80211: stop radar detection in cfg80211_leave()

[Johannes Berg]

On Sat, 2025-12-06 at 09:02 -0500, Sasha Levin wrote:
> 
> ### Conclusion
> 
> This commit fixes a legitimate bug but does **not** meet stable kernel
> criteria:
> - The maintainer did not request stable backporting
> - The affected code only exists in kernel 6.12+, making it only relevant
>   to the most recent stable branch if any
> - The bug severity (warnings, not crashes/corruption/security) does not
>   warrant the backporting effort
> - It cannot be cleanly applied to most stable trees due to structural
>   code differences
> 
> **NO**

:)

To be fair, it's kind of a corner case that happened mostly during tests
as far as I know, when two mesh peers getting radar detection happen to
pick two incompatible channels and then give up, causing wpa_s to bring
down the interface.

The thing that makes this interesting is that they both detect radar at
*precisely* the same time because they're actually simulated on a single
Linux system, and our regulatory code tells each and every radio if any
of them detects radar.

Anyway, either way is reasonable, it's probably a much older issue than
6.12 (then we just shuffled things around due to MLO), but the issue
would've been around before that, and nobody really seems to have
noticed outside this specific test.

johannes

Re: [PATCH AUTOSEL 6.18-6.12] wifi: cfg80211: stop radar detection in cfg80211_leave()

[Sasha Levin]

On Sat, Dec 06, 2025 at 03:55:37PM +0100, Johannes Berg wrote:
>On Sat, 2025-12-06 at 09:02 -0500, Sasha Levin wrote:
>>
>> ### Conclusion
>>
>> This commit fixes a legitimate bug but does **not** meet stable kernel
>> criteria:
>> - The maintainer did not request stable backporting
>> - The affected code only exists in kernel 6.12+, making it only relevant
>>   to the most recent stable branch if any
>> - The bug severity (warnings, not crashes/corruption/security) does not
>>   warrant the backporting effort
>> - It cannot be cleanly applied to most stable trees due to structural
>>   code differences
>>
>> **NO**
>
>:)
>
>To be fair, it's kind of a corner case that happened mostly during tests
>as far as I know, when two mesh peers getting radar detection happen to
>pick two incompatible channels and then give up, causing wpa_s to bring
>down the interface.
>
>The thing that makes this interesting is that they both detect radar at
>*precisely* the same time because they're actually simulated on a single
>Linux system, and our regulatory code tells each and every radio if any
>of them detects radar.
>
>Anyway, either way is reasonable, it's probably a much older issue than
>6.12 (then we just shuffled things around due to MLO), but the issue
>would've been around before that, and nobody really seems to have
>noticed outside this specific test.

Commits still get a review after the LLM response, which something is (IMO)
wrong :)

I'll keep it in, thanks!

-- 
Thanks,
Sasha