Received-SPF: pass (google.com: domain of linux-kernel+bounces-158758-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Content-Type: multipart/signed;
 boundary=0a003b88e518e591a0130d80c72408215230c45ba769297ac394215a4c0d;
 micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: bulk
Mime-Version: 1.0
Date: Thu, 25 Apr 2024 17:03:46 +0200
Message-Id: <D0TANBDMJHH2.5XTXRZ09K4OU@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>
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>
References: <20240412130540.28447-1-sumitg@nvidia.com>
 <20240412130540.28447-2-sumitg@nvidia.com>
 <d26f9661-3e50-4a72-9097-fe63a27503f1@linaro.org>
 <D0SHRQVCGJBY.2DPLX9K6VXEYM@gmail.com>
 <D0SILCYU98EV.1XW7NZFC9013K@gmail.com>
 <9561dede-37d0-4183-8742-448058803f8e@linaro.org>
 <D0T3R7UPFO07.2VR2436TG4N8B@gmail.com>
 <d8eb6652-18b5-4ed6-9a44-7c2a0f3bc3bb@linaro.org>
In-Reply-To: <d8eb6652-18b5-4ed6-9a44-7c2a0f3bc3bb@linaro.org>

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

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 Gue=
st 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-controll=
ers/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
> >>>>>> =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 o=
rder
> >>>>> of the rest is now fully flexible?
> >>>>
> >>>> The reason why the order of the rest doesn't matter is because we ha=
ve
> >>>> both reg and reg-names properties and so the order in which they app=
ear
> >>>> 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-schem=
a,
> >>>> 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/nvi=
dia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers=
/nvidia,tegra186-mc.yaml
> >>> index 935d63d181d9..86f1475926e4 100644
> >>> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,teg=
ra186-mc.yaml
> >>> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,teg=
ra186-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:
> >>> @@ -146,17 +146,21 @@ allOf:
> >>>      then:
> >>>        properties:
> >>>          reg:
> >>> +          minItems: 4
> >>>            maxItems: 6
> >>>            description: 5 memory controller channels and 1 for stream=
-id registers
> >>> =20
> >>>          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
> >>> =20
> >>>    - if:
> >>>        properties:
> >>> @@ -165,29 +169,22 @@ allOf:
> >>>      then:
> >>>        properties:
> >>>          reg:
> >>> -          minItems: 18
> >>> +          minItems: 16
> >>>            description: 17 memory controller channels and 1 for strea=
m-id registers
> >>> =20
> >>>          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.
> >=20
> > 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

--0a003b88e518e591a0130d80c72408215230c45ba769297ac394215a4c0d
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmYqcNMACgkQ3SOs138+
s6FoSg//Wac2hlyCg8ZwVjTvYTsFfjus5REQ8iUcO81kHtEwiC884J27E5ufC9zu
Uadobj7eb4YC646DkI/qDwgYMLylrzQAfTTJcRvV+y/BRxH8P5cl3/SJh6gAf2cH
ER6pspuOwGmmkEGS4Q8JmlgQzZlg4y+SzGDT7YQRUKWa9B4xhRIeerVnZCpu3rmW
kvGNe0/cvkgYUwbyr1If/hJQN+QtEKIr+wxzRtPourIffXBLaXpJ2mxKltkU2DyO
hPusV7UJwdF3Mhlpp/G94XdiUDU5hPrZubcSV+iP+LtxZp+pth0HUGdAVypT7HKw
aaaJ7G7pf0jmgc9UR0WccqkT831B/ambW2LJW63Uy4l0oxcjEfXoFmLo5K4EixCt
vjxjvYK08T3kTgU0sXg1BBRhZfF3iryPFJQGqlvF4lszUOWQNxOgRZBmI8dn4wud
PYzz1orsFlOssa6tdhJ11M17cXPJ0xiH7XH3GUhWZZkUFoexqci9xsFYY4LH/n9U
GADqq3nVsY2hDZDDW8EFZKn82lTb+JWAoD+W9ItunRhzp71CmlzWA59lLd8ba/+n
NLFaWlt7fw0R2lmNDP/v0De/swQC/Sd3q1nVO9uI4Ymf03Gm1EfuaWD75oDEpbsn
qJy1EUqvwkh8cHJJDHnzP7i2jWhcEDahUNUwzJ8DZnU4rSKNKns=
=L5Ll
-----END PGP SIGNATURE-----

--0a003b88e518e591a0130d80c72408215230c45ba769297ac394215a4c0d--