Re: [PATCH v2 00/31] Clean up thermal zone polling-delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/05/2024 12:59, Konrad Dybcio wrote:
A trivial follow-up on the changes introduced in Commit 488164006a28
("thermal/of: Assume polling-delay(-passive) 0 when absent").

Should probably wait until v6.9-rc1 so that the patch in question is
in the base tree, otherwise TZs will fail to register.

FWIW, Compile-tested only (except 8280).

To: Bjorn Andersson <andersson@xxxxxxxxxx>
To: Rob Herring <robh@xxxxxxxxxx>
To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>
To: Conor Dooley <conor+dt@xxxxxxxxxx>
To: cros-qcom-dts-watchers@xxxxxxxxxxxx
To: Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx
Cc: devicetree@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>

Changes in v2:
- Un-drop passive delays. Whether they're useful where they're enabled
   is a topic for another patchset, as it requires examination on a case-
   -by-case basis.
- Better unify the style (newlines between properties)
- Link to v1: https://lore.kernel.org/r/20240319-topic-msm-polling-cleanup-v1-0-e0aee1dbcd78@xxxxxxxxxx

So perhaps you can answer the question I have.

Right now, we have non-zero delay values, doesn't this mean the thermal framework driver has a delay between evaluating dT/dt values per

Documentation/devicetree/bindings/thermal/thermal-zones.yaml

Your commit log implies or my reading of it is, there's no functional change because its currently driven by an IRQ but, is that actually _so_ with non-zero values in the DT?

---
bod





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux