From: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] dt-bindings: examples: add a list of templates and solutions
Date: Tue, 1 Nov 2022 08:07:20 -0500 [thread overview]
Message-ID: <20221101130720.GA963805-robh@kernel.org> (raw)
In-Reply-To: <20221028233701.572280-1-krzysztof.kozlowski@linaro.org>
On Fri, Oct 28, 2022 at 07:37:01PM -0400, Krzysztof Kozlowski wrote:
> It is useful to start from existing bindings when writing new ones,
> especially when one does not know that much DT schema. However we have
> several bindings which are not the best examples, so people tend to copy
> their issues into new bindings.
>
> Beginners also might not know how to achieve some more complex solutions
> in DT schema, e.g. how one of two properties should be required by the
> bindings. Some of such solutions are already in example-schema.yaml,
> but several other are missing. Add reference with such re-usable
> design-patterns.
My main concern here is what's a good example today is not tomorrow...
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> .../devicetree/bindings/examples.rst | 63 +++++++++++++++++++
> Documentation/devicetree/bindings/index.rst | 1 +
> 2 files changed, 64 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/examples.rst
>
> diff --git a/Documentation/devicetree/bindings/examples.rst b/Documentation/devicetree/bindings/examples.rst
> new file mode 100644
> index 000000000000..710eea81d8b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/examples.rst
> @@ -0,0 +1,63 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Examples of Devicetree Bindings to use a base
> +=============================================
> +
> +Following Devicetree Bindings in DT Schema are a known good starting point when
> +writing new bindings:
> +
> +1. Simple SPI device:
> + Documentation/devicetree/bindings/iio/adc/maxim,max11205.yaml
> +
> +2. PMIC (MFD) with several sub-devices:
> + Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> +
> +3. Battery charger (power supply):
> + Documentation/devicetree/bindings/power/supply/bq256xx.yaml
> + (but use vendor prefix in filename)
> +
> +4. Clock controller for several devices with different clock inputs:
> + Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
> +
> +5. GPIO controller:
> + Documentation/devicetree/bindings/gpio/qcom,wcd934x-gpio.yaml
> +
> +
> +Re-usable design patterns when writing your own bindings
> +========================================================
> +
> +Following bindings show how to use common pattern of writing bindings:
> +
> +1. Property required and present only for one variant. Property cannot appear
> + on other variants:
> + Documentation/devicetree/bindings/example-schema.yaml
> + Line: 212
> +
> +2. Excluding properties, but none are required:
> + Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
> + Line: 155
> +
> +3. Excluding required properties, but one is required:
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> + Line: 91
> +
> +4. Array with numbers (items) from given range - min/max:
> + Documentation/devicetree/bindings/arm/l2c2x0.yaml
> + Line: 74
> +
> +5. Array with numbers (items) from given range - enum:
> + Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> + Line: 101
> +
> +6. Uint32 matrix, variable length of two-items:
> + Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
> + Line: 278
> +
> +7. Phandle to syscon with offset:
> + Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
> + Line: 42
> +
> +8. Variable length of array (e.g. clocks and clock-names) but narrowed to
> + specific variant:
> + Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
> + Lines: 33 and 71
It seems like some of these that are just a single property we could add
to example-schema.yaml.
Also, perhaps a reference to this from writing-schema.rst.
Rob
next prev parent reply other threads:[~2022-11-01 13:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 23:37 [PATCH] dt-bindings: examples: add a list of templates and solutions Krzysztof Kozlowski
2022-11-01 13:07 ` Rob Herring [this message]
2022-11-04 14:52 ` Krzysztof Kozlowski
2022-11-04 21:47 ` Rob Herring
2022-11-07 18:35 ` Krzysztof Kozlowski
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=20221101130720.GA963805-robh@kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.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 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).