Lines Matching +full:many +full:- +full:to +full:- +full:one
1 .. SPDX-License-Identifier: GPL-2.0
8 every rule, there are exceptions and bindings have many gray areas.
10 For guidelines related to patches, see
11 Documentation/devicetree/bindings/submitting-patches.rst
17 - DO attempt to make bindings complete even if a driver doesn't support some
21 - DON'T refer to Linux or "device driver" in bindings. Bindings should be
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.
27 - DO check that the example matches the documentation especially after making
30 - DON'T create nodes just for the sake of instantiating drivers. Multi-function
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
42 - DO make 'compatible' properties specific.
44 - DON'T use wildcards or device-family names in compatible strings.
46 - DO use fallback compatibles when devices are the same as or a superset of
49 - DO add new compatibles in case there are new features or bugs.
51 - DO use a SoC-specific compatible for all SoC devices, followed by a
52 fallback if appropriate. SoC-specific compatibles are also preferred for
55 - DON'T use bus suffixes to encode the type of interface device is using.
59 - DO use a vendor prefix on device-specific property names. Consider if
63 - DON'T redefine common properties. Just reference the definition and define
64 constraints specific to the device.
66 - DON'T add properties to avoid a specific compatible. DON'T add properties if
69 - DO use common property unit suffixes for properties with scientific units.
71 https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
73 - DO define properties in terms of constraints. How many entries? What are
77 - DON'T make changes that break the ABI without explicit and detailed rationale
78 for why the changes have to be made and their impact. ABI impact goes beyond
79 the Linux kernel, because it also covers other open-source upstream projects.
85 - Phandle entries, like clocks/dmas/interrupts/resets, should always be
86 explicitly ordered. Include the {clock,dma,interrupt,reset}-names if there is
87 more than one phandle. When used, both of these fields need the same
90 - For names used in {clock,dma,interrupt,reset}-names, do not add any suffix,
93 - Properties without schema types (e.g. without standard suffix or not defined
96 - If schema includes other schema (e.g. /schemas/i2c/i2c-controller.yaml) use
100 - For sub-blocks/components of bigger device (e.g. SoC blocks) use rather
101 device-based compatible (e.g. SoC-based compatible), instead of custom
103 For example use "vendor,soc1234-i2c" instead of "vendor,i2c-v2".
105 - "syscon" is not a generic property. Use vendor and type, e.g.
106 "vendor,power-manager-syscon".
108 - Do not add instance index (IDs) properties or custom OF aliases. If the
113 - Bindings files should be named like compatible: vendor,device.yaml. In case
114 of multiple compatibles in the binding, use one of the fallbacks or a more
120 - DO put all MMIO devices under a bus node and not at the top-level.
122 - DO use non-empty 'ranges' to limit the size of child buses/devices. 64-bit
123 platforms don't need all devices to have 64-bit address and size.