Re: [Patch v3 1/2] dt-bindings: make sid and broadcast reg optional

Krzysztof Kozlowski
2024-04-25T09:45:07Z

On 25/04/2024 11:39, Thierry Reding wrote:
> On Thu Apr 25, 2024 at 9:52 AM CEST, Krzysztof Kozlowski wrote:
>> On 24/04/2024 19:04, Thierry Reding wrote:
>>> On Wed Apr 24, 2024 at 6:26 PM CEST, Thierry Reding wrote:
>>>> On Mon Apr 22, 2024 at 9:02 AM CEST, Krzysztof Kozlowski wrote:
>>>>> On 12/04/2024 15:05, Sumit Gupta wrote:
>>>>>> MC SID and Broadbast channel register access is restricted for Guest VM.
>>>>>
>>>>> Broadcast
>>>>>
>>>>>> Make both the regions as optional for SoC's from Tegra186 onwards.
>>>>>
>>>>> onward?
>>>>>
>>>>>> Tegra MC driver will skip access to the restricted registers from Guest
>>>>>> if the respective regions are not present in the memory-controller node
>>>>>> of Guest DT.
>>>>>>
>>>>>> Suggested-by: Thierry Reding <treding@nvidia.com>
>>>>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>>>>> ---
>>>>>> .../nvidia,tegra186-mc.yaml | 95 ++++++++++---------
>>>>>> 1 file changed, 49 insertions(+), 46 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
>>>>>> index 935d63d181d9..e0bd013ecca3 100644
>>>>>> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
>>>>>> @@ -34,11 +34,11 @@ properties:
>>>>>> - nvidia,tegra234-mc
>>>>>>
>>>>>> reg:
>>>>>> - minItems: 6
>>>>>> + minItems: 4
>>>>>> maxItems: 18
>>>>>>
>>>>>> reg-names:
>>>>>> - minItems: 6
>>>>>> + minItems: 4
>>>>>> maxItems: 18
>>>>>>
>>>>>> interrupts:
>>>>>> @@ -151,12 +151,13 @@ allOf:
>>>>>>
>>>>>> reg-names:
>>>>>> items:
>>>>>> - - const: sid
>>>>>> - - const: broadcast
>>>>>> - - const: ch0
>>>>>> - - const: ch1
>>>>>> - - const: ch2
>>>>>> - - const: ch3
>>>>>> + enum:
>>>>>> + - sid
>>>>>> + - broadcast
>>>>>> + - ch0
>>>>>> + - ch1
>>>>>> + - ch2
>>>>>> + - ch3
>>>>>
>>>>> I understand why sid and broadcast are becoming optional, but why order
>>>>> of the rest is now fully flexible?
>>>>
>>>> The reason why the order of the rest doesn't matter is because we have
>>>> both reg and reg-names properties and so the order in which they appear
>>>> in the list doesn't matter. The only thing that matters is that the
>>>> entries of the reg and reg-names properties match.
>>>>
>>>>> This does not even make sid/broadcast optional, but ch0!
>>>>
>>>> Yeah, this ends up making all entries optional, which isn't what we
>>>> want. I don't know of a way to accurately express this in json-schema,
>>>> though. Do you?
>>>>
>>>> If not, then maybe we need to resort to something like this and also
>>>> mention explicitly in some comment that it is sid and broadcast that are
>>>> optional.
>>>
>>> Actually, here's another variant that is a bit closer to what we want:
>>>
>>> --- >8 ---
>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
>>> index 935d63d181d9..86f1475926e4 100644
>>> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
>>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
>>> @@ -34,11 +34,11 @@ properties:
>>> - nvidia,tegra234-mc
>>>
>>> reg:
>>> - minItems: 6
>>> + minItems: 4
>>> maxItems: 18
>>>
>>> reg-names:
>>> - minItems: 6
>>> + minItems: 4
>>> maxItems: 18
>>>
>>> interrupts:
>>> @@ -146,17 +146,21 @@ allOf:
>>> then:
>>> properties:
>>> reg:
>>> + minItems: 4
>>> maxItems: 6
>>> description: 5 memory controller channels and 1 for stream-id registers
>>>
>>> reg-names:
>>> - items:
>>> - - const: sid
>>> - - const: broadcast
>>> - - const: ch0
>>> - - const: ch1
>>> - - const: ch2
>>> - - const: ch3
>>> + anyOf:
>>> + - items:
>>> + enum: [ sid, broadcast, ch0, ch1, ch2, ch3 ]
>>> + uniqueItems: true
>>> + minItems: 6
>>> +
>>> + - items:
>>> + enum: [ ch0, ch1, ch2, ch3 ]
>>> + uniqueItems: true
>>> + minItems: 4
>>>
>>> - if:
>>> properties:
>>> @@ -165,29 +169,22 @@ allOf:
>>> then:
>>> properties:
>>> reg:
>>> - minItems: 18
>>> + minItems: 16
>>> description: 17 memory controller channels and 1 for stream-id registers
>>>
>>> reg-names:
>>> - items:
>>> - - const: sid
>>> - - const: broadcast
>>> - - const: ch0
>>> - - const: ch1
>>> - - const: ch2
>>> - - const: ch3
>>> - - const: ch4
>>> - - const: ch5
>>> - - const: ch6
>>> - - const: ch7
>>> - - const: ch8
>>> - - const: ch9
>>> - - const: ch10
>>> - - const: ch11
>>> - - const: ch12
>>> - - const: ch13
>>> - - const: ch14
>>> - - const: ch15
>>> + anyOf:
>>> + - items:
>>> + enum: [ sid, broadcast, ch0, ch1, ch2, ch3, ch4, ch5, ch6, ch7,
>>> + ch8, ch9, ch10, ch11, ch12, ch13, ch14, ch15 ]
>>> + minItems: 18
>>> + uniqueItems: true
>>> +
>>> + - items:
>>> + enum: [ ch0, ch1, ch2, ch3, ch4, ch5, ch6, ch7, ch8, ch9, ch10,
>>> + ch11, ch12, ch13, ch14, ch15 ]
>>> + minItems: 16
>>> + uniqueItems: true
>>
>> No, because order is strict.
>
> Why? I realize that prior to this the order was indeed strict and it's

That's the policy for entire Devicetree. I said why in other email:
because any bindings consumer can take it via indices.

> common to have these listed in strict order in the DTS files. However,
> this is an arbitrary restriction that was introduced in the patch that
> added reg-names. However, */*-names properties have always assumed the
> ordering to be non-strict because each entry from the * property gets
> matched up with the corresponding entry in the *-names property, so the
> ordering is completely irrelevant.

This was raised so many times... reg-names is just a helper. It does not
change the fact that order should be strict and if binding defined the
order, it is an ABI.

Best regards,
Krzysztof