[PATCH AUTOSEL 6.18-6.12] Bluetooth: btusb: MT7920: Add VID/PID 0489/e135

[PATCH AUTOSEL 6.18-6.12] Bluetooth: btusb: MT7920: Add VID/PID 0489/e135

[Sasha Levin]

From: Chris Lu <chris.lu@mediatek.com>

[ Upstream commit c126f98c011f5796ba118ef2093122d02809d30d ]

Add VID 0489 & PID e135 for MediaTek MT7920 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e135 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us

Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:



 drivers/bluetooth/btusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 36f18f2657ab8..cc03c8c38b16f 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -621,6 +621,8 @@ static const struct usb_device_id quirks_table[] = {
 	/* Additional MediaTek MT7920 Bluetooth devices */
 	{ USB_DEVICE(0x0489, 0xe134), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x0489, 0xe135), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3620), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3621), .driver_info = BTUSB_MEDIATEK |
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] Bluetooth: btusb: MT7922: Add VID/PID 0489/e170

[Sasha Levin]

From: Chris Lu <chris.lu@mediatek.com>

[ Upstream commit 5a6700a31c953af9a17a7e2681335f31d922614d ]

Add VID 0489 & PID e170 for MediaTek MT7922 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e170 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:



 drivers/bluetooth/btusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c70e79e69be8d..36f18f2657ab8 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -685,6 +685,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0489, 0xe153), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x0489, 0xe170), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x04ca, 0x3804), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x04ca, 0x38e4), .driver_info = BTUSB_MEDIATEK |
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] wifi: mt76: mt792x: fix wifi init fail by setting MCU_RUNNING after CLC load

[Sasha Levin]

From: Quan Zhou <quan.zhou@mediatek.com>

[ Upstream commit 066f417be5fd8c7fe581c5550206364735dad7a3 ]

Set the MT76_STATE_MCU_RUNNING bit only after mt7921_load_clc()
has successfully completed. Previously, the MCU_RUNNING state
was set before loading CLC, which could cause conflict between
chip mcu_init retry and mac_reset flow, result in chip init fail
and chip abnormal status. By moving the state set after CLC load,
firmware initialization becomes robust and resolves init fail issue.

Signed-off-by: Quan Zhou <quan.zhou@mediatek.com>
Reviewed-by: druth@chromium.org
Link: https://patch.msgid.link/19ec8e4465142e774f17801025accd0ae2214092.1763465933.git.quan.zhou@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Commit Analysis: wifi: mt76: mt792x: fix wifi init fail by setting
MCU_RUNNING after CLC load

## 1. COMMIT MESSAGE ANALYSIS

**Subject:** Clearly indicates a bug fix ("fix wifi init fail")

**Problem described:** Setting `MT76_STATE_MCU_RUNNING` bit before CLC
(Country/Legal Configuration) load completion could cause conflicts
between MCU init retry and mac_reset flows, resulting in chip
initialization failure and abnormal chip status.

**Tags present:**
- `Signed-off-by:` Quan Zhou (MediaTek - chip vendor) and Felix Fietkau
  (mt76 maintainer)
- `Reviewed-by:` druth@chromium.org (Chrome OS kernel team - indicates
  real-world Chromebook impact)
- No explicit `Cc: stable@vger.kernel.org` tag
- No explicit `Fixes:` tag

## 2. CODE CHANGE ANALYSIS

The change is extremely simple and surgical:

**Before the fix:**
```c
set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);  // State set here
err = mt7921_load_clc(dev, mt792x_ram_name(dev));   // CLC load after
```

**After the fix:**
```c
err = mt7921_load_clc(dev, mt792x_ram_name(dev));   // CLC load first
set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);  // State set after
success
```

**Technical mechanism:**
- `MT76_STATE_MCU_RUNNING` indicates the MCU is fully operational
- Setting this flag prematurely (before CLC load) could allow other code
  paths to think the MCU is ready when it's not
- If something triggers MCU init retry or mac_reset during CLC load,
  there's a race condition
- The conflict causes complete initialization failure and abnormal chip
  state

**Why fix is correct:**
- The state bit should only be set when initialization is truly complete
- This ensures no code sees MCU_RUNNING during the vulnerable CLC
  loading phase
- Error handling remains intact (if CLC load fails, function returns
  error)

## 3. CLASSIFICATION

- **Type:** Bug fix - initialization failure fix
- **NOT** a feature addition
- Fixes a real runtime bug affecting device usability

## 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | ~6 lines (just moving 1 line in 2 files) |
| Files touched | 2 (mt7921/mcu.c, mt7925/mcu.c) |
| Complexity | Very low - simple reordering |
| Regression risk | LOW - no logic changes, just timing |
| Subsystem | Wireless driver (contained) |

The change is almost purely a reordering operation within the same
function. If CLC load succeeds, the state gets set (same as before, just
later). If it fails, function returns error anyway.

## 5. USER IMPACT

**Affected hardware:** MediaTek mt7921 and mt7925 WiFi chips

These are **extremely common** chips found in:
- Many Chromebooks (Chrome OS review indicates this)
- Consumer laptops (Dell, Lenovo, HP, etc.)
- USB WiFi adapters
- Various PC builds

**Severity:** HIGH
- WiFi initialization failure = device doesn't work at all
- "chip abnormal status" suggests chip may be left in broken state
- Users cannot use their WiFi until reboot or driver reload

## 6. STABILITY INDICATORS

- Reviewed by Chromium kernel team (indicates real-world testing on
  Chromebooks)
- From MediaTek engineer (hardware vendor knows their chip)
- Accepted by mt76 maintainer Felix Fietkau
- Clean, minimal change with clear rationale

## 7. DEPENDENCY CHECK

The change is self-contained. It only reorders existing function calls
within `mt7921_run_firmware()` and `mt7925_run_firmware()`. No new
dependencies are introduced.

The mt7921 driver has been in stable kernels for some time. The mt7925
is newer and may not exist in older stable trees, but the mt7921 portion
would still be valuable.

## STABLE KERNEL CRITERIA CHECK

| Criterion | Met? | Notes |
|-----------|------|-------|
| Obviously correct | ✅ | Simple reordering, logic is clear |
| Fixes real bug | ✅ | WiFi init failure - real user impact |
| Small and contained | ✅ | 6 lines, 2 files, same subsystem |
| No new features | ✅ | No new APIs or functionality |
| No architectural changes | ✅ | Minimal change |

## RISK vs BENEFIT

**Benefit:** High - Fixes WiFi initialization failure on widely-deployed
hardware. Without this fix, affected users may have non-functional WiFi.

**Risk:** Very low - The change is a trivial reordering of two
operations. The logic remains identical; only the timing of when the
state bit is set changes. The fix has been reviewed by the chip vendor
and Chrome OS team.

## CONCLUSION

This commit is an ideal candidate for stable backporting:

1. **Fixes a real, user-visible bug** - WiFi doesn't work
2. **Minimal change** - Just reordering one line in each of two files
3. **Well-reviewed** - MediaTek and Chrome OS review
4. **Low regression risk** - No logic changes, simple timing fix
5. **High user impact** - mt7921/mt7925 are very common chips
6. **Contained scope** - Only affects initialization path of specific
   driver

The lack of `Cc: stable` tag doesn't disqualify it - many legitimate
fixes don't include this tag. The important factors are all positive: it
fixes a real bug, is small, safe, and affects real users.

**YES**

 drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
index 86bd33b916a9d..edc1df3c071e5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
@@ -646,10 +646,10 @@ int mt7921_run_firmware(struct mt792x_dev *dev)
 	if (err)
 		return err;
 
-	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 	err = mt7921_load_clc(dev, mt792x_ram_name(dev));
 	if (err)
 		return err;
+	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 
 	return mt7921_mcu_fw_log_2_host(dev, 1);
 }
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index 8eda407e4135e..c12b71b71cfc7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1003,10 +1003,10 @@ int mt7925_run_firmware(struct mt792x_dev *dev)
 	if (err)
 		return err;
 
-	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 	err = mt7925_load_clc(dev, mt792x_ram_name(dev));
 	if (err)
 		return err;
+	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 
 	return mt7925_mcu_fw_log_2_host(dev, 1);
 }
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] wifi: mt76: mt792x: fix wifi init fail by setting MCU_RUNNING after CLC load

[Sasha Levin]

From: Quan Zhou <quan.zhou@mediatek.com>

[ Upstream commit 066f417be5fd8c7fe581c5550206364735dad7a3 ]

Set the MT76_STATE_MCU_RUNNING bit only after mt7921_load_clc()
has successfully completed. Previously, the MCU_RUNNING state
was set before loading CLC, which could cause conflict between
chip mcu_init retry and mac_reset flow, result in chip init fail
and chip abnormal status. By moving the state set after CLC load,
firmware initialization becomes robust and resolves init fail issue.

Signed-off-by: Quan Zhou <quan.zhou@mediatek.com>
Reviewed-by: druth@chromium.org
Link: https://patch.msgid.link/19ec8e4465142e774f17801025accd0ae2214092.1763465933.git.quan.zhou@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Commit Analysis: wifi: mt76: mt792x: fix wifi init fail by setting
MCU_RUNNING after CLC load

## 1. COMMIT MESSAGE ANALYSIS

**Subject:** Clearly indicates a bug fix ("fix wifi init fail")

**Problem described:** Setting `MT76_STATE_MCU_RUNNING` bit before CLC
(Country/Legal Configuration) load completion could cause conflicts
between MCU init retry and mac_reset flows, resulting in chip
initialization failure and abnormal chip status.

**Tags present:**
- `Signed-off-by:` Quan Zhou (MediaTek - chip vendor) and Felix Fietkau
  (mt76 maintainer)
- `Reviewed-by:` druth@chromium.org (Chrome OS kernel team - indicates
  real-world Chromebook impact)
- No explicit `Cc: stable@vger.kernel.org` tag
- No explicit `Fixes:` tag

## 2. CODE CHANGE ANALYSIS

The change is extremely simple and surgical:

**Before the fix:**
```c
set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);  // State set here
err = mt7921_load_clc(dev, mt792x_ram_name(dev));   // CLC load after
```

**After the fix:**
```c
err = mt7921_load_clc(dev, mt792x_ram_name(dev));   // CLC load first
set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);  // State set after
success
```

**Technical mechanism:**
- `MT76_STATE_MCU_RUNNING` indicates the MCU is fully operational
- Setting this flag prematurely (before CLC load) could allow other code
  paths to think the MCU is ready when it's not
- If something triggers MCU init retry or mac_reset during CLC load,
  there's a race condition
- The conflict causes complete initialization failure and abnormal chip
  state

**Why fix is correct:**
- The state bit should only be set when initialization is truly complete
- This ensures no code sees MCU_RUNNING during the vulnerable CLC
  loading phase
- Error handling remains intact (if CLC load fails, function returns
  error)

## 3. CLASSIFICATION

- **Type:** Bug fix - initialization failure fix
- **NOT** a feature addition
- Fixes a real runtime bug affecting device usability

## 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | ~6 lines (just moving 1 line in 2 files) |
| Files touched | 2 (mt7921/mcu.c, mt7925/mcu.c) |
| Complexity | Very low - simple reordering |
| Regression risk | LOW - no logic changes, just timing |
| Subsystem | Wireless driver (contained) |

The change is almost purely a reordering operation within the same
function. If CLC load succeeds, the state gets set (same as before, just
later). If it fails, function returns error anyway.

## 5. USER IMPACT

**Affected hardware:** MediaTek mt7921 and mt7925 WiFi chips

These are **extremely common** chips found in:
- Many Chromebooks (Chrome OS review indicates this)
- Consumer laptops (Dell, Lenovo, HP, etc.)
- USB WiFi adapters
- Various PC builds

**Severity:** HIGH
- WiFi initialization failure = device doesn't work at all
- "chip abnormal status" suggests chip may be left in broken state
- Users cannot use their WiFi until reboot or driver reload

## 6. STABILITY INDICATORS

- Reviewed by Chromium kernel team (indicates real-world testing on
  Chromebooks)
- From MediaTek engineer (hardware vendor knows their chip)
- Accepted by mt76 maintainer Felix Fietkau
- Clean, minimal change with clear rationale

## 7. DEPENDENCY CHECK

The change is self-contained. It only reorders existing function calls
within `mt7921_run_firmware()` and `mt7925_run_firmware()`. No new
dependencies are introduced.

The mt7921 driver has been in stable kernels for some time. The mt7925
is newer and may not exist in older stable trees, but the mt7921 portion
would still be valuable.

## STABLE KERNEL CRITERIA CHECK

| Criterion | Met? | Notes |
|-----------|------|-------|
| Obviously correct | ✅ | Simple reordering, logic is clear |
| Fixes real bug | ✅ | WiFi init failure - real user impact |
| Small and contained | ✅ | 6 lines, 2 files, same subsystem |
| No new features | ✅ | No new APIs or functionality |
| No architectural changes | ✅ | Minimal change |

## RISK vs BENEFIT

**Benefit:** High - Fixes WiFi initialization failure on widely-deployed
hardware. Without this fix, affected users may have non-functional WiFi.

**Risk:** Very low - The change is a trivial reordering of two
operations. The logic remains identical; only the timing of when the
state bit is set changes. The fix has been reviewed by the chip vendor
and Chrome OS team.

## CONCLUSION

This commit is an ideal candidate for stable backporting:

1. **Fixes a real, user-visible bug** - WiFi doesn't work
2. **Minimal change** - Just reordering one line in each of two files
3. **Well-reviewed** - MediaTek and Chrome OS review
4. **Low regression risk** - No logic changes, simple timing fix
5. **High user impact** - mt7921/mt7925 are very common chips
6. **Contained scope** - Only affects initialization path of specific
   driver

The lack of `Cc: stable` tag doesn't disqualify it - many legitimate
fixes don't include this tag. The important factors are all positive: it
fixes a real bug, is small, safe, and affects real users.

**YES**

 drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
index 86bd33b916a9d..edc1df3c071e5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
@@ -646,10 +646,10 @@ int mt7921_run_firmware(struct mt792x_dev *dev)
 	if (err)
 		return err;
 
-	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 	err = mt7921_load_clc(dev, mt792x_ram_name(dev));
 	if (err)
 		return err;
+	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 
 	return mt7921_mcu_fw_log_2_host(dev, 1);
 }
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index 8eda407e4135e..c12b71b71cfc7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1003,10 +1003,10 @@ int mt7925_run_firmware(struct mt792x_dev *dev)
 	if (err)
 		return err;
 
-	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 	err = mt7925_load_clc(dev, mt792x_ram_name(dev));
 	if (err)
 		return err;
+	set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);
 
 	return mt7925_mcu_fw_log_2_host(dev, 1);
 }
-- 
2.51.0