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