Re: #thermal-sensor-cells under protocol@15

On Tue, Jul 28, 2026 at 04:33:59PM +0200, Laszlo Ersek wrote:
> On 7/28/26 12:23, Sudeep Holla wrote:
> > On Tue, Jul 28, 2026 at 11:53:41AM +0200, Laszlo Ersek wrote:
> 
> > > And so describing protocol@15 in the Device Tree, without a
> > > #thermal-sensor-cells property, looks like a valid use case.
> > > 
> > 
> > No, unless you go back in time and find a replacement for
> > #thermal-sensor-cells and replace it w/o breaking any compatibility.
> > 
> > > Am I wrong?
> > > 
> > 
> > We need some property cell to be set to 1 to read the SCMI IDs. For
> > backward compatibility reasons, it will remain #thermal-sensor-cells.

My bad, I didn't remember all the context correct earlier today. The
cells property is not for the SCMI sensor itself, it is for the
consumer of this node which currently is only thermal subsystem.

> 
> (1) Are you saying that the property "#thermal-sensor-cells", under
> protocol@15, is actually a *misnomer* today, and it is in fact a
> *generic* specification of the Sensor ID width -- regardless of any
> referring stanzas elsewhere in the Device Tree (of which there may be
> none, or some may be thermal-UNrelated)?
> 

Not really, see my update above.

> (2) If so, would you accept a patch for
> "Documentation/devicetree/bindings/firmware/arm,scmi.yaml" that points
> out the above fact in a "description" yaml key?
> 

Not required for above mentioned reason.

> | diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> | index d06cca9273c4..78cc26ce0458 100644
> | --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> | +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> | @@ -223,20 +223,25 @@ properties:
> |    protocol@15:
> |      $ref: '#/$defs/protocol-node'
> |      unevaluatedProperties: false
> |
> |      properties:
> |        reg:
> |          const: 0x15
> |
> |        '#thermal-sensor-cells':
> |          const: 1
> | +        description:
> | +          The width of SCMI Sensor IDs, expressed as a number of 32-bit cells.
> | +          (The property name is an historical artifact, and counts nowadays as
> | +          a misnomer. The property is no longer specific to anything
> | +          "thermal".)
> |
> |      required:
> |        - '#thermal-sensor-cells'
> |
> |    protocol@16:
> |      $ref: '#/$defs/protocol-node'
> |      unevaluatedProperties: false
> |
> |      properties:
> |        reg:
> 
> (3) Where exactly does the kernel consume "#thermal-sensor-cells" in the
> proposed (general) sense?
> 

No where, I got confused earlier as mentioned above. It is not needed
unless you have use case. Please present if you have one.

> I can only find matches for the property name in
> "drivers/thermal/thermal_of.c" and
> "drivers/thermal/ti-soc-thermal/ti-thermal-common.c", but those appear
> like thermal drivers, not general SCMI stuff. AIUI,
> of_thermal_zone_find() in the former consults "#thermal-sensor-cells" in
> the "provider" (such as SCMI protocol@15) to figure out the expected
> argument cell count in the "thermal-sensors" list.
> 

Indeed, this made me recall all the details. Sorry I hadn't looked at
or touch this code in ages.

> But that implies that, if there ever was another (non-thermal) driver
> that wanted to reference SCMI sensor identifiers similarly, it would
> also have to consult "#thermal-sensor-cells", for the argument cell
> count. Which seems to support the idea that "#thermal-sensor-cells"
> counts as a misnomer today. Is that right?
> 

We could add new property if needed though we can specify it would be
mutually exclusive on systems that use #thermal-sensor-cells as it is
simply useless duplication of same information as it has to be 1.

> > > IMPORTANT NOTICE: [...]
> > 
> > Deleted now, please fix it for next time.
> 
> My bad, should be fixed now. (I've tested it with another external
> addressee.)
> 

Thanks.

-- 
Regards,
Sudeep