| 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: <9561dede-37d0-4183-8742-448058803f8e@linaro.org> Date: Thu, 25 Apr 2024 09:52:01 +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 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. .. > > The one restriction that it has is that "sid" and "broadcast" must be > optional together. So you can't have just "sid" or "broadcast", but they > either must both be there, or they must both not be there. > This must be explained in commit msg. Best regards, Krzysztof
Powered by blists - more mailing lists