]> git.proxmox.com Git - mirror_ubuntu-jammy-kernel.git/blob - Documentation/devicetree/bindings/example-schema.yaml
affs: fix basic permission bits to actually work
[mirror_ubuntu-jammy-kernel.git] / Documentation / devicetree / bindings / example-schema.yaml
1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
2 # Copyright 2018 Linaro Ltd.
3 %YAML 1.2
4 ---
5 # All the top-level keys are standard json-schema keywords except for
6 # 'maintainers' and 'select'
7
8 # $id is a unique identifier based on the filename. There may or may not be a
9 # file present at the URL.
10 $id: http://devicetree.org/schemas/example-schema.yaml#
11 # $schema is the meta-schema this schema should be validated with.
12 $schema: http://devicetree.org/meta-schemas/core.yaml#
13
14 title: An example schema annotated with jsonschema details
15
16 maintainers:
17 - Rob Herring <robh@kernel.org>
18
19 description: |
20 A more detailed multi-line description of the binding.
21
22 Details about the hardware device and any links to datasheets can go here.
23
24 Literal blocks are marked with the '|' at the beginning. The end is marked by
25 indentation less than the first line of the literal block. Lines also cannot
26 begin with a tab character.
27
28 select: false
29 # 'select' is a schema applied to a DT node to determine if this binding
30 # schema should be applied to the node. It is optional and by default the
31 # possible compatible strings are extracted and used to match.
32
33 # In this case, a 'false' schema will never match.
34
35 properties:
36 # A dictionary of DT properties for this binding schema
37 compatible:
38 # More complicated schema can use oneOf (XOR), anyOf (OR), or allOf (AND)
39 # to handle different conditions.
40 # In this case, it's needed to handle a variable number of values as there
41 # isn't another way to express a constraint of the last string value.
42 # The boolean schema must be a list of schemas.
43 oneOf:
44 - items:
45 # items is a list of possible values for the property. The number of
46 # values is determined by the number of elements in the list.
47 # Order in lists is significant, order in dicts is not
48 # Must be one of the 1st enums followed by the 2nd enum
49 #
50 # Each element in items should be 'enum' or 'const'
51 - enum:
52 - vendor,soc4-ip
53 - vendor,soc3-ip
54 - vendor,soc2-ip
55 - enum:
56 - vendor,soc1-ip
57 # additionalItems being false is implied
58 # minItems/maxItems equal to 2 is implied
59 - items:
60 # 'const' is just a special case of an enum with a single possible value
61 - const: vendor,soc1-ip
62
63 reg:
64 # The core schema already checks that reg values are numbers, so device
65 # specific schema don't need to do those checks.
66 # The description of each element defines the order and implicitly defines
67 # the number of reg entries.
68 items:
69 - description: core registers
70 - description: aux registers
71 # minItems/maxItems equal to 2 is implied
72
73 reg-names:
74 # The core schema enforces this (*-names) is a string array
75 items:
76 - const: core
77 - const: aux
78
79 clocks:
80 # Cases that have only a single entry just need to express that with maxItems
81 maxItems: 1
82 description: bus clock. A description is only needed for a single item if
83 there's something unique to add.
84
85 clock-names:
86 items:
87 - const: bus
88
89 interrupts:
90 # Either 1 or 2 interrupts can be present
91 minItems: 1
92 maxItems: 2
93 items:
94 - description: tx or combined interrupt
95 - description: rx interrupt
96 description:
97 A variable number of interrupts warrants a description of what conditions
98 affect the number of interrupts. Otherwise, descriptions on standard
99 properties are not necessary.
100
101 interrupt-names:
102 # minItems must be specified here because the default would be 2
103 minItems: 1
104 maxItems: 2
105 items:
106 - const: tx irq
107 - const: rx irq
108
109 # Property names starting with '#' must be quoted
110 '#interrupt-cells':
111 # A simple case where the value must always be '2'.
112 # The core schema handles that this must be a single integer.
113 const: 2
114
115 interrupt-controller: true
116 # The core checks this is a boolean, so just have to list it here to be
117 # valid for this binding.
118
119 clock-frequency:
120 # The type is set in the core schema. Per device schema only need to set
121 # constraints on the possible values.
122 minimum: 100
123 maximum: 400000
124 # The value that should be used if the property is not present
125 default: 200
126
127 foo-gpios:
128 maxItems: 1
129 description: A connection of the 'foo' gpio line.
130
131 # *-supply is always a single phandle, so nothing more to define.
132 foo-supply: true
133
134 # Vendor specific properties
135 #
136 # Vendor specific properties have slightly different schema requirements than
137 # common properties. They must have at least a type definition and
138 # 'description'.
139 vendor,int-property:
140 description: Vendor specific properties must have a description
141 $ref: /schemas/types.yaml#/definitions/uint32
142 enum: [2, 4, 6, 8, 10]
143
144 vendor,bool-property:
145 description: Vendor specific properties must have a description. Boolean
146 properties are one case where the json-schema 'type' keyword can be used
147 directly.
148 type: boolean
149
150 vendor,string-array-property:
151 description: Vendor specific properties should reference a type in the
152 core schema.
153 $ref: /schemas/types.yaml#/definitions/string-array
154 items:
155 - enum: [foo, bar]
156 - enum: [baz, boo]
157
158 vendor,property-in-standard-units-microvolt:
159 description: Vendor specific properties having a standard unit suffix
160 don't need a type.
161 enum: [ 100, 200, 300 ]
162
163 child-node:
164 description: Child nodes are just another property from a json-schema
165 perspective.
166 type: object # DT nodes are json objects
167 properties:
168 vendor,a-child-node-property:
169 description: Child node properties have all the same schema
170 requirements.
171 type: boolean
172
173 required:
174 - vendor,a-child-node-property
175
176 # Describe the relationship between different properties
177 dependencies:
178 # 'vendor,bool-property' is only allowed when 'vendor,string-array-property'
179 # is present
180 vendor,bool-property: [ 'vendor,string-array-property' ]
181 # Expressing 2 properties in both orders means all of the set of properties
182 # must be present or none of them.
183 vendor,string-array-property: [ 'vendor,bool-property' ]
184
185 required:
186 - compatible
187 - reg
188 - interrupts
189 - interrupt-controller
190
191 # if/then schema can be used to handle conditions on a property affecting
192 # another property. A typical case is a specific 'compatible' value changes the
193 # constraints on other properties.
194 #
195 # For multiple 'if' schema, group them under an 'allOf'.
196 #
197 # If the conditionals become too unweldy, then it may be better to just split
198 # the binding into separate schema documents.
199 if:
200 properties:
201 compatible:
202 contains:
203 const: vendor,soc2-ip
204 then:
205 required:
206 - foo-supply
207
208 # Ideally, the schema should have this line otherwise any other properties
209 # present are allowed. There's a few common properties such as 'status' and
210 # 'pinctrl-*' which are added automatically by the tooling.
211 #
212 # This can't be used in cases where another schema is referenced
213 # (i.e. allOf: [{$ref: ...}]).
214 additionalProperties: false
215
216 examples:
217 # Examples are now compiled with dtc and validated against the schemas
218 #
219 # Examples have a default #address-cells and #size-cells value of 1. This can
220 # be overridden or an appropriate parent bus node should be shown (such as on
221 # i2c buses).
222 #
223 # Any includes used have to be explicitly included.
224 - |
225 node@1000 {
226 compatible = "vendor,soc4-ip", "vendor,soc1-ip";
227 reg = <0x1000 0x80>,
228 <0x3000 0x80>;
229 reg-names = "core", "aux";
230 interrupts = <10>;
231 interrupt-controller;
232 };