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

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

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@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.

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 ?