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

[Loic Poulain]

On Thu, Nov 12, 2026 at 5:46 PM Nicolas Escande <nico.escande at gmail.com> wrote:
>
> On Wed Nov 11, 2026 at 5:30 PM CET, Loic Poulain wrote:
> > 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
>
> I think that what Jeff suggested makes the most sense. If we ever had a valid
> response, never disable it.

Yes, that's a good suggestion. However, we still need to define when
to fail. If the first read attempt fails, how many retries should be
required before concluding that further polling is unlikely to
succeed?

In this case, the in-function retry mechanism could indeed be useful,
provided you can validate the behavior on your platform.

>
> I've tried in the past to increase it. But that leads nowhere, its not that we
> dont wait enough it's that it never comes. Or we missed it, I have no clue.
>
> Regarding the behavior of current chipsets. Ive added code to time how long it
> takes. From before the ath10k_wmi_pdev_get_temperature() to after the
> wait_for_completion_timeout() so my numbers are affected by the platform it runs
> on (cpu ranging from armv5 to A53 & A72). Here the numbers from multiple
> devices each running one of peregrine/besra/cascade
>
> ┌─────────┬──────────┬────────┬────────┬─────────┐
> │  Chip   │   Mean   │ Median │  Min   │   Max   │
> ├─────────┼──────────┼────────┼────────┼─────────┤
> │ QCA9984 │ 88.9 µs  │ 85 µs  │ 75 µs  │ 348 µs  │
> ├─────────┼──────────┼────────┼────────┼─────────┤
> │ QCA9888 │ 148.5 µs │ 142 µs │ 99 µs  │ 418 µs  │
> ├─────────┼──────────┼────────┼────────┼─────────┤
> │ QCA988x │ 205.7 µs │ 187 µs │ 108 µs │ 1193 µs │
> └─────────┴──────────┴────────┴────────┴─────────┘
>
> So for a sensible timeout value, I suggest a few ms, even 25ms or 100ms to have
> some margin. But maybe you guys have internal knowledge of the expected
> response time ?

The 100 ms timeout seems reasonable. However, will it actually help in
your case? You mentioned that the failures are sporadic. If we happen
to read the temperature at the "wrong" moment, is it likely that all
three retry attempts will fail as well, or would it be better to wait
a little longer before retrying the read?

In other words, do we expect a short retry loop to be sufficient, or
is the failure window long enough that spacing out the retries would
improve the chances of success?

Regards,
Loic