Commit 73f76a41 authored by Krzysztof Kozlowski's avatar Krzysztof Kozlowski Committed by Rob Herring

dt-bindings: example: Extend based on practice

Extend the example schema with common rules which seems to be not that
obvious:
1. Expecting arrays of phandles to be always ordered, regardless if
   "xxx-names" is provided (e.g. clocks),
2. Add example of altering a property based on presence of other
   property,
3. Document usage of unevaluatedProperties.
Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200910184706.9677-1-krzk@kernel.orgSigned-off-by: default avatarRob Herring <robh@kernel.org>
parent 5f40bb39
...@@ -81,6 +81,8 @@ properties: ...@@ -81,6 +81,8 @@ properties:
maxItems: 1 maxItems: 1
description: bus clock. A description is only needed for a single item if description: bus clock. A description is only needed for a single item if
there's something unique to add. there's something unique to add.
The items should be have a fixed order, so pattern matching names are
discouraged.
clock-names: clock-names:
items: items:
...@@ -97,6 +99,8 @@ properties: ...@@ -97,6 +99,8 @@ properties:
A variable number of interrupts warrants a description of what conditions A variable number of interrupts warrants a description of what conditions
affect the number of interrupts. Otherwise, descriptions on standard affect the number of interrupts. Otherwise, descriptions on standard
properties are not necessary. properties are not necessary.
The items should be have a fixed order, so pattern matching names are
discouraged.
interrupt-names: interrupt-names:
# minItems must be specified here because the default would be 2 # minItems must be specified here because the default would be 2
...@@ -196,14 +200,24 @@ required: ...@@ -196,14 +200,24 @@ required:
# #
# If the conditionals become too unweldy, then it may be better to just split # If the conditionals become too unweldy, then it may be better to just split
# the binding into separate schema documents. # the binding into separate schema documents.
if: allOf:
properties: - if:
compatible: properties:
contains: compatible:
const: vendor,soc2-ip contains:
then: const: vendor,soc2-ip
required: then:
- foo-supply required:
- foo-supply
# Altering schema depending on presence of properties is usually done by
# dependencies (see above), however some adjustments might require if:
- if:
required:
- vendor,bool-property
then:
properties:
vendor,int-property:
enum: [2, 4, 6]
# Ideally, the schema should have this line otherwise any other properties # Ideally, the schema should have this line otherwise any other properties
# present are allowed. There's a few common properties such as 'status' and # present are allowed. There's a few common properties such as 'status' and
...@@ -211,6 +225,9 @@ then: ...@@ -211,6 +225,9 @@ then:
# #
# This can't be used in cases where another schema is referenced # This can't be used in cases where another schema is referenced
# (i.e. allOf: [{$ref: ...}]). # (i.e. allOf: [{$ref: ...}]).
# If and only if another schema is referenced and arbitrary children nodes can
# appear, "unevaluatedProperties: false" could be used. Typical example is I2C
# controller where no name pattern matching for children can be added.
additionalProperties: false additionalProperties: false
examples: examples:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment