linux-kernel - Re: [PATCH v2 31/31] arm64: dts: qcom: sm8650-*: Remove thermal zone polling delays

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]

Date: Thu, 6 Jun 2024 12:50:14 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, cros-qcom-dts-watchers@...omium.org,
 Krzysztof Kozlowski <krzk+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 31/31] arm64: dts: qcom: sm8650-*: Remove thermal zone
 polling delays

On 10.05.2024 2:47 PM, Bryan O'Donoghue wrote:
> On 10/05/2024 12:59, Konrad Dybcio wrote:
>> All of the thermal zone suppliers are interrupt-driven, remove the
>> bogus and unnecessary polling that only wastes CPU time.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/sm8650.dtsi | 88 +++++++-----------------------------
>>   1 file changed, 16 insertions(+), 72 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> index 62a6e77730bc..39e789b21acc 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> @@ -5328,8 +5328,6 @@ compute-cb@12 {
>>         thermal-zones {
>>           aoss0-thermal {
>> -            polling-delay-passive = <0>;
>> -            polling-delay = <0>;
> 
> Commit log doesn't really match the values being subtracted
> 
> polling-delay:
>   $ref: /schemas/types.yaml#/definitions/uint32
>   description:
>     The maximum number of milliseconds to wait between polls when
>     checking this thermal zone. Setting this to 0 disables the polling
>     timers setup by the thermal framework and assumes that the thermal
>     sensors in this zone support interrupts.
> 

OK I suppose there are 3 things at play:

1) for devices with polling-delay = <non_zero> without this patchset, the
   polling is removed and threshold crossings are defered to the PMIC periph
   or TSENS interrupts

2) for devices with polling-delay = <0>, this is a NOP cleanup, saving LoC

3) for devices with polling-delay-passive = <0>, this is a NOP, however in 99%
   of cases, this was a misconfiguration in the first place. I can leave such
   entries so that somebody has an easier time spotting it down the line. I'm not
   however willing to go over each one of them and assess what the value should be,
   as that requires significant effort across tens of platforms

Konrad