On 03/07/2024 17:12, Daniel Lezcano wrote:
On 03/07/2024 16:42, neil.armstrong@xxxxxxxxxx wrote:
On 03/07/2024 16:00, Daniel Lezcano wrote:
On 03/07/2024 14:43, neil.armstrong@xxxxxxxxxx wrote:
Hi,
On 03/07/2024 14:25, Daniel Lezcano wrote:
Hi Neil,
it seems there is something wrong with the driver actually.
There can be a moment where the sensor is not yet initialized for different reason, so reading the temperature fails. The routine will just retry until the sensor gets ready.
Having these errors seem to me that the sensor for this specific thermal zone is never ready which may be the root cause of your issue. The change is spotting this problem IMO.
Probably, but it gets printed every second until system shutdown, but only for a single thermal_zone.
Using v1 of Rafael's patch makes the message disappear completely.
Yes, because you have probably the thermal zone polling delay set to zero, thus it fails the first time and does no longer try to set it up again. The V1 is an incomplete fix.
Very likely the problem is in the sensor platform driver, or in the thermal zone description in the device tree which describes a non functional thermal zone.
It was at 0 but the delay was removed recently:
https://lore.kernel.org/all/20240510-topic-msm-polling-cleanup-v2-0-436ca4218da2@xxxxxxxxxx/
Yes, these changes are because another change did:
commit 488164006a281986d95abbc4b26e340c19c4c85b
Author: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
thermal/of: Assume polling-delay(-passive) 0 when absent
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
That doesn't explain it because only the last platforms have this error message printed.
Let me recap.
It has been reported if a thermal-zone with zero delay fails to initialize because the sensor returns an error, then there is no more attempt to initialize it and the thermal zone won't be functional.
The provided fix will periodically read the sensor temperature until there is a valid temperature. When there is a valid temperature, then the interrupts are set for the previous and the next temperature thresholds. That leads to the end of the routine of initializing the thermal zone and cancels the timer.
The platforms you reported, the delay is zero (before and after the 'polling cleanup').
My hypothesis is the following:
The thermal-zone29 describes a sensor which does not operate.
Before the patch:
First attempt to initialize it, the temperature is invalid, then because the delay is zero, the routine stops, and there is no more attempts to initialize it. Nothing will happen to this thermal zone and it will stay stuck silently. So at this point, the thermal zone is broken and you don't notice it.
After the patch:
The initialization routine is constantly retrying to init the thermal zone.
-------------------
If you revert the fix and you try to read the thermal zone 29, it should always fail to return an error.
If I'm correct, then I suggest to identify what thermal zone is 29 (type file), identify the node name in the DT, find the tsens channel and double check if it really describes an existing sensor
OK I just found out, it's the `qcom-battmgr-bat` thermal zone, and in CI we do not have the firmwares so the
temperature is never available, this is why it fails in a loop.
Before this patch it would fail silently, but would be useless if we start the firmware too late.
So since it's firmware based, valid data could arrive very late in the boot stage, and sending an
error message in a loop until the firmware isn't started doesn't seem right.
I think Rafael's new patch is good, but perhaps it should send an error when it finally stops monitoring.
Neil
