| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <d8eb6652-18b5-4ed6-9a44-7c2a0f3bc3bb@linaro.org> Date: Thu, 25 Apr 2024 11:45:03 +0200 From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> To: Thierry Reding <thierry.reding@...il.com>, Sumit Gupta <sumitg@...dia.com>, robh@...nel.org, conor+dt@...nel.org, maz@...nel.org, mark.rutland@....com, treding@...dia.com, jonathanh@...dia.com Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org, amhetre@...dia.com, bbasu@...dia.com Subject: Re: [Patch v3 1/2] dt-bindings: make sid and broadcast reg optional 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@...dia.com> >>>>>> Signed-off-by: Sumit Gupta <sumitg@...dia.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
Powered by blists - more mailing lists