[PATCH v2 1/3] dt-bindings: soc: ti: Document the ti,tda54-mcu-scm-conf binding
Moteen Shah
m-shah at ti.com
Mon Nov 2 02:48:16 PST 2026
On 02/11/26 12:34, Krzysztof Kozlowski wrote:
> On 02/11/2026 06:20, Moteen Shah wrote:
>>>> + ti,proxy-id:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>> + minimum: 0
>>>> + maximum: 7
>>>> + description:
>>>> + Proxy region (0-7) through which this node's clients access
>>>> + claimable registers and their fault status registers.
>>> I don't get the need of this property. You have a one, specific device, so
>>> why the proxy id would vary per board?
>>>
>>> It also looks like re-implementing access controllers.
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Thanks for the review, Krzysztof. I’ll drop the redundant “binding” from
>> the subject.
>>
>> ti,proxy-id is not intended to vary by board. It selects the proxy
> Then it is implied by compatible, no?
>
>> window used by this Linux instance. One use case we need to support is
>> running two VMs with different proxy IDs, with each VM’s DT describing
>> the proxy it uses.
>> The driver reads the ID from DT and performs register accesses through
>> that proxy; it does not allocate proxy IDs or decide which VM uses which
>> one.
> And if not, my statement still feels applicable.
I think my previous reply did not explain why this property belongs in
the binding.
In the current design, reg describes the SCM region and ti,proxy-id
selects one of its proxy windows for this Linux instance. The compatible
describes the SCM hardware; it does not select a proxy window. Our use
case is separate VM DTs for two Linux instances using different proxy
IDs. For a single non-virtualized Linux instance, the DT has one fixed
ID but it can differ between VM instances. The property selects the view
used by the driver; it does not allocate or grant access to a proxy. The
information to the driver about the proxy via which it is supposed to
perform the claim/lock operations, need to be supplied for a particular
VM instance. I think DT would be the right way to do it. If you think
some other way would be better please feel free to suggest.
Regards,
Moteen
More information about the linux-arm-kernel
mailing list