From: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@secretlab.ca>,
David Gibson <david@gibson.dropbear.id.au>,
Tom Rini <trini@konsulko.com>,
Franklin S Cooper Jr <fcooper@ti.com>,
Matt Porter <mporter@konsulko.com>,
Simon Glass <sjg@chromium.org>,
Phil Elwell <philip.j.elwell@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Marek Vasut <marex@denx.de>,
Devicetree Compiler <devicetree-compiler@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too
Date: Mon, 02 Oct 2017 22:46:20 +0300 [thread overview]
Message-ID: <1506973580.17981.5.camel@hp800z> (raw)
In-Reply-To: <CAL_Jsq+Hxjf8PecU+ZpCoFqbKAYJtzHpFco2Wsi_KT499fb-=g@mail.gmail.com>
Hi Rob,
On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
> On Thu, Sep 28, 2017 at 2:58 PM, Pantelis Antoniou
> <pantelis.antoniou@konsulko.com> wrote:
> > Hello again,
> >
> > Significant progress has been made on yamldt and is now capable of
> > not only generating yaml from DTS source but also compiling DTS sources
> > and being almost fully compatible with DTC.
>
> Can you quantify "almost"?
>
> > Compiling the kernel's DTBs using yamldt is as simple as using a
> > DTC=yamldt.
>
> Good.
>
> >
> > Error reporting is accurate and validation against a YAML based schema
> > works as well. In a short while I will begin posting patches with
> > fixes on bindings and DTS files in the kernel.
>
> What I would like to see is the schema format posted for review.
>
I'm including the skeleton.yaml binding which is the template for
the bindings and a board-example.yaml binding for a top level binding.
> I would also like to see the bindings for top-level compatible strings
> (aka boards) as an example. That's something that's simple enough that
> I'd think we could agree on a format and start moving towards defining
> board bindings that way.
>
Note there is some line wrapping I'm including a link
to the github repo of the files:
The skeleton.yaml
https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/skeleton.yaml
%YAML 1.1
---
# The name of the binding is first
# The anchor is put there for use by others
skeleton: &skeleton
version: 1
id: skel-device
title: >
Skeleton Device
maintainer:
name: Skeleton Person <skel@kernel.org>
description: >
The Skeleton Device binding represents the SK11 device produced by
the Skeleton Corporation. The binding can also support compatible
clones made by second source vendors.
# The class is an optional property that declares this
# binding as part of a larger set
# Multiple definitions are possible
class: [ device, spi-device ]
# This binding inherits property characteristics from the generic
# spi-slave binding
# Note that the notation is standard yaml reference
inherits: *spi-slave
# virtual bindings do not generate checkers
virtual: true
# each property is defined by each name
properties:
# The compatible property is a reserved name. The type is always
"string"
# and should not be repeated device binding.
compatible:
category: required # required property
type: strseq # is a sequence of strings
description: >
FX11 is a clone of the original SK11 device
# v is always the name of the value of the property
# np is passed to the checker and is the current
# node pointer. We can access properties and call
# methods that operate on them.
# There can be multiple constraints, just put them
# into a sequence.
# Note that the BASE("skel,sk11") form from the previous
# binding will have to be reworked.
constraint: |
anystreq(v, "skel,sk11") ||
anystreq(v, "faux,fx11")
# The reg property is a reserved name. The type is always "int" and
# should not be repeated in a device binding. Constraints are
defined
# only in the context of the parent node's address, size, and ranges
# cells. The description is inherited from the spi-slave binding.
# Note that if inheriting from a base binding this declaration may
# be omitted.
reg:
category: required # required property
type: intseq # is a sequence of integers
# spi-max-frequency needs the device-specific constraint to be
supplied
spi-max-frequency:
# this constraint is dependent on the compatible property
# property containing "skel,sk11"
constraint: |
v <= anystreq(get_strseq(np, "compatible"), "skel,sk11") ?
10000000 : 1000000
# This property overrides the generic binding description with
# a device specific description in order to mention the chip's
# h/w cfg strapping pins.
spi-cs-high:
description: >
Set if skeleton device configuration pins are set for chip
select polarity high
# Device specific properties don't inherit characteristic from a
generic
# binding so category, type, constraint, and description must be
specified
# if needed.
skel,deprecated1:
# note that the category may be declare more than one option
category: [ deprecated, optional ]
type: int
constraint: |
v >= 100000 && v <= 200000
description: >
First of two deprecated properties.
# There are no constraints for properties of empty type
skel,deprecated2:
category: deprecated
type: empty
description: >
Second of two deprecated properties.
# This example could be auto-generated rather than explicitly
included
# in the yaml source.
# Note that the YAML example must be validated against this binding
# to be an accepted entry
example:
dts: |
sk11@0 {
compatible = "skel,sk11";
reg = <0>;
spi-max-frequency = <1000000>;
spi-cs-high;
};
yaml: |
sk11@0:
compatible: "skel,sk11"
reg: 0
sip-max-frequency: 1000000
spi-cs-high: true
---
...
And board-example.yaml
https://raw.githubusercontent.com/pantoniou/yamldt/master/validate/bindings/board-example.yaml
%YAML 1.1
---
board-example: &board-example
version: 1
title: A board example using compatible and model properties
maintainer:
name: Skeleton Person <skel@kernel.org>
class: board
# this binding is selected when the compatible property constraint
matches
selected: "compatible"
description: >
A board binding example. Matches on a top-level compatible string
and model.
properties:
compatible:
category: required
type: strseq
description: |
Compatible strings for the board example.
The depth of the node must be zero, i.e. root.
constraint: |
get_depth(np) == 0 && (
anystreq(v, "example,evm") ||
anystreq(v, "example,evm2") ||
anystreq(v, "example,base"))
model:
category: required
type: str
description: models that this board family supports
constraint: |
streq(v, "Example EVM") ||
streq(v, "Example EVM2")
example:
dts: |
/ {
compatible = "example,evm", "example,base";
model = "Example EVM";
};
yaml: |
compatible: [ "example,evm", "example,base" ] ;
model: "Example EVM";
As you see it's almost identical to what you've originally posted.
> Rob
next prev parent reply other threads:[~2017-10-02 19:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 19:58 [RFC] yamldt v0.5, now a DTS compiler too Pantelis Antoniou
2017-09-28 19:58 ` Pantelis Antoniou
2017-10-01 22:00 ` Rob Herring
2017-10-01 22:00 ` Rob Herring
2017-10-02 7:36 ` Pantelis Antoniou
2017-10-02 19:46 ` Pantelis Antoniou [this message]
2017-10-03 7:17 ` Geert Uytterhoeven
2017-10-03 7:33 ` Pantelis Antoniou
2017-10-03 13:18 ` Rob Herring
2017-10-03 14:13 ` Pantelis Antoniou
2017-10-03 14:13 ` Pantelis Antoniou
2017-10-03 17:13 ` Rob Herring
2017-10-03 17:39 ` Pantelis Antoniou
2017-10-03 17:39 ` Pantelis Antoniou
2017-10-06 13:55 ` Rob Herring
2017-10-06 13:55 ` Rob Herring
2017-10-07 10:23 ` Pantelis Antoniou
2017-10-08 23:08 ` Frank Rowand
2017-10-08 23:08 ` Frank Rowand
2017-10-09 0:00 ` David Gibson
2017-10-09 0:00 ` David Gibson
2017-10-09 15:07 ` Pantelis Antoniou
2017-10-09 15:07 ` Pantelis Antoniou
2017-10-10 1:50 ` David Gibson
2017-10-10 15:19 ` Pantelis Antoniou
2017-10-10 15:19 ` Pantelis Antoniou
2017-10-11 3:49 ` David Gibson
2017-10-11 3:49 ` David Gibson
2017-10-09 14:59 ` Pantelis Antoniou
2017-10-20 17:46 ` Grant Likely
2017-10-20 17:46 ` Grant Likely
2017-10-20 19:16 ` Pantelis Antoniou
2017-10-22 17:54 ` Grant Likely
2017-10-22 17:54 ` Grant Likely
2017-10-22 18:23 ` Pantelis Antoniou
2017-10-22 18:23 ` Pantelis Antoniou
2017-10-22 19:13 ` Grant Likely
2017-10-22 19:13 ` Grant Likely
2017-10-23 10:08 ` Pantelis Antoniou
2017-10-23 10:08 ` Pantelis Antoniou
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=1506973580.17981.5.camel@hp800z \
--to=pantelis.antoniou@konsulko.com \
--cc=david@gibson.dropbear.id.au \
--cc=devicetree-compiler@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fcooper@ti.com \
--cc=frowand.list@gmail.com \
--cc=geert@linux-m68k.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=mporter@konsulko.com \
--cc=philip.j.elwell@gmail.com \
--cc=robherring2@gmail.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.