[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

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

[Baochen Qiang]

On 3/22/2026 8:48 PM, Malte Schababerle wrote:
> 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;
>  

Malte, the firmware team needs firmware dump to understand this issue, would you be able
to help collect it?

Re: [PATCH] ath10k: skip quiet mode for WCN3990 to prevent firmware crash

[Malte Schababerle]

On 3/22/2026, Baochen Qiang wrote:
> Malte, the firmware team needs firmware dump to understand this issue,
> would you be able to help collect it?

Sure. Attaching the full dmesg from a reproducible test run (kernel
without the patch, upstream 6.17, postmarketOS on OnePlus 7T / SM8150).

Firmware: WLAN.HL.3.2.0.c2-00006

The crash triggers deterministically on every boot. Key lines:

  [25.122098] PDM: service 'wlan_process' crash:
               'EX:wlan_process:0x1:WLAN RT:0x2076:PC=0xb0008e20'
  [25.283364] ath10k_snoc 18800000.wifi: firmware crashed!

Full crash sequence repeats across subsequent recovery attempts at the
same PC=0xb0008e20 (see attached dmesg.txt).

Note: I'm running an upstream kernel (6.17) on postmarketOS.
CONFIG_QCOM_RAMDUMP and WCSS coredump tooling are not available here.
If the firmware team needs a full Hexagon register dump, please advise
how to collect it in this environment.

Tested-by: Malte Schababerle <m.schababerle@gmail.com>
  on OnePlus 7T (SM8150/WCN3990), kernel 6.17, FW WLAN.HL.3.2.0.c2-00006

Re: [PATCH] ath10k: skip quiet mode for WCN3990 to prevent firmware crash

[Baochen Qiang]

On 4/7/2026 6:14 AM, Malte Schababerle wrote:
> On 3/22/2026, Baochen Qiang wrote:
>> Malte, the firmware team needs firmware dump to understand this issue,
>> would you be able to help collect it?
> 
> Sure. Attaching the full dmesg from a reproducible test run (kernel
> without the patch, upstream 6.17, postmarketOS on OnePlus 7T / SM8150).
> 
> Firmware: WLAN.HL.3.2.0.c2-00006
> 
> The crash triggers deterministically on every boot. Key lines:
> 
>   [25.122098] PDM: service 'wlan_process' crash:
>                'EX:wlan_process:0x1:WLAN RT:0x2076:PC=0xb0008e20'
>   [25.283364] ath10k_snoc 18800000.wifi: firmware crashed!
> 
> Full crash sequence repeats across subsequent recovery attempts at the
> same PC=0xb0008e20 (see attached dmesg.txt).
> 
> Note: I'm running an upstream kernel (6.17) on postmarketOS.
> CONFIG_QCOM_RAMDUMP and WCSS coredump tooling are not available here.
> If the firmware team needs a full Hexagon register dump, please advise
> how to collect it in this environment.

please follow below steps to collect firmware dump:

1. sudo modprobe -r ath10k_pci
2. sudo modprobe ath10k_core coredump_mask=7
3. sudo modprobe ath10k_pci
4. reproduce the crash issue
5. collect dump using a similar way to Intel chip [1]:

	You can now get the data from the devcoredump device and dump to a file:

	cat /sys/devices/virtual/devcoredump/devcdY/data > iwl.dump
	echo 1 > /sys/devices/virtual/devcoredump/devcdY/data
	(Y is incremented each time)

	The easiest is to define a udev rule to dump the data automatically as soon as
	dump is created:

	SUBSYSTEM=="devcoredump", ACTION=="add", RUN+="/sbin/iwlfwdump.sh"
	You’ll typically have to paste this into a new file called /etc/udev/rules.d/85-
	iwl-dump.rules. This location can vary between distributions.

	/sbin/iwlfwdump.sh can simply be:

	#!/bin/bash

	timestamp=$(date +%F_%H-%M-%S)
	filename=/var/log/iwl-fw-error_${timestamp}.dump
	cat /sys/${DEVPATH}/data > ${filename}
	echo 1 > /sys/${DEVPATH}/data

	This way, each time a dump is created it will automatically land on your file
	system. Remember to make the /sbin/iwlfwdump.sh file executable (i.e. chmod a+x
	/sbin/iwlfwdump.sh), so that the udev rule can execute it, otherwise it won’t
	work.

[1]
https://wireless.docs.kernel.org/en/latest/en/users/drivers/iwlwifi/debugging.html#how-to-provide-information-to-debug-the-firmware

> 
> Tested-by: Malte Schababerle <m.schababerle@gmail.com>
>   on OnePlus 7T (SM8150/WCN3990), kernel 6.17, FW WLAN.HL.3.2.0.c2-00006

[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?