mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-25 20:14:25 +08:00
d0413118bb
property-units.txt is not maintained anymore. New suffixes are now supported that have not been added here. To avoid people incorrectly think a given suffix is not in the list remove the file entirely and point to the authoritative place where the recommended suffixes are maintained. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Link: https://lore.kernel.org/r/20210512152311.7399-1-luca@lucaceresoli.net Signed-off-by: Rob Herring <robh@kernel.org>
69 lines
2.6 KiB
ReStructuredText
69 lines
2.6 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
============================================================
|
|
DOs and DON'Ts for designing and writing Devicetree bindings
|
|
============================================================
|
|
|
|
This is a list of common review feedback items focused on binding design. With
|
|
every rule, there are exceptions and bindings have many gray areas.
|
|
|
|
For guidelines related to patches, see
|
|
Documentation/devicetree/bindings/submitting-patches.rst
|
|
|
|
|
|
Overall design
|
|
==============
|
|
|
|
- DO attempt to make bindings complete even if a driver doesn't support some
|
|
features. For example, if a device has an interrupt, then include the
|
|
'interrupts' property even if the driver is only polled mode.
|
|
|
|
- DON'T refer to Linux or "device driver" in bindings. Bindings should be
|
|
based on what the hardware has, not what an OS and driver currently support.
|
|
|
|
- DO use node names matching the class of the device. Many standard names are
|
|
defined in the DT Spec. If there isn't one, consider adding it.
|
|
|
|
- DO check that the example matches the documentation especially after making
|
|
review changes.
|
|
|
|
- DON'T create nodes just for the sake of instantiating drivers. Multi-function
|
|
devices only need child nodes when the child nodes have their own DT
|
|
resources. A single node can be multiple providers (e.g. clocks and resets).
|
|
|
|
- DON'T use 'syscon' alone without a specific compatible string. A 'syscon'
|
|
hardware block should have a compatible string unique enough to infer the
|
|
register layout of the entire block (at a minimum).
|
|
|
|
|
|
Properties
|
|
==========
|
|
|
|
- DO make 'compatible' properties specific. DON'T use wildcards in compatible
|
|
strings. DO use fallback compatibles when devices are the same as or a subset
|
|
of prior implementations. DO add new compatibles in case there are new
|
|
features or bugs.
|
|
|
|
- DO use a vendor prefix on device specific property names. Consider if
|
|
properties could be common among devices of the same class. Check other
|
|
existing bindings for similar devices.
|
|
|
|
- DON'T redefine common properties. Just reference the definition and define
|
|
constraints specific to the device.
|
|
|
|
- DO use common property unit suffixes for properties with scientific units.
|
|
Recommended suffixes are listed at
|
|
https://github.com/devicetree-org/dt-schema/blob/master/schemas/property-units.yaml
|
|
|
|
- DO define properties in terms of constraints. How many entries? What are
|
|
possible values? What is the order?
|
|
|
|
|
|
Board/SoC .dts Files
|
|
====================
|
|
|
|
- DO put all MMIO devices under a bus node and not at the top-level.
|
|
|
|
- DO use non-empty 'ranges' to limit the size of child buses/devices. 64-bit
|
|
platforms don't need all devices to have 64-bit address and size.
|