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

["Nicolas Escande" <nico.escande@gmail.com>]

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