Received-SPF: pass (google.com: domain of linux-kernel+bounces-140594-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 11 Apr 2024 16:04:36 +0200
Message-Id: <D0HCMDMWTO61.1F860N5I5SKS3@bootlin.com>
Cc: <linux-mips@vger.kernel.org>, <devicetree@vger.kernel.org>,
 <linux-kernel@vger.kernel.org>, <linux-clk@vger.kernel.org>,
 <linux-gpio@vger.kernel.org>, "Vladimir Kondratiev"
 <vladimir.kondratiev@mobileye.com>, "Gregory CLEMENT"
 <gregory.clement@bootlin.com>, "Thomas Petazzoni"
 <thomas.petazzoni@bootlin.com>, "Tawfik Bayouk"
 <tawfik.bayouk@mobileye.com>
To: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>, "Rob Herring"
 <robh@kernel.org>, "Krzysztof Kozlowski"
 <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>,
 "Michael Turquette" <mturquette@baylibre.com>, "Stephen Boyd"
 <sboyd@kernel.org>, "Philipp Zabel" <p.zabel@pengutronix.de>, "Linus
 Walleij" <linus.walleij@linaro.org>
From: =?utf-8?q?Th=C3=A9o_Lebrun?= <theo.lebrun@bootlin.com>
Subject: Re: [PATCH 03/11] dt-bindings: reset: mobileye,eyeq5-reset: add
 EyeQ6L and EyeQ6H
References: <20240410-mbly-olb-v1-0-335e496d7be3@bootlin.com>
 <20240410-mbly-olb-v1-3-335e496d7be3@bootlin.com>
 <975a8554-a299-4394-be15-c910cf9688ae@linaro.org>
In-Reply-To: <975a8554-a299-4394-be15-c910cf9688ae@linaro.org>

Hello,

On Thu Apr 11, 2024 at 8:14 AM CEST, Krzysztof Kozlowski wrote:
> On 10/04/2024 19:12, Th=C3=A9o Lebrun wrote:
> > Add bindings for EyeQ6L and EyeQ6H reset controllers.
> >=20
> > Some controllers host a single domain, meaning a single cell is enough.
> > We do not enforce reg-names for such nodes.
> >=20
> > Signed-off-by: Th=C3=A9o Lebrun <theo.lebrun@bootlin.com>
> > ---
> >  .../bindings/reset/mobileye,eyeq5-reset.yaml       | 88 ++++++++++++++=
++++----
> >  MAINTAINERS                                        |  1 +
> >  2 files changed, 74 insertions(+), 15 deletions(-)
> >=20
> > diff --git a/Documentation/devicetree/bindings/reset/mobileye,eyeq5-res=
et.yaml b/Documentation/devicetree/bindings/reset/mobileye,eyeq5-reset.yaml
> > index 062b4518347b..799bcf15bed9 100644
> > --- a/Documentation/devicetree/bindings/reset/mobileye,eyeq5-reset.yaml
> > +++ b/Documentation/devicetree/bindings/reset/mobileye,eyeq5-reset.yaml
> > @@ -4,11 +4,13 @@
> >  $id: http://devicetree.org/schemas/reset/mobileye,eyeq5-reset.yaml#
> >  $schema: http://devicetree.org/meta-schemas/core.yaml#
> > =20
> > -title: Mobileye EyeQ5 reset controller
> > +title: Mobileye EyeQ reset controller
> > =20
> >  description:
> > -  The EyeQ5 reset driver handles three reset domains. Its registers li=
ve in a
> > -  shared region called OLB.
> > +  EyeQ reset controller handles one or more reset domains. They live i=
n shared
> > +  regions called OLB. EyeQ5 and EyeQ6L host one OLB each, each with on=
e reset
> > +  instance. EyeQ6H hosts 7 OLB regions; three of those (west, east,
> > +  accelerator) host reset controllers. West and east are duplicates.
> > =20
> >  maintainers:
> >    - Gr=C3=A9gory Clement <gregory.clement@bootlin.com>
> > @@ -17,27 +19,83 @@ maintainers:
> > =20
> >  properties:
> >    compatible:
> > -    const: mobileye,eyeq5-reset
> > +    enum:
> > +      - mobileye,eyeq5-reset
> > +      - mobileye,eyeq6l-reset
> > +      - mobileye,eyeq6h-we-reset
> > +      - mobileye,eyeq6h-acc-reset
> > =20
> > -  reg:
> > -    maxItems: 3
> > +  reg: true
>
> Same mistakes. Please open existing bindings with multiple variants,
> e.g. some Qualcomm, and take a look how it is done there.

Thanks for the pointer to good example, that is useful! So if we take
one random binding matching
Documentation/devicetree/bindings/clock/qcom,*.yaml and that contains
the "reg-names" string, we see:

  reg:
    items:
      - description: LPASS qdsp6ss register
      - description: LPASS top-cc register

  reg-names:
    items:
      - const: qdsp6ss
      - const: top_cc

I don't understand one thing; this doesn't tell you:

   You can provide 2 MMIO blocks, which must be qdsp6ss and top_cc.

But it tells you:

   Block zero must be qdsp6ss.
   Block one must be top_cc.

If we do that I do not get the point of reg-names; we put more
information in our devicetree that is in any case imposed.

This is why I went with a different approach looking like:

  reg:
    minItems: 2
    maxItems: 2
  reg-names:
    minItems: 2
    maxItems: 2
    items:
      enum: [ d0, d1 ]

I know this is not perfect, but at least you don't enforce an order for
no reason. If "items: const..." approach should be taken, then I'll
remove reg-names which bring no benefit.

Thanks Krzysztof,

--
Th=C3=A9o Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com