[PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Filippo Falezza]

Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
holding conf_mutex. Not all firmware answers: the WCN3990 firmware
WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
codename nairo (SM7250) never sends the event, so every read of
temp1_input stalls for 5 s, logs

  ath10k_snoc 18800000.wifi: failed to synchronize thermal read

and returns -ETIMEDOUT. Tools that read all hwmon sensors, such as
lm-sensors, hang for 5 s on every run, and configuration changes of the
interface wait for conf_mutex in the meantime.

Whether the firmware answers cannot be told from the chip: firmware that
answers and firmware that does not both advertise
WMI_SERVICE_THERM_THROT, and WCN3990 firmware differs between devices.
Instead, remember that the running firmware did not answer, and return
-EOPNOTSUPP right away on later reads. Forget it when the firmware
starts, so that a restarted or updated firmware is asked again.

The first read after each firmware start still takes 5 s when the
firmware does not answer. Reads on firmware that answers are unchanged.

This change was written with the help of an AI coding assistant; see
the notes below.

Fixes: e98199a8c27f ("ath10k: enable QCA6174/QCA9377 to read the chip temperature")
Signed-off-by: Filippo Falezza <effeffe99@gmail.com>
---
Hello there,

this is v2 of the fix for ath10k temperature reads that stall for 5 s
on firmware that never answers the request, as on the WCN3990 firmware
of a Motorola Moto G 5G Plus (SM7250).

The only change from v1 is the name of the flag: it is now
ath10k_thermal.broken, as Loic suggested, instead of
temperature_unanswered. The behaviour is the same, so the testing from
v1 still applies: on the phone, the first read after the firmware
starts times out once after 5 s, every later read returns -EOPNOTSUPP
within milliseconds, and a full `sensors` run takes 25 ms instead of
5 s or more. Restarting Wi-Fi makes the driver ask the firmware again.
I have not tested firmware that answers the request.

v2 builds with W=1 for arm64 and is checkpatch --strict clean, on top
of ath-next (cd026e68fdbf).

As with v1, I wrote this with the help of an AI coding assistant
(Claude Code); the testing is on the phone.

Thanks,
Filippo
---
Changes in v2:
- Rename temperature_unanswered to broken, as suggested by Loic Poulain.
- Link to v1: https://patch.msgid.link/20261026-ath10k-temperature-v1-1-e5cd6fde7f1e@gmail.com
---
 drivers/net/wireless/ath/ath10k/core.c    | 1 +
 drivers/net/wireless/ath/ath10k/thermal.c | 9 ++++++++-
 drivers/net/wireless/ath/ath10k/thermal.h | 2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7c2939cbde5f..a749ae582b0a 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2985,6 +2985,7 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
 	clear_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
 
 	ar->running_fw = fw;
+	ar->thermal.broken = false;
 
 	if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
 		      ar->running_fw->fw_file.fw_features)) {
diff --git a/drivers/net/wireless/ath/ath10k/thermal.c b/drivers/net/wireless/ath/ath10k/thermal.c
index 9bb486f8e920..9ff7de0abd12 100644
--- a/drivers/net/wireless/ath/ath10k/thermal.c
+++ b/drivers/net/wireless/ath/ath10k/thermal.c
@@ -75,6 +75,12 @@ static ssize_t ath10k_thermal_show_temp(struct device *dev,
 		goto out;
 	}
 
+	/* Don't stall every read on firmware that never answers */
+	if (ar->thermal.broken) {
+		ret = -EOPNOTSUPP;
+		goto out;
+	}
+
 	reinit_completion(&ar->thermal.wmi_sync);
 	ret = ath10k_wmi_pdev_get_temperature(ar);
 	if (ret) {
@@ -90,7 +96,8 @@ static ssize_t ath10k_thermal_show_temp(struct device *dev,
 	time_left = wait_for_completion_timeout(&ar->thermal.wmi_sync,
 						ATH10K_THERMAL_SYNC_TIMEOUT_HZ);
 	if (!time_left) {
-		ath10k_warn(ar, "failed to synchronize thermal read\n");
+		ath10k_warn(ar, "failed to synchronize thermal read, not asking again until the firmware restarts\n");
+		ar->thermal.broken = true;
 		ret = -ETIMEDOUT;
 		goto out;
 	}
diff --git a/drivers/net/wireless/ath/ath10k/thermal.h b/drivers/net/wireless/ath/ath10k/thermal.h
index 1f4de9fbf2b3..d1fb5b958c37 100644
--- a/drivers/net/wireless/ath/ath10k/thermal.h
+++ b/drivers/net/wireless/ath/ath10k/thermal.h
@@ -19,6 +19,8 @@ struct ath10k_thermal {
 	/* protected by conf_mutex */
 	u32 throttle_state;
 	u32 quiet_period;
+	/* the running firmware did not answer a temperature request */
+	bool broken;
 	/* temperature value in Celsius degree
 	 * protected by data_lock
 	 */

---
base-commit: cd026e68fdbf88b9cc522b76c7a9d92c9a41f709
change-id: 20261022-ath10k-temperature-22b119fd615c

Best regards,
--  
Filippo Falezza <effeffe99@gmail.com>

Re: [PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Loic Poulain]

On Tue, Oct 27, 2026 at 2:56 AM Filippo Falezza <effeffe99@gmail.com> wrote:
>
> Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
> waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
> holding conf_mutex. Not all firmware answers: the WCN3990 firmware
> WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
> codename nairo (SM7250) never sends the event, so every read of
> temp1_input stalls for 5 s, logs
>
>   ath10k_snoc 18800000.wifi: failed to synchronize thermal read
>
> and returns -ETIMEDOUT. Tools that read all hwmon sensors, such as
> lm-sensors, hang for 5 s on every run, and configuration changes of the
> interface wait for conf_mutex in the meantime.
>
> Whether the firmware answers cannot be told from the chip: firmware that
> answers and firmware that does not both advertise
> WMI_SERVICE_THERM_THROT, and WCN3990 firmware differs between devices.
> Instead, remember that the running firmware did not answer, and return
> -EOPNOTSUPP right away on later reads. Forget it when the firmware
> starts, so that a restarted or updated firmware is asked again.
>
> The first read after each firmware start still takes 5 s when the
> firmware does not answer. Reads on firmware that answers are unchanged.
>
> This change was written with the help of an AI coding assistant; see
> the notes below.
>
> Fixes: e98199a8c27f ("ath10k: enable QCA6174/QCA9377 to read the chip temperature")
> Signed-off-by: Filippo Falezza <effeffe99@gmail.com>

Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>

> ---
> Hello there,
>
> this is v2 of the fix for ath10k temperature reads that stall for 5 s
> on firmware that never answers the request, as on the WCN3990 firmware
> of a Motorola Moto G 5G Plus (SM7250).
>
> The only change from v1 is the name of the flag: it is now
> ath10k_thermal.broken, as Loic suggested, instead of
> temperature_unanswered. The behaviour is the same, so the testing from
> v1 still applies: on the phone, the first read after the firmware
> starts times out once after 5 s, every later read returns -EOPNOTSUPP
> within milliseconds, and a full `sensors` run takes 25 ms instead of
> 5 s or more. Restarting Wi-Fi makes the driver ask the firmware again.
> I have not tested firmware that answers the request.
>
> v2 builds with W=1 for arm64 and is checkpatch --strict clean, on top
> of ath-next (cd026e68fdbf).
>
> As with v1, I wrote this with the help of an AI coding assistant
> (Claude Code); the testing is on the phone.
>
> Thanks,
> Filippo
> ---
> Changes in v2:
> - Rename temperature_unanswered to broken, as suggested by Loic Poulain.
> - Link to v1: https://patch.msgid.link/20261026-ath10k-temperature-v1-1-e5cd6fde7f1e@gmail.com
> ---
>  drivers/net/wireless/ath/ath10k/core.c    | 1 +
>  drivers/net/wireless/ath/ath10k/thermal.c | 9 ++++++++-
>  drivers/net/wireless/ath/ath10k/thermal.h | 2 ++
>  3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 7c2939cbde5f..a749ae582b0a 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2985,6 +2985,7 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
>         clear_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
>
>         ar->running_fw = fw;
> +       ar->thermal.broken = false;
>
>         if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
>                       ar->running_fw->fw_file.fw_features)) {
> diff --git a/drivers/net/wireless/ath/ath10k/thermal.c b/drivers/net/wireless/ath/ath10k/thermal.c
> index 9bb486f8e920..9ff7de0abd12 100644
> --- a/drivers/net/wireless/ath/ath10k/thermal.c
> +++ b/drivers/net/wireless/ath/ath10k/thermal.c
> @@ -75,6 +75,12 @@ static ssize_t ath10k_thermal_show_temp(struct device *dev,
>                 goto out;
>         }
>
> +       /* Don't stall every read on firmware that never answers */
> +       if (ar->thermal.broken) {
> +               ret = -EOPNOTSUPP;
> +               goto out;
> +       }
> +
>         reinit_completion(&ar->thermal.wmi_sync);
>         ret = ath10k_wmi_pdev_get_temperature(ar);
>         if (ret) {
> @@ -90,7 +96,8 @@ static ssize_t ath10k_thermal_show_temp(struct device *dev,
>         time_left = wait_for_completion_timeout(&ar->thermal.wmi_sync,
>                                                 ATH10K_THERMAL_SYNC_TIMEOUT_HZ);
>         if (!time_left) {
> -               ath10k_warn(ar, "failed to synchronize thermal read\n");
> +               ath10k_warn(ar, "failed to synchronize thermal read, not asking again until the firmware restarts\n");
> +               ar->thermal.broken = true;
>                 ret = -ETIMEDOUT;
>                 goto out;
>         }
> diff --git a/drivers/net/wireless/ath/ath10k/thermal.h b/drivers/net/wireless/ath/ath10k/thermal.h
> index 1f4de9fbf2b3..d1fb5b958c37 100644
> --- a/drivers/net/wireless/ath/ath10k/thermal.h
> +++ b/drivers/net/wireless/ath/ath10k/thermal.h
> @@ -19,6 +19,8 @@ struct ath10k_thermal {
>         /* protected by conf_mutex */
>         u32 throttle_state;
>         u32 quiet_period;
> +       /* the running firmware did not answer a temperature request */
> +       bool broken;
>         /* temperature value in Celsius degree
>          * protected by data_lock
>          */
>
> ---
> base-commit: cd026e68fdbf88b9cc522b76c7a9d92c9a41f709
> change-id: 20261022-ath10k-temperature-22b119fd615c
>
> Best regards,
> --
> Filippo Falezza <effeffe99@gmail.com>
>

Re: [PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Jeff Johnson]

On 10/26/2026 6:56 PM, Filippo Falezza wrote:
> Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
> waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
> holding conf_mutex. Not all firmware answers: the WCN3990 firmware
> WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
> codename nairo (SM7250) never sends the event, so every read of
> temp1_input stalls for 5 s, logs
> 
>   ath10k_snoc 18800000.wifi: failed to synchronize thermal read
> 
> and returns -ETIMEDOUT. Tools that read all hwmon sensors, such as
> lm-sensors, hang for 5 s on every run, and configuration changes of the
> interface wait for conf_mutex in the meantime.
> 
> Whether the firmware answers cannot be told from the chip: firmware that
> answers and firmware that does not both advertise
> WMI_SERVICE_THERM_THROT, and WCN3990 firmware differs between devices.
> Instead, remember that the running firmware did not answer, and return
> -EOPNOTSUPP right away on later reads. Forget it when the firmware
> starts, so that a restarted or updated firmware is asked again.
> 
> The first read after each firmware start still takes 5 s when the
> firmware does not answer. Reads on firmware that answers are unchanged.
> 
> This change was written with the help of an AI coding assistant; see
> the notes below.

I've dropped this paragraph from the commit text since it doesn't add value to
the git history. The final commit will have a link to the e-mail thread which 
will still document the LLM usage.

pending patch:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=407f3916cca45de3720a93703d28b047920e6230

> 
> Fixes: e98199a8c27f ("ath10k: enable QCA6174/QCA9377 to read the chip temperature")
> Signed-off-by: Filippo Falezza <effeffe99@gmail.com>

Re: [PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Jeff Johnson]

On Tue, 27 Oct 2026 01:56:20 +0000, Filippo Falezza wrote:
> Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
> waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
> holding conf_mutex. Not all firmware answers: the WCN3990 firmware
> WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
> codename nairo (SM7250) never sends the event, so every read of
> temp1_input stalls for 5 s, logs
> 
> [...]

Applied, thanks!

[1/1] wifi: ath10k: Stop unanswered temperature reads
      commit: 2a87e367c62856b87a90f745c6b7d2eb91e0c51f

Best regards,
-- 
Jeff Johnson <jeff.johnson@oss.qualcomm.com>

Re: [PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Nicolas Escande]

On Tue Oct 27, 2026 at 2:56 AM CET, Filippo Falezza wrote:
> Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
> waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
> holding conf_mutex. Not all firmware answers: the WCN3990 firmware
> WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
> codename nairo (SM7250) never sends the event, so every read of
> temp1_input stalls for 5 s, logs
>
>   ath10k_snoc 18800000.wifi: failed to synchronize thermal read
>
> and returns -ETIMEDOUT. Tools that read all hwmon sensors, such as
> lm-sensors, hang for 5 s on every run, and configuration changes of the
> interface wait for conf_mutex in the meantime.
>
> Whether the firmware answers cannot be told from the chip: firmware that
> answers and firmware that does not both advertise
> WMI_SERVICE_THERM_THROT, and WCN3990 firmware differs between devices.
> Instead, remember that the running firmware did not answer, and return
> -EOPNOTSUPP right away on later reads. Forget it when the firmware
> starts, so that a restarted or updated firmware is asked again.
>
> The first read after each firmware start still takes 5 s when the
> firmware does not answer. Reads on firmware that answers are unchanged.
>
[...]

Hello,

I've just now seen this and it will break some setups. It seems that some ath10k
devices that usually respond to the thermal WMI messages sometimes do not.
This is from a QCA9888 that does not have your patch yet:

[431710.509443] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
[433385.529449] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
[434755.541438] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
[435385.549438] ath10k_pci 0000:01:00.0: failed to synchronize thermal read

Like you I have a daemon that reads the sensor periodically and it seldom
fails to read the sensor value for whatever reason. Most of the time it works.
With your patch once I've hit this, I will never have a valid reading anymore.

So how about I post a new patch that only fully disable sending when we have
like 3 consecutive read fails, and in the mean time I can also lower
ATH10K_THERMAL_SYNC_TIMEOUT_HZ to 1s or so so it doesn't lock up for too long ?

Jeff / Loic is that ok or do you have any other suggestion ?

Thanks

Re: [PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Loic Poulain]

Hi Nicolas,

On Tue, Nov 10, 2026 at 6:20 PM Nicolas Escande <nico.escande@gmail.com> wrote:
>
> On Tue Oct 27, 2026 at 2:56 AM CET, Filippo Falezza wrote:
> > Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
> > waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
> > holding conf_mutex. Not all firmware answers: the WCN3990 firmware
> > WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
> > codename nairo (SM7250) never sends the event, so every read of
> > temp1_input stalls for 5 s, logs
> >
> >   ath10k_snoc 18800000.wifi: failed to synchronize thermal read
> >
> > and returns -ETIMEDOUT. Tools that read all hwmon sensors, such as
> > lm-sensors, hang for 5 s on every run, and configuration changes of the
> > interface wait for conf_mutex in the meantime.
> >
> > Whether the firmware answers cannot be told from the chip: firmware that
> > answers and firmware that does not both advertise
> > WMI_SERVICE_THERM_THROT, and WCN3990 firmware differs between devices.
> > Instead, remember that the running firmware did not answer, and return
> > -EOPNOTSUPP right away on later reads. Forget it when the firmware
> > starts, so that a restarted or updated firmware is asked again.
> >
> > The first read after each firmware start still takes 5 s when the
> > firmware does not answer. Reads on firmware that answers are unchanged.
> >
> [...]
>
> Hello,
>
> I've just now seen this and it will break some setups. It seems that some ath10k
> devices that usually respond to the thermal WMI messages sometimes do not.
> This is from a QCA9888 that does not have your patch yet:
>
> [431710.509443] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> [433385.529449] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> [434755.541438] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> [435385.549438] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
>
> Like you I have a daemon that reads the sensor periodically and it seldom
> fails to read the sensor value for whatever reason. Most of the time it works.
> With your patch once I've hit this, I will never have a valid reading anymore.
>
> So how about I post a new patch that only fully disable sending when we have
> like 3 consecutive read fails, and in the mean time I can also lower
> ATH10K_THERMAL_SYNC_TIMEOUT_HZ to 1s or so so it doesn't lock up for too long ?
>
> Jeff / Loic is that ok or do you have any other suggestion ?

I'm not particularly comfortable with such a solution but since we're
already introduced a workaround, I think this is an acceptable
approach.

Would it be possible to implement the retry loop directly inside
thermal_show_temp()? A one-second timeout seems more than sufficient
to read a thermistor but it would also be useful to include some
information about the typical read time for this kind of request,
along with the timeout change. I assume the actual read time is well
below one second.

On the other side, since you've been experiencing sporadic thermal
reading issues, have you also tried increasing the timeout to see
whether that helps?

I think including these details and any relevant measurements in the
patch description would be valuable.

Regards,
Loic

Re: [PATCH v2] wifi: ath10k: Stop unanswered temperature reads

[Jeff Johnson]

On 11/10/2026 9:20 AM, Nicolas Escande wrote:
> On Tue Oct 27, 2026 at 2:56 AM CET, Filippo Falezza wrote:
>> Reading the ath10k hwmon temperature sends WMI_PDEV_GET_TEMPERATURE and
>> waits up to 5 s (ATH10K_THERMAL_SYNC_TIMEOUT_HZ) for the reply event,
>> holding conf_mutex. Not all firmware answers: the WCN3990 firmware
>> WLAN.HL.3.3.1-00694-QCAHLSWMTPLZ-1 on a Motorola Moto G 5G Plus
>> codename nairo (SM7250) never sends the event, so every read of
>> temp1_input stalls for 5 s, logs
>>
>>   ath10k_snoc 18800000.wifi: failed to synchronize thermal read
>>
>> and returns -ETIMEDOUT. Tools that read all hwmon sensors, such as
>> lm-sensors, hang for 5 s on every run, and configuration changes of the
>> interface wait for conf_mutex in the meantime.
>>
>> Whether the firmware answers cannot be told from the chip: firmware that
>> answers and firmware that does not both advertise
>> WMI_SERVICE_THERM_THROT, and WCN3990 firmware differs between devices.
>> Instead, remember that the running firmware did not answer, and return
>> -EOPNOTSUPP right away on later reads. Forget it when the firmware
>> starts, so that a restarted or updated firmware is asked again.
>>
>> The first read after each firmware start still takes 5 s when the
>> firmware does not answer. Reads on firmware that answers are unchanged.
>>
> [...]
> 
> Hello,
> 
> I've just now seen this and it will break some setups. It seems that some ath10k
> devices that usually respond to the thermal WMI messages sometimes do not.
> This is from a QCA9888 that does not have your patch yet:
> 
> [431710.509443] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> [433385.529449] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> [434755.541438] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> [435385.549438] ath10k_pci 0000:01:00.0: failed to synchronize thermal read
> 
> Like you I have a daemon that reads the sensor periodically and it seldom
> fails to read the sensor value for whatever reason. Most of the time it works.
> With your patch once I've hit this, I will never have a valid reading anymore.
> 
> So how about I post a new patch that only fully disable sending when we have
> like 3 consecutive read fails, and in the mean time I can also lower
> ATH10K_THERMAL_SYNC_TIMEOUT_HZ to 1s or so so it doesn't lock up for too long ?
> 
> Jeff / Loic is that ok or do you have any other suggestion ?
My thinking is that based upon your logs we should never disable the logic if
the firmware ever replied.

I'm also in favor of tuning the timeout based upon whatever empirical data is
available.

/jeff