1.. SPDX-License-Identifier: GPL-2.0
2
3============================================================
4DOs and DON'Ts for designing and writing Devicetree bindings
5============================================================
6
7This is a list of common review feedback items focused on binding design. With
8every rule, there are exceptions and bindings have many gray areas.
9
10For guidelines related to patches, see
11Documentation/devicetree/bindings/submitting-patches.rst
12
13
14Overall design
15==============
16
17- DO attempt to make bindings complete even if a driver doesn't support some
18  features. For example, if a device has an interrupt, then include the
19  'interrupts' property even if the driver is only polled mode.
20
21- DON'T refer to Linux or "device driver" in bindings. Bindings should be
22  based on what the hardware has, not what an OS and driver currently support.
23
24- DO use node names matching the class of the device. Many standard names are
25  defined in the DT Spec. If there isn't one, consider adding it.
26
27- DO check that the example matches the documentation especially after making
28  review changes.
29
30- DON'T create nodes just for the sake of instantiating drivers. Multi-function
31  devices only need child nodes when the child nodes have their own DT
32  resources. A single node can be multiple providers (e.g. clocks and resets).
33
34- DON'T use 'syscon' alone without a specific compatible string. A 'syscon'
35  hardware block should have a compatible string unique enough to infer the
36  register layout of the entire block (at a minimum).
37
38
39Properties
40==========
41
42- DO make 'compatible' properties specific. DON'T use wildcards in compatible
43  strings. DO use fallback compatibles when devices are the same as or a subset
44  of prior implementations. DO add new compatibles in case there are new
45  features or bugs.
46
47- DO use a vendor prefix on device specific property names. Consider if
48  properties could be common among devices of the same class. Check other
49  existing bindings for similar devices.
50
51- DON'T redefine common properties. Just reference the definition and define
52  constraints specific to the device.
53
54- DO use common property unit suffixes for properties with scientific units.
55  See property-units.txt.
56
57- DO define properties in terms of constraints. How many entries? What are
58  possible values? What is the order?
59
60
61Board/SoC .dts Files
62====================
63
64- DO put all MMIO devices under a bus node and not at the top-level.
65
66- DO use non-empty 'ranges' to limit the size of child buses/devices. 64-bit
67  platforms don't need all devices to have 64-bit address and size.
68