linux-kernel - Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

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_JsqJpp2iF-wRWuEuCuTjRsOKD_K7kjyRQq6iNGmjdGJqpuQ@mail.gmail.com>
Date:   Fri, 20 Apr 2018 20:34:16 -0500
From:   Rob Herring <robh@...nel.org>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     devicetree-spec@...r.kernel.org, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Grant Likely <grant.likely@....com>,
        Frank Rowand <frowand.list@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linus Walleij <linus.walleij@...aro.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Jonathan Cameron <jic23@...nel.org>
Subject: Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

On Fri, Apr 20, 2018 at 6:41 PM, Stephen Boyd <sboyd@...nel.org> wrote:
> Quoting Rob Herring (2018-04-20 11:15:04)
>> On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd <sboyd@...nel.org> wrote:
>> > Quoting Rob Herring (2018-04-18 15:29:05)
>> >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml
>> >> new file mode 100644
>> >> index 000000000000..fe0a3bd1668e
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/example-schema.yaml
>> >> @@ -0,0 +1,149 @@
>> >> +
>> >> +  The end of the description is marked by indentation less than the first line
>> >> +  in the description.
>> >> +
>> >> +select: false
>> >> +  # 'select' is a schema applied to a DT node to determine if this binding
>> >> +  # schema should be applied to the node. It is optional and by default the
>> >> +  # possible compatible strings are extracted and used to match.
>> >
>> > Can we get a concrete example here?
>>
>> select: true
>>
>> :) Which is apply to every node.
>>
>> A better one is from the memory node schema ('$nodename' gets added :
>>
>> select:
>>   required: ["$nodename"]
>>   properties:
>>     $nodename:
>>       oneOf:
>>         - pattern: "^memory@[0-9a-f]*"
>>         - const: "memory" # 'memory' only allowed for selecting
>>
>>
>> I expect the vast majority of device bindings will not use select at
>> all and rely on compatible string matching.
>
> Thanks! I was looking to see how the select syntax would work and this
> shows one example nicely. I suppose another way would be to show how a
> compatible string would be matched through select, even though it's
> redundant.
>
> Is there a way we can enforce node names through the schema too? For
> example to enforce that a clock controller is called 'clock-controller'
> or a spi master is called 'spi'.

Yes, that's something I'd like to do. I think the easiest is to just
treat node name as a property. We already generate a $nodename
property when parsing the yaml format DT.

>>
>> >> +
>> >> +properties:
>> > [...]
>> >> +
>> >> +  interrupts:
>> >> +    # Either 1 or 2 interrupts can be present
>> >> +    minItems: 1
>> >> +    maxItems: 2
>> >> +    items:
>> >> +      - description: tx or combined interrupt
>> >> +      - description: rx interrupt
>> >> +
>> >> +    description: |
>> >
>> > The '|' is needed to make yaml happy?
>>
>> Yes, this is simply how you do literal text blocks in yaml.
>>
>> We don't really need for this one really, but for the top-level
>> 'description' we do. The long term intent is 'description' would be
>> written in sphinx/rst and can be extracted into the DT spec (for
>> common bindings). Grant has experimented with that some.
>
> Ok. That sounds cool. Then we could embed links to datasheets and SVGs
> too.
>
>>
>> >> +      A variable number of interrupts warrants a description of what conditions
>> >> +      affect the number of interrupts. Otherwise, descriptions on standard
>> >> +      properties are not necessary.
>> >> +
>> >> +  interrupt-names:
>> >> +    # minItems must be specified here because the default would be 2
>> >> +    minItems: 1
>> >> +    items:
>> >> +      - const: "tx irq"
>> >> +      - const: "rx irq"
>> >> +
>> >> +  # Property names starting with '#' must be quoted
>> >> +  '#interrupt-cells':
>> >> +    # A simple case where the value must always be '2'.
>> >> +    # The core schema handles that this must be a single integer.
>> >> +    const: 2
>> >> +
>> >> +  interrupt-controller: {}
>> >
>> > Does '{}' mean nothing to see here?
>>
>> Yes. It's just an empty schema that's always valid.
>
> Could we include another schema to indicate that this is an interrupt
> controller? I'm sort of asking for multi-schema inheritance.

Yes, but there's no need to do that here. Another schema can select on
"interrupt-controller" property and be applied independently. There's
already an example of that for the root node in my yaml-bindings repo.

Rob