[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