diff options
| author | Krzysztof Kozlowski <krzk@kernel.org> | 2020-09-10 20:47:06 +0200 |
|---|---|---|
| committer | Rob Herring <robh@kernel.org> | 2020-09-15 16:42:11 -0600 |
| commit | 73f76a41c4ed7def5dc2ec7c33c7e9f94e601a20 (patch) | |
| tree | 4873ddacc779fb0bfe8473def80289503b46307d /Documentation/devicetree/bindings/example-schema.yaml | |
| parent | 5f40bb39ad555066589bfdcbfaaab1fad56ce1b0 (diff) | |
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: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200910184706.9677-1-krzk@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Diffstat (limited to 'Documentation/devicetree/bindings/example-schema.yaml')
| -rw-r--r-- | Documentation/devicetree/bindings/example-schema.yaml | 33 |
1 files changed, 25 insertions, 8 deletions
diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index 822975dbeafa..4552f2b988d0 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -81,6 +81,8 @@ properties: maxItems: 1 description: bus clock. A description is only needed for a single item if there's something unique to add. + The items should be have a fixed order, so pattern matching names are + discouraged. clock-names: items: @@ -97,6 +99,8 @@ properties: A variable number of interrupts warrants a description of what conditions affect the number of interrupts. Otherwise, descriptions on standard properties are not necessary. + The items should be have a fixed order, so pattern matching names are + discouraged. interrupt-names: # minItems must be specified here because the default would be 2 @@ -196,14 +200,24 @@ required: # # If the conditionals become too unweldy, then it may be better to just split # the binding into separate schema documents. -if: - properties: - compatible: - contains: - const: vendor,soc2-ip -then: - required: - - foo-supply +allOf: + - if: + properties: + compatible: + contains: + const: vendor,soc2-ip + then: + 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 # present are allowed. There's a few common properties such as 'status' and @@ -211,6 +225,9 @@ then: # # This can't be used in cases where another schema is referenced # (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 examples: |