[PATCH 0/2] ath10k: WCN3990 firmware workarounds for WLAN.HL.3.2

[PATCH 0/2] ath10k: WCN3990 firmware workarounds for WLAN.HL.3.2

[Malte Schababerle]

Two firmware workarounds for WCN3990 (QCA6174 integrated variant on
Qualcomm SM8150/SDM845 platforms) running WLAN.HL.3.2 firmware.

Both issues are firmware bugs where WCN3990 advertises capabilities it
cannot handle correctly. Tested on OnePlus 7T (SM8150) with
WLAN.HL.3.2.0.c2-00006 and WLAN.HL.3.2.0.c2-00011.

Patch 1 fixes a deterministic firmware crash caused by the quiet mode
WMI command. The existing guard from commit 53884577fbcef relied on
THERM_THROT not being advertised, but HL3.2 now advertises it despite
still crashing on the command.

Patch 2 works around a bug where active scan does not tune the radio
on 5GHz non-DFS channels, making 5GHz networks invisible. Forcing
passive scan mode restores 5GHz discovery.

Malte Schababerle (2):
  ath10k: skip quiet mode for WCN3990 to prevent firmware crash
  ath10k: force passive scan on 5GHz for WCN3990

 drivers/net/wireless/ath/ath10k/mac.c     |  8 ++++++++
 drivers/net/wireless/ath/ath10k/thermal.c | 10 ++++++++++
 2 files changed, 18 insertions(+)

-- 
2.47.3

[PATCH 1/2] ath10k: skip quiet mode for WCN3990 to prevent firmware crash

[Malte Schababerle]

WCN3990 firmware (WLAN.HL.3.2) crashes deterministically when the
quiet mode WMI command is sent during ath10k_start(). The crash occurs
at PC=0xb0008e20 in wlanmdsp.mbn, ~17ms after the subsequent
vdev_create command, and cascades into a full modem crash.

Commit 53884577fbcef ("ath10k: skip sending quiet mode cmd for
WCN3990") addressed this for HL2.0 firmware by gating quiet mode on
WMI_SERVICE_THERM_THROT. HL2.0 did not advertise the service bit, so
the guard was effective. However, newer WCN3990 firmware (HL3.2)
erroneously advertises WMI_SERVICE_THERM_THROT via its TLV service
map despite still being unable to handle the quiet mode command.

Skip quiet mode unconditionally for WCN3990 using QCA_REV_WCN3990()
instead of relying on the service bit.

Tested on OnePlus 7T (SM8150/WCN3990) with WLAN.HL.3.2.0.c2-00006
and WLAN.HL.3.2.0.c2-00011 (both crash without patch, both work with):
- wlan0 comes up without crash
- WiFi scanning works
- NetworkManager recognizes the interface

Fixes: 53884577fbcef ("ath10k: skip sending quiet mode cmd for WCN3990")
Signed-off-by: Malte Schababerle <m.schababerle@gmail.com>
---
 drivers/net/wireless/ath/ath10k/thermal.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/thermal.c b/drivers/net/wireless/ath/ath10k/thermal.c
index 8b15ec07b1071..33f299f414710 100644
--- a/drivers/net/wireless/ath/ath10k/thermal.c
+++ b/drivers/net/wireless/ath/ath10k/thermal.c
@@ -136,6 +136,16 @@ void ath10k_thermal_set_throttling(struct ath10k *ar)
 	if (!ar->wmi.ops->gen_pdev_set_quiet_mode)
 		return;
 
+	/* WCN3990 firmware crashes on quiet mode despite advertising support.
+	 * See also commit 53884577fbcef ("ath10k: skip sending quiet mode
+	 * cmd for WCN3990").
+	 */
+	if (QCA_REV_WCN3990(ar)) {
+		ath10k_dbg(ar, ATH10K_DBG_BOOT,
+			   "skip quiet mode for WCN3990 (known crash trigger)\n");
+		return;
+	}
+
 	if (ar->state != ATH10K_STATE_ON)
 		return;
 
-- 
2.47.3

[PATCH 2/2] ath10k: force passive scan on 5GHz for WCN3990

[Malte Schababerle]

WCN3990 firmware (WLAN.HL.3.2) has a bug where active scan does not
tune the radio on 5GHz non-DFS channels. The radio reports identical
rx_clear_count values across channels, indicating no RF tuning occurs.
As a result, no 5GHz networks are discovered during active scan.

Passive scan works correctly on all 5GHz channels: the radio tunes
properly and rx_clear_count varies as expected.

Force passive scan mode for all 5GHz channels on WCN3990 using
QCA_REV_WCN3990(). DFS channels are already passive, so the effective
change is for non-DFS 5GHz channels only. This follows the pattern
established for WCN3990 firmware workarounds in thermal.c.

Tested on OnePlus 7T (SM8150/WCN3990) with WLAN.HL.3.2.0.c2-00006
and WLAN.HL.3.2.0.c2-00011:
- 5GHz passive scan discovers APs reliably (e.g. ch116/5580 MHz)
- Association to 5GHz networks succeeds
- No change to 2.4GHz or DFS channel behavior

Signed-off-by: Malte Schababerle <m.schababerle@gmail.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 24dd794e31ea2..f6829232f6b15 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3441,6 +3441,14 @@ static int ath10k_update_channel_list(struct ath10k *ar)
 			passive = channel->flags & IEEE80211_CHAN_NO_IR;
 			ch->passive = passive;
 
+			/* Force passive scan on 5GHz to work around WCN3990
+			 * firmware bug where active scan doesn't tune the
+			 * radio on 5GHz non-DFS channels.
+			 */
+			if (QCA_REV_WCN3990(ar) &&
+			    band == NL80211_BAND_5GHZ)
+				ch->passive = true;
+
 			/* the firmware is ignoring the "radar" flag of the
 			 * channel and is scanning actively using Probe Requests
 			 * on "Radar detection"/DFS channels which are not
-- 
2.47.3

Re: [PATCH 0/2] ath10k: WCN3990 firmware workarounds for WLAN.HL.3.2

[Loic Poulain]

Hi Jeff, Malte.

On Sun, Mar 22, 2026 at 2:49 PM Malte Schababerle
<m.schababerle@gmail.com> wrote:
>
> Two firmware workarounds for WCN3990 (QCA6174 integrated variant on
> Qualcomm SM8150/SDM845 platforms) running WLAN.HL.3.2 firmware.
>
> Both issues are firmware bugs where WCN3990 advertises capabilities it
> cannot handle correctly. Tested on OnePlus 7T (SM8150) with
> WLAN.HL.3.2.0.c2-00006 and WLAN.HL.3.2.0.c2-00011.
>
> Patch 1 fixes a deterministic firmware crash caused by the quiet mode
> WMI command. The existing guard from commit 53884577fbcef relied on
> THERM_THROT not being advertised, but HL3.2 now advertises it despite
> still crashing on the command.
>
> Patch 2 works around a bug where active scan does not tune the radio
> on 5GHz non-DFS channels, making 5GHz networks invisible. Forcing
> passive scan mode restores 5GHz discovery.
>
> Malte Schababerle (2):
>   ath10k: skip quiet mode for WCN3990 to prevent firmware crash
>   ath10k: force passive scan on 5GHz for WCN3990

Jeff, is this something that could be addressed or worked around
through the firmware or NV configuration? Applying this workaround to
all WCN3990 devices feels a bit excessive if the issue is limited to
specific variants.

Regards,
Loic

Re: [PATCH 0/2] ath10k: WCN3990 firmware workarounds for WLAN.HL.3.2

[Jeff Johnson]

On 3/25/2026 1:41 AM, Loic Poulain wrote:
> Hi Jeff, Malte.
> 
> On Sun, Mar 22, 2026 at 2:49 PM Malte Schababerle
> <m.schababerle@gmail.com> wrote:
>>
>> Two firmware workarounds for WCN3990 (QCA6174 integrated variant on
>> Qualcomm SM8150/SDM845 platforms) running WLAN.HL.3.2 firmware.
>>
>> Both issues are firmware bugs where WCN3990 advertises capabilities it
>> cannot handle correctly. Tested on OnePlus 7T (SM8150) with
>> WLAN.HL.3.2.0.c2-00006 and WLAN.HL.3.2.0.c2-00011.
>>
>> Patch 1 fixes a deterministic firmware crash caused by the quiet mode
>> WMI command. The existing guard from commit 53884577fbcef relied on
>> THERM_THROT not being advertised, but HL3.2 now advertises it despite
>> still crashing on the command.
>>
>> Patch 2 works around a bug where active scan does not tune the radio
>> on 5GHz non-DFS channels, making 5GHz networks invisible. Forcing
>> passive scan mode restores 5GHz discovery.
>>
>> Malte Schababerle (2):
>>   ath10k: skip quiet mode for WCN3990 to prevent firmware crash
>>   ath10k: force passive scan on 5GHz for WCN3990
> 
> Jeff, is this something that could be addressed or worked around
> through the firmware or NV configuration? Applying this workaround to
> all WCN3990 devices feels a bit excessive if the issue is limited to
> specific variants.

+Baochen, can you look at this with the firmware team?