On Thu Apr 25, 2024 at 11:45 AM CEST, Krzysztof Kozlowski wrote: > 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@xxxxxxxxxx> > >>>>>> Signed-off-by: Sumit Gupta <sumitg@xxxxxxxxxx> > >>>>>> --- > >>>>>> .../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. Sorry, but that's not how we've dealt with this in the past. Even though this was now ten or more years ago, I distinctly recall that when we started adding these *-names properties and at the time it was very much implied that the order didn't matter. The only use-case that I know of where order was always meant to matter is backwards-compatibility for devices that used to have a single entry (hence drivers couldn't rely on *-names to resolve the index) and then had additional entries added. The *-names entry for that previously single entry would now obviously have to always be first in the list to preserve backwards-compatibility. Besides, if reg-names was really only a helper, then it would also be completely redundant. Many device tree bindings have *-names properties marked as "required" precisely because of the role that they serve. Thierry
Attachment:
signature.asc
Description: PGP signature
