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

On 29/07/2026 13:54, Anvesh Jain P wrote:
> 
> 
> On 7/29/2026 4:38 PM, Krzysztof Kozlowski wrote:
>> On 28/07/2026 19:44, 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.
>>>
>>> The generic thermal-sensors property has no standard semantic for
>>> selecting a range of sensor IDs from a provider without enumerating
>>> each one, so a vendor-specific phandle-array with an explicit sensor
>>> count is used instead.
>>>
>>> Signed-off-by: Anvesh Jain P <[email protected]>
>>> ---
>>>  .../embedded-controller/qcom,hamoa-crd-ec.yaml     | 31 ++++++++++++++++++++++
>>>  1 file changed, 31 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
>>> index c07483aa5937..ec809fcd03ab 100644
>>> --- a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
>>> +++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
>>> @@ -33,11 +33,40 @@ properties:
>>>    interrupts:
>>>      maxItems: 1
>>>  
>>> +  # A generic "thermal-sensors" phandle only identifies individual sensor
>>> +  # IDs, and thermal zones are a Linux-side grouping of those sensors, not
>>> +  # a devicetree concept the EC cares about. What the driver actually needs
>>> +  # is raw readings from a contiguous range of leading sensor IDs on each
>>> +  # tsens provider, averaged together, so qcom,tsens pairs each provider
>>> +  # phandle with a count instead of enumerating every sensor cell.
>>> +  qcom,tsens:
>>
>>
>> What is the point of having internal review and then IGNORE that review?
>>
>> NAK
>>
>> Best regards,
>> Krzysztof
> 
> Krzysztof — for context: I did move to thermal-sensors after your
> review, but Konrad separately suggested keeping just the provider
> phandle instead of enumerating every sensor cell, since we only need a
> leading range per provider. qcom,tsens was meant to combine both
> suggestions, not ignore yours. Happy to instead just go with your
> original suggestion and use plain thermal-sensors, enumerating each
> sensor — let me know which you'd prefer.

How does <"thermal-sensors" phandle only identifies individual sensor>
and this phandlel does not? I see absolutely no difference thus you
duplicated the property, which I EXPLICITLY asked NOT TO during internal
review.



Best regards,
Krzysztof