linux-kernel - Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqK8pr5itTr8xTOf=h7zOan6giGsQcwQ-zUCbjtpUsosfw@mail.gmail.com>
Date:   Fri, 9 Jun 2023 08:03:44 -0600
From:   Rob Herring <robh@...nel.org>
To:     Conor Dooley <conor@...nel.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Oleksii <oleksii.kurochko@...il.com>,
        Anup Patel <apatel@...tanamicro.com>, qemu-riscv@...gnu.org,
        u-boot@...ts.denx.de, Andrew Jones <ajones@...tanamicro.com>,
        palmer@...belt.com, Atish Patra <atishp@...shpatra.org>,
        Jessica Clarke <jrtc27@...c27.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Alistair Francis <alistair.francis@....com>,
        devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
        Rick Chen <rick@...estech.com>, linux-kernel@...r.kernel.org,
        Leo <ycliang@...estech.com>
Subject: Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa

On Thu, Jun 8, 2023 at 12:05 PM Conor Dooley <conor@...nel.org> wrote:
>
> 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 add
> > > riscv,isa-extensions as an exception to the rules preventing vendor
> > > properties being of object type, otherwise dt_binding_check is less than
> > > happy with me.
>
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml: properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be fixed:
> >       Additional properties are not allowed ('additionalProperties', 'properties' were unexpected)
> >               hint: A vendor boolean property can use "type: boolean"
> >       /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml: properties:riscv,isa-extensions: 'oneOf' conditional 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 implicit type
> >               from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
> >       Additional properties are not allowed ('additionalProperties', 'properties', 'type' were unexpected)
> >               hint: A vendor string property with exact values has an implicit type
> >       /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml: properties:riscv,isa-extensions: 'oneOf' conditional 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/vendor-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