LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, devicetree-spec@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Grant Likely <grant.likely@arm.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linus Walleij <linus.walleij@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Stephen Boyd <sboyd@kernel.org>,
	Jonathan Cameron <jic23@kernel.org>
Subject: Re: [RFC PATCH] dt-bindings: add a jsonschema binding example
Date: Fri, 20 Apr 2018 13:47:03 -0500	[thread overview]
Message-ID: <CAL_Jsq+ZB-afhtDqq333qG9fs060WX8jkEqWmgOJyJVtztL2XA@mail.gmail.com> (raw)
In-Reply-To: <20180420165921.GD22369@sirena.org.uk>

On Fri, Apr 20, 2018 at 11:59 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Apr 18, 2018 at 05:29:05PM -0500, Rob Herring wrote:
>> The current DT binding documentation format of freeform text is painful
>> to write, review, validate and maintain.
>>
>> This is just an example of what a binding in the schema format looks
>> like. It's using jsonschema vocabulary in a YAML encoded document. Using
>> jsonschema gives us access to existing tooling. A YAML encoding gives us
>> something easy to edit.
>
> It'd be useful to see some examples of how things like including by
> reference other schema work.  It feels like something we should be able
> to use more in a schema based thing but perhaps that's not viable with
> realistic tooling.  In general this looks OK, especially with all the
> meta comments about the language stripped out.

There are several examples in the meta-schema and some of the core
schema as references are used there quite a bit. It gets quite fun to
follow with recursion. :)

I think the need for references in device bindings should be pretty
minimal. We'd probably mainly need references for some vendor specific
properties which will need to reference some of our compound types. So
we'd have something like this:

vendor,a-string-array-prop:
  $ref: "dt-core.yaml#/definitions/proptypes/stringarray"

For common bindings, we don't have to reference them in device
bindings (which should save lots of boilerplate). We can select and
apply them based on presence of properties and that happens
independent of the device binding. The device binding only needs
define what the common binding cannot which is typically how many
elements and what are they.

>
>> +    description: |
>> +      A variable number of interrupts warrants a description of what conditions
>
> Like Stephen said the | looks odd.

That's just how literal blocks in yaml are done.

>> +  interrupt-names:
>> +    # minItems must be specified here because the default would be 2
>> +    minItems: 1
>> +    items:
>> +      - const: "tx irq"
>> +      - const: "rx irq"
>
> Any way to relate this to the interrupts property in the schema
> language (eg, must have the less or equal number of elements)?

I've wanted something like that, but there isn't any way that I've
come up with. Generally, the "jsonschema way" is each schema is
supposed to be independent of each other. There's some discussion
about adding data dependent schema which might help in this case.

>
>> +  # Property names starting with '#' must be quoted
>
> That's awkward :/  Perhaps just by convention quote all property names
> for simplicity?

Yes, perhaps we should. I have a formatting tool, I'll look into
whether i can make it do that.

Thanks for taking a look.

Rob

  reply	other threads:[~2018-04-20 18:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18 22:29 Rob Herring
2018-04-20 16:47 ` Stephen Boyd
2018-04-20 18:15   ` Rob Herring
2018-04-20 19:53     ` Frank Rowand
2018-04-20 23:41     ` Stephen Boyd
2018-04-21  1:34       ` Rob Herring
2018-04-23 14:01       ` Grant Likely
2018-04-23 14:38         ` Rob Herring
2018-04-23 14:49           ` Grant Likely
2018-04-20 16:59 ` Mark Brown
2018-04-20 18:47   ` Rob Herring [this message]
2018-04-20 21:00 ` Frank Rowand
2018-04-21  1:28   ` Rob Herring
2018-04-23  7:25     ` Geert Uytterhoeven
2018-04-23 14:47     ` Grant Likely
2018-04-23 16:49       ` Geert Uytterhoeven
2018-04-25 10:15         ` Grant Likely
2018-04-25  0:33     ` Frank Rowand
2018-11-14 19:39     ` jonsmirl
2018-11-15 23:42       ` Rob Herring
2018-11-16  1:34         ` jonsmirl
2018-04-20 21:47 ` Bjorn Andersson
2018-04-23 16:51   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAL_Jsq+ZB-afhtDqq333qG9fs060WX8jkEqWmgOJyJVtztL2XA@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=devicetree-spec@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=grant.likely@arm.com \
    --cc=jic23@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=thierry.reding@gmail.com \
    --subject='Re: [RFC PATCH] dt-bindings: add a jsonschema binding example' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).