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