Re: [PATCH 1/8] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add qcom,tsens

On 7/29/26 2:13 PM, Anvesh Jain P wrote:
> 
> 
> On 7/29/2026 4:43 PM, Konrad Dybcio wrote:
>> On 7/28/26 7:44 PM, Anvesh Jain P wrote:
>>> Add the qcom,tsens property so Hamoa-based boards can list the tsens
>>> providers, and how many leading sensor IDs on each, whose readings the
>>> driver averages to compute the SoC junction temperature reported to
>>> the EC for fan control.

[...]

>>> +  qcom,tsens:
>>> +    description:
>>> +      List of tsens providers and, for each, the number of leading sensor
>>> +      IDs on that provider whose readings are averaged to compute the SoC
>>> +      junction temperature reported to the EC for fan control. Only
>>> +      applicable for Hamoa based devices.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +    minItems: 1
>>> +    maxItems: 2
>>> +    items:
>>> +      items:
>>> +        - description: phandle to a tsens thermal-sensor provider
>>> +        - description: number of leading sensor IDs on that provider to average
>>
>> Why don't we want to look at all of the TSENS sensors?
>>
>> Konrad
> 
> Each tsens provider has more physical sensors (16) than the count used
> here. The leading N we take exactly matches the number of sensors
> already wired to board thermal-zones for other purposes (CPU clusters,
> GPU, camera, etc.) on that provider — e.g. on hamoa, tsens2 has 11 such
> zones and tsens3 has 15, matching qcom,tsens = <&tsens2 11>, <&tsens3
> 15>;. The remaining sensor IDs aren't referenced by any thermal-zone on
> this platform, so there's no per-purpose reading to include in the SoC
> Tj average.

What you said is true

It also doesn't answer the question why that isn't the case

Konrad