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: <3a4299cf-b737-8e74-2e9e-994f5943d006@arm.com>
Date:   Wed, 25 Apr 2018 11:15:43 +0100
From:   Grant Likely <grant.likely@....com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Rob Herring <robh@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, devicetree-spec@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        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>, Stephen Boyd <sboyd@...nel.org>,
        Jonathan Cameron <jic23@...nel.org>
Subject: Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

On 23/04/2018 17:49, Geert Uytterhoeven wrote:
> Hi Grant,
>
> On Mon, Apr 23, 2018 at 4:47 PM, Grant Likely <grant.likely@....com> wrote:
>> On 21/04/2018 02:28, Rob Herring wrote:
>>> On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand <frowand.list@...il.com>
>>> wrote:
>>>>> +  interrupts:
>>>>> +    # Either 1 or 2 interrupts can be present
>>>>> +    minItems: 1
>>>>> +    maxItems: 2
>>>>> +    items:
>>>>> +      - description: tx or combined interrupt
>>>>> +      - description: rx interrupt
>>>>> +
>>>>> +    description: |
>>>>> +      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
>>>>
>>>> Why the difference between the interrupts property and the
>>>> interrupt-names
>>>> property (specifying maxItems for interrupt, but not interrupt-names)?
>>>
>>> I should probably have maxItems here too.
>>>
>>>> Others have already commented on a desire to have a way to specify that
>>>> number of interrupts should match number of interrupt-names.
>>>
>>> Yeah, but I don't see a way to do that. You could stick the array size
>>> constraints in a common definition and have a $ref to that definition
>>> from both, but that doesn't really save you too much.
>>
>>
>> There has been discussions in the jsonschema community regarding
>> referencing data in the document when applying the schema.
>>
>> https://github.com/json-schema-org/json-schema-spec/issues/549
>>
>> However, those discussions are ongoing and have been pushed back to
>> after draft-8 (the current release is draft-7). We can instead define
>> DT-specific keywords and extend the validator to make it do what we
>> want. We need to do something very similar to validate that the length
>> of tuples in 'reg', 'interrupts', and '*gpios' match the '#*-cells' values.
>
> Checking that property lengths match the corresponding #*-cells cannot
> be done for a schema, but only for the final DTS, as #*-cells is a property
> of the target node, right?

It can be done in the schema checking of the target node. For example,
given a GPIO specifier of:

gpios = <&gpio1 0> <&gpio2 4 1> <&gpio2 3 0>;

The validation engine could validate that the &gpio1 and &gpio2 targets
have the same length as the associated gpio descriptor tuples. (ex.
gpio1 needs #gpio-cells=<1>; and gpio2 needs #gpio-cells=<2>; If the
tuples are the wrong size, then validation should fail.

g.
>
> Gr{oetje,eeting}s,
>
>                          Geert
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.