Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230608-sitting-bath-31eddc03c5a5@spud> <168624654839.3085745.9088493205796442132.robh@kernel.org>
 <20230608-unlucky-carpenter-b3a95f269712@spud>
In-Reply-To: <20230608-unlucky-carpenter-b3a95f269712@spud>
From:   Rob Herring <robh@kernel.org>
Date:   Fri, 9 Jun 2023 08:03:44 -0600
Message-ID: <CAL_JsqK8pr5itTr8xTOf=h7zOan6giGsQcwQ-zUCbjtpUsosfw@mail.gmail.com>
Subject: Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa
To:     Conor Dooley <conor@kernel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor.dooley@microchip.com>,
        Oleksii <oleksii.kurochko@gmail.com>,
        Anup Patel <apatel@ventanamicro.com>, qemu-riscv@nongnu.org,
        u-boot@lists.denx.de, Andrew Jones <ajones@ventanamicro.com>,
        palmer@dabbelt.com, Atish Patra <atishp@atishpatra.org>,
        Jessica Clarke <jrtc27@jrtc27.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
        Rick Chen <rick@andestech.com>, linux-kernel@vger.kernel.org,
        Leo <ycliang@andestech.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Jun 8, 2023 at 12:05=E2=80=AFPM Conor Dooley <conor@kernel.org> wro=
te:
>
> On Thu, Jun 08, 2023 at 11:49:08AM -0600, Rob Herring wrote:
> > On Thu, 08 Jun 2023 17:54:05 +0100, Conor Dooley wrote:
>
> > > As a result of implementing Sean's suggestion, I believe I need to ad=
d
> > > riscv,isa-extensions as an exception to the rules preventing vendor
> > > properties being of object type, otherwise dt_binding_check is less t=
han
> > > happy with me.
>
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings=
/riscv/extensions.yaml: properties:riscv,isa-extensions: 'oneOf' conditiona=
l failed, one must be fixed:
> >       Additional properties are not allowed ('additionalProperties', 'p=
roperties' were unexpected)
> >               hint: A vendor boolean property can use "type: boolean"
> >       /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bi=
ndings/riscv/extensions.yaml: properties:riscv,isa-extensions: 'oneOf' cond=
itional failed, one must be fixed:
> >               'enum' is a required property
> >               'const' is a required property
> >               hint: A vendor string property with exact values has an i=
mplicit type
> >               from schema $id: http://devicetree.org/meta-schemas/vendo=
r-props.yaml#
> >       Additional properties are not allowed ('additionalProperties', 'p=
roperties', 'type' were unexpected)
> >               hint: A vendor string property with exact values has an i=
mplicit type
> >       /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bi=
ndings/riscv/extensions.yaml: properties:riscv,isa-extensions: 'oneOf' cond=
itional failed, one must be fixed:
> >               '$ref' is a required property
> >               'allOf' is a required property
> >               hint: A vendor property needs a $ref to types.yaml
> >               from schema $id: http://devicetree.org/meta-schemas/vendo=
r-props.yaml#
> >       'boolean' was expected
> >               hint: A vendor boolean property can use "type: boolean"
> >       hint: Vendor specific properties must have a type and description=
 unless they have a defined, common suffix.
> >       from schema $id: http://devicetree.org/meta-schemas/vendor-props.=
yaml#
>
> Yeah, expected. I think I need an exception in vendor-props for this to
> pass the checks.

Nope, vendor prefixes don't go in node names. That's not explicit
anywhere, but goes against using generic node names.

Also, note that looking at the DT spec, there's already prior art here
with PPC. See "power-isa-*". Though that appears in .dts files, but no
kernel code. Maybe you already saw that as your v1 is similar. There's
not really much advantage to align with it, but also not much reason
to deviate.

Rob