[PATCH AUTOSEL 6.19-6.18] wifi: rtw89: regd: 6 GHz power type marks default when inactive

[Sasha Levin <sashal@kernel.org>]

From: Zong-Zhe Yang <kevin_yang@realtek.com>

[ Upstream commit 8c96752d99c0b094af68317a8c701b09bd0862d9 ]

When inactive, 6 GHz power type has been assigned to the default one,
but missed to mark the local control variable, dflt, true. Then, this
might let some 6 GHz power info of disconnected APs keep being taken
into account under certain cases.

So, mark default when inactive.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251229030926.27004-12-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: wifi: rtw89: regd: 6 GHz power type marks default
when inactive

### 1. Commit Message Analysis

The commit message clearly describes a bug: when a 6 GHz connection
becomes inactive, the code correctly sets the power type to the default
value (`RTW89_REG_6GHZ_POWER_DFLT`), but **fails to set the local
variable `dflt = true`**. This is a logic error where two related state
updates are out of sync.

The consequence: "this might let some 6 GHz power info of disconnected
APs keep being taken into account under certain cases." This means stale
power configuration from a previously connected AP could persist and
affect regulatory behavior.

### 2. Code Change Analysis

The fix is a **single line addition**: `dflt = true;` in the `else`
(inactive) branch.

Let me trace the logic:

- `dflt` is a boolean that tracks whether the default power type is in
  use
- In the `active` branch, when the `default:` case of the switch is hit,
  both `reg_6ghz_power = RTW89_REG_6GHZ_POWER_DFLT` AND `dflt = true`
  are set
- In the `else` (inactive) branch, `reg_6ghz_power =
  RTW89_REG_6GHZ_POWER_DFLT` is set but `dflt` was **not** being set to
  `true`

The `dflt` variable is then checked at line `if (!dflt &&
blocked[rtwvif_link->reg_6ghz_power])`. When `dflt` is false and the
power type is `RTW89_REG_6GHZ_POWER_DFLT`, the code would incorrectly
check `blocked[RTW89_REG_6GHZ_POWER_DFLT]`, which could cause the
function to return `-EINVAL` erroneously when the link is inactive, or
it could allow stale power type information to persist.

### 3. Bug Classification

This is a **logic bug** — specifically a missing state update that
causes inconsistent behavior. When a WiFi interface goes inactive on 6
GHz:
- The power type is correctly reset to default
- But `dflt` stays false (from initialization), so the "blocked" check
  below could still evaluate the default power type against the blocked
  list, potentially returning an error when it shouldn't

This affects regulatory domain handling, which is important for proper
WiFi operation on 6 GHz bands.

### 4. Scope and Risk Assessment

- **Size**: 1 line added — minimal
- **Files touched**: 1 file
  (`drivers/net/wireless/realtek/rtw89/regd.c`)
- **Risk**: Extremely low — it's adding a missing boolean assignment
  that mirrors the behavior already present in the `default:` case of
  the `active` branch
- **Correctness**: Obviously correct — the inactive branch sets the same
  `RTW89_REG_6GHZ_POWER_DFLT` value as the default case in the active
  branch, so it should also set `dflt = true`

### 5. User Impact

- Affects users of Realtek RTW89 WiFi adapters using 6 GHz bands
- Could cause incorrect regulatory power type handling when
  disconnecting from 6 GHz APs
- In certain cases, stale power info from disconnected APs could be
  used, potentially causing regulatory compliance issues or connectivity
  problems

### 6. Stable Kernel Criteria

- **Obviously correct**: Yes — the fix is symmetric with the `default:`
  case in the active branch
- **Fixes a real bug**: Yes — logic error causing inconsistent state
- **Small and contained**: Yes — 1 line in 1 file
- **No new features**: Correct — pure bug fix
- **Tested**: From Realtek maintainers (Zong-Zhe Yang, Ping-Ke Shih)

### 7. Dependencies

This fix is self-contained. The surrounding code structure (the switch
statement, the `dflt` variable, the `blocked[]` check) all exist in
stable kernels that have the rtw89 driver with 6 GHz support.

### Conclusion

This is a clean, minimal, obviously-correct bug fix that addresses a
real logic error in WiFi regulatory power type handling. It has
negligible risk of regression and fixes a genuine issue for users of
Realtek WiFi adapters on 6 GHz networks.

**YES**

 drivers/net/wireless/realtek/rtw89/regd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtw89/regd.c b/drivers/net/wireless/realtek/rtw89/regd.c
index 209d84909f885..c3425ed44732e 100644
--- a/drivers/net/wireless/realtek/rtw89/regd.c
+++ b/drivers/net/wireless/realtek/rtw89/regd.c
@@ -1142,6 +1142,7 @@ static int rtw89_reg_6ghz_power_recalc(struct rtw89_dev *rtwdev,
 		}
 	} else {
 		rtwvif_link->reg_6ghz_power = RTW89_REG_6GHZ_POWER_DFLT;
+		dflt = true;
 	}
 
 	rcu_read_unlock();
-- 
2.51.0