# valid for this binding.
clock-frequency:
- # The type is set in the core schema. Per device schema only need to set
+ # The type is set in the core schema. Per-device schema only need to set
# constraints on the possible values.
minimum: 100
maximum: 400000
# *-supply is always a single phandle, so nothing more to define.
foo-supply: true
- # Vendor specific properties
+ # Vendor-specific properties
#
- # Vendor specific properties have slightly different schema requirements than
+ # Vendor-specific properties have slightly different schema requirements than
# common properties. They must have at least a type definition and
# 'description'.
vendor,int-property:
- description: Vendor specific properties must have a description
+ description: Vendor-specific properties must have a description
$ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4, 6, 8, 10]
vendor,bool-property:
- description: Vendor specific properties must have a description. Boolean
+ description: Vendor-specific properties must have a description. Boolean
properties are one case where the json-schema 'type' keyword can be used
directly.
type: boolean
vendor,string-array-property:
- description: Vendor specific properties should reference a type in the
+ description: Vendor-specific properties should reference a type in the
core schema.
$ref: /schemas/types.yaml#/definitions/string-array
items:
- enum: [baz, boo]
vendor,property-in-standard-units-microvolt:
- description: Vendor specific properties having a standard unit suffix
+ description: Vendor-specific properties having a standard unit suffix
don't need a type.
enum: [ 100, 200, 300 ]
==========================================
Devicetree bindings are written using json-schema vocabulary. Schema files are
-written in a JSON compatible subset of YAML. YAML is used instead of JSON as it
+written in a JSON-compatible subset of YAML. YAML is used instead of JSON as it
is considered more human readable and has some advantages such as allowing
comments (Prefixed with '#').
URI typically containing the binding's filename and path. For DT schema, it must
begin with "http://devicetree.org/schemas/". The URL is used in constructing
references to other files specified in schema "$ref" properties. A $ref value
- with a leading '/' will have the hostname prepended. A $ref value a relative
- path or filename only will be prepended with the hostname and path components
- of the current schema file's '$id' value. A URL is used even for local files,
- but there may not actually be files present at those locations.
+ with a leading '/' will have the hostname prepended. A $ref value with only a
+ relative path or filename will be prepended with the hostname and path
+ components of the current schema file's '$id' value. A URL is used even for
+ local files, but there may not actually be files present at those locations.
$schema
Indicates the meta-schema the schema file adheres to.
title
- A one line description on the contents of the binding schema.
+ A one-line description on the contents of the binding schema.
maintainers
A DT specific property. Contains a list of email address(es)
select
Optional. A json-schema used to match nodes for applying the
- schema. By default without 'select', nodes are matched against their possible
- compatible string values or node name. Most bindings should not need select.
+ schema. By default, without 'select', nodes are matched against their possible
+ compatible-string values or node name. Most bindings should not need select.
allOf
Optional. A list of other schemas to include. This is used to
properties
A set of sub-schema defining all the DT properties for the
binding. The exact schema syntax depends on whether properties are known,
- common properties (e.g. 'interrupts') or are binding/vendor specific properties.
+ common properties (e.g. 'interrupts') or are binding/vendor-specific
+ properties.
A property can also define a child DT node with child properties defined
under it.
The 'properties' section of the schema contains all the DT properties for a
binding. Each property contains a set of constraints using json-schema
-vocabulary for that property. The properties schemas are what is used for
+vocabulary for that property. The properties schemas are what are used for
validation of DT files.
-For common properties, only additional constraints not covered by the common
+For common properties, only additional constraints not covered by the common,
binding schema need to be defined such as how many values are valid or what
possible values are valid.
-Vendor specific properties will typically need more detailed schema. With the
+Vendor-specific properties will typically need more detailed schema. With the
exception of boolean properties, they should have a reference to a type in
schemas/types.yaml. A "description" property is always required.
-The Devicetree schemas don't exactly match the YAML encoded DT data produced by
+The Devicetree schemas don't exactly match the YAML-encoded DT data produced by
dtc. They are simplified to make them more compact and avoid a bunch of
boilerplate. The tools process the schema files to produce the final schema for
validation. There are currently 2 transformations the tools perform.
-The default for arrays in json-schema is they are variable sized and allow more
+The default for arrays in json-schema is they are variable-sized and allow more
entries than explicitly defined. This can be restricted by defining 'minItems',
'maxItems', and 'additionalItems'. However, for DeviceTree Schemas, a fixed
size is desired in most cases, so these properties are added based on the
OSDN Git Service
