94 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3============================================================4DOs and DON'Ts for designing and writing Devicetree bindings5============================================================6 7This is a list of common review feedback items focused on binding design. With8every rule, there are exceptions and bindings have many gray areas.9 10For guidelines related to patches, see11Documentation/devicetree/bindings/submitting-patches.rst12 13 14Overall design15==============16 17- DO attempt to make bindings complete even if a driver doesn't support some18 features. For example, if a device has an interrupt, then include the19 'interrupts' property even if the driver is only polled mode.20 21- DON'T refer to Linux or "device driver" in bindings. Bindings should be22 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 are25 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 making28 review changes.29 30- DON'T create nodes just for the sake of instantiating drivers. Multi-function31 devices only need child nodes when the child nodes have their own DT32 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 the36 register layout of the entire block (at a minimum).37 38 39Properties40==========41 42- DO make 'compatible' properties specific. DON'T use wildcards in compatible43 strings. DO use fallback compatibles when devices are the same as or a subset44 of prior implementations. DO add new compatibles in case there are new45 features or bugs.46 47- DO use a vendor prefix on device-specific property names. Consider if48 properties could be common among devices of the same class. Check other49 existing bindings for similar devices.50 51- DON'T redefine common properties. Just reference the definition and define52 constraints specific to the device.53 54- DO use common property unit suffixes for properties with scientific units.55 Recommended suffixes are listed at56 https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml57 58- DO define properties in terms of constraints. How many entries? What are59 possible values? What is the order?60 61Typical cases and caveats62=========================63 64- Phandle entries, like clocks/dmas/interrupts/resets, should always be65 explicitly ordered. Include the {clock,dma,interrupt,reset}-names if there is66 more than one phandle. When used, both of these fields need the same67 constraints (e.g. list of items).68 69- For names used in {clock,dma,interrupt,reset}-names, do not add any suffix,70 e.g.: "tx" instead of "txirq" (for interrupt).71 72- Properties without schema types (e.g. without standard suffix or not defined73 by schema) need the type, even if this is an enum.74 75- If schema includes other schema (e.g. /schemas/i2c/i2c-controller.yaml) use76 "unevaluatedProperties:false". In other cases, usually use77 "additionalProperties:false".78 79- For sub-blocks/components of bigger device (e.g. SoC blocks) use rather80 device-based compatible (e.g. SoC-based compatible), instead of custom81 versioning of that component.82 For example use "vendor,soc1234-i2c" instead of "vendor,i2c-v2".83 84- "syscon" is not a generic property. Use vendor and type, e.g.85 "vendor,power-manager-syscon".86 87Board/SoC .dts Files88====================89 90- DO put all MMIO devices under a bus node and not at the top-level.91 92- DO use non-empty 'ranges' to limit the size of child buses/devices. 64-bit93 platforms don't need all devices to have 64-bit address and size.94