linux-kernel - Re: [PATCH v2] thermal: core: Call monitor_thermal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0c4b401e-86b8-4169-af88-475433012d67@linaro.org>
Date: Wed, 3 Jul 2024 17:12:12 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: neil.armstrong@...aro.org, "Rafael J. Wysocki" <rjw@...ysocki.net>,
 Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>,
 Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
 Zhang Rui <rui.zhang@...el.com>,
 linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2] thermal: core: Call monitor_thermal_zone() if zone
 temperature is invalid

On 03/07/2024 16:42, neil.armstrong@...aro.org wrote:
> On 03/07/2024 16:00, Daniel Lezcano wrote:
>> On 03/07/2024 14:43, neil.armstrong@...aro.org 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@linaro.org/

Yes, these changes are because another change did:

commit 488164006a281986d95abbc4b26e340c19c4c85b
Author: Konrad Dybcio <konrad.dybcio@...aro.org>

     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

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog