Received-SPF: pass (google.com: domain of linux-kernel+bounces-157313-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Content-Type: multipart/signed;
 boundary=6ba2911ab0d9061d591e2d0178dd10ab327ff50a605e39dd9da24fd42a86;
 micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: bulk
Mime-Version: 1.0
Date: Wed, 24 Apr 2024 18:26:01 +0200
Message-Id: <D0SHRQVCGJBY.2DPLX9K6VXEYM@gmail.com>
Cc: <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
 <linux-tegra@vger.kernel.org>, <amhetre@nvidia.com>, <bbasu@nvidia.com>
Subject: Re: [Patch v3 1/2] dt-bindings: make sid and broadcast reg optional
From: "Thierry Reding" <thierry.reding@gmail.com>
To: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>, "Sumit Gupta"
 <sumitg@nvidia.com>, <robh@kernel.org>, <conor+dt@kernel.org>,
 <maz@kernel.org>, <mark.rutland@arm.com>, <treding@nvidia.com>,
 <jonathanh@nvidia.com>
References: <20240412130540.28447-1-sumitg@nvidia.com>
 <20240412130540.28447-2-sumitg@nvidia.com>
 <d26f9661-3e50-4a72-9097-fe63a27503f1@linaro.org>
In-Reply-To: <d26f9661-3e50-4a72-9097-fe63a27503f1@linaro.org>

--6ba2911ab0d9061d591e2d0178dd10ab327ff50a605e39dd9da24fd42a86
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

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.
> >=20
> > 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(-)
> >=20
> > diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidi=
a,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/n=
vidia,tegra186-mc.yaml
> > index 935d63d181d9..e0bd013ecca3 100644
> > --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra=
186-mc.yaml
> > +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra=
186-mc.yaml
> > @@ -34,11 +34,11 @@ properties:
> >            - nvidia,tegra234-mc
> > =20
> >    reg:
> > -    minItems: 6
> > +    minItems: 4
> >      maxItems: 18
> > =20
> >    reg-names:
> > -    minItems: 6
> > +    minItems: 4
> >      maxItems: 18
> > =20
> >    interrupts:
> > @@ -151,12 +151,13 @@ allOf:
> > =20
> >          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.

Thierry

--6ba2911ab0d9061d591e2d0178dd10ab327ff50a605e39dd9da24fd42a86
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmYpMpoACgkQ3SOs138+
s6GyxxAAoN6Z69DQJQGqGUJCL6invi972MVm5AggYBlXmwj+NYR7dqdKsYmMBrG5
7o2ODlJotzRPauv3NHWwOPg0RwFZw8yMvgVtNnY2bAUzGJphP7tTO7pN+EzS9V9e
CX9tMg+8eUjO2ArnothckaFH4VFus1MAVOdcy0jm9HiE/9mj0L3sJ4Z+0PY6F29I
31X1nkWersqcSuPEc3fO7xCMge8hWBSIpl1DHFwZYcgfW1RvjzQ99VDC3fsW0zS1
9VTu0pDeWnh4LBpwk6NxD7mGjEhcbMH7Dh3vo11uqIF9eyXE3cLSEZjuWxbfea/a
HwOZpTQYq7yH3fsbxAQHPvKW85ZOvgpzdJiHEd2DdPrFjNY06+/xx0tSoHNS1bCN
T4AhOYLDMCyu7eh5uHqmLG9K7f6OpIZYkcgtAR+55z/IR2r6PLUKMXZcGtNK+L25
G736aaFvywp9xxpnWNAzmQZPMwTfGtiWVhJcVNG9tw0bjNhar6sJlfag0TQIeSOr
DDt7kNUuiypkyyfhTxXaeIpV2FU1hu8Xh0AmvpI/8xuSB4H6lm1ZW0hCE4zF0dyA
QSqG3aMEPTQ4BadPJvJ4rK6dlk9AHT9dEHdDeaG7AFGFMxmhXVpGaG+TmFNn+78x
x0RILdoILw1iKzZMhW2emocJXqfXBan7530waOFbXI3UT8RwIbQ=
=wRVU
-----END PGP SIGNATURE-----

--6ba2911ab0d9061d591e2d0178dd10ab327ff50a605e39dd9da24fd42a86--