LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: jonsmirl@gmail.com
Cc: Frank Rowand <frowand.list@gmail.com>,
	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>,
	Mark Rutland <mark.rutland@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linus Walleij <linus.walleij@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Mark Brown <broonie@kernel.org>, 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: Thu, 15 Nov 2018 17:42:14 -0600	[thread overview]
Message-ID: <CAL_JsqJd7F7=yyW5X0P4W0N+0UDA8MLPDGvbBBK+VqMKqajC7Q@mail.gmail.com> (raw)
In-Reply-To: <CAKON4OxwAmmPv2+CEtT+eO3Uu8duCKD8OqyWj8+w2Y5SZ4bfOQ@mail.gmail.com>

On Wed, Nov 14, 2018 at 1:39 PM jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>
> On Fri, Apr 20, 2018 at 9:36 PM Rob Herring <robh@kernel.org> wrote:
> > I share the concern as I doubt most kernel developers don't know
> > jsonschema. But then the alternative is us defining and writing our
> > own thing which is C like 'cause that's what kernel developers
> > understand. My hope is to simplify and restrict things enough that it
> > writing a binding doc is straightforward without being jsonschema
> > experts. That was the intent of this patch without going into all the
> > details behind it.
>
> When schemas were first discussed long, long ago the idea was to have
> a n arbitrator who controls the schema (like Grant/Rob) so there is no
> need for general schema design knowledge in random kernel developers.
>
> First a developer should try and build their device tree using the
> existing schema. Then only if they find that impossible to do so
> should they propose schema changes. The schema arbitrator would then
> look at those changes and work them into the existing schemas as
> needed. Doing this via an arbitrator will ensure consistency in the
> overall schema design while eliminating redundancy with slight
> variations (like we have now).
>
> Another side effect of schemas is that as they evolve and enforce
> commonality among driver implementation it will become possible to
> turn those in-common pieces into driver libraries.

If we replace 'schemas' everywhere above with 'bindings', then this
pretty much describes the status quo today. Most device specific
bindings are a collection of standard bindings. Occasionally, we have
new common bindings. All the bindings get reviewed by me. The only
real change here is submitters have to have some level of
understanding of json-schema instead of just English (for writing free
form text). I think it will continue to largely be following existing
examples of other bindings.

Rob

  reply	other threads:[~2018-11-15 23:42 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
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 [this message]
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_JsqJd7F7=yyW5X0P4W0N+0UDA8MLPDGvbBBK+VqMKqajC7Q@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=jonsmirl@gmail.com \
    --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).