[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7b7a2ce-9c5e-693b-34fc-db7a20e7b01b@gmail.com>
Date: Tue, 24 Apr 2018 17:33:11 -0700
From: Frank Rowand <frowand.list@...il.com>
To: Rob Herring <robh@...nel.org>
Cc: devicetree@...r.kernel.org, devicetree-spec@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Grant Likely <grant.likely@....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>, Stephen Boyd <sboyd@...nel.org>,
Jonathan Cameron <jic23@...nel.org>
Subject: Re: [RFC PATCH] dt-bindings: add a jsonschema binding example
On 04/20/18 18:28, Rob Herring wrote:
> On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand <frowand.list@...il.com> wrote:
>> Hi Rob,
>>
>> Thanks for the example. It was a good starting tutorial of sorts for me
>> to understand the format a bit.
>>
>>
>> On 04/18/18 15:29, 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.
>>>
>>> This example is just the tip of the iceberg, but it the part most
>>> developers writing bindings will interact with. Backing all this up
>>> are meta-schema (to validate the binding schemas), some DT core schema,
>>> YAML encoded DT output with dtc, and a small number of python scripts to
>>> run validation. The gory details including how to run end-to-end
>>> validation can be found here:
>>>
>>> https://www.spinics.net/lists/devicetree-spec/msg00649.html
>>>
>>> Signed-off-by: Rob Herring <robh@...nel.org>
>>> ---
>>> Cc list,
>>> You all review and/or write lots of binding documents. I'd like some feedback
>>> on the format.
>>>
>>> Thanks,
>>> Rob
>>>
>>> .../devicetree/bindings/example-schema.yaml | 149 +++++++++++++++++++++
>>> 1 file changed, 149 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/example-schema.yaml
>>>
>>> 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
>>
>> I'm guessing by the path name that this is in the Linux kernel source tree.
>
> Yes, well, my kernel tree. Most of the work still lives here:
>
> https://github.com/robherring/yaml-bindings/
>
>>> @@ -0,0 +1,149 @@
>>> +# SPDX-License-Identifier: BSD-2-Clause
>>
>> If in the Linux kernel source tree, then allow gpl-v2 as a possible license.
>
> Why? BSD is compatible. The license of the above repo is all BSD.
I said __if__ in the Linux kernel source tree. As my other comments
indicated, I wasn't sure if this was intended to end up in the Linux
kernel source tree. __If__ in the Linux kernel source tree then it
would be dual licensed, correct? And thus the tag would reflect that?
> Of course there's all the existing docs which default to GPLv2 and
> we'll probably have to maintain that.
>
< snip >
Powered by blists - more mailing lists