提交设备树 (DT) 绑定补丁¶
I. 针对补丁提交者¶
来自 Submitting patches: the essential guide to getting your code into the kernel 的常规补丁提交规则适用。
补丁中 Documentation/ 和 include/dt-bindings/ 的部分应该是独立的补丁。绑定补丁的首选主题前缀是
"dt-bindings: <binding dir>: ..."少数子系统（如 ASoC、media、regulators、SCSI、SPI 和 UFS）期望基于子系统名称的前缀采用相反的顺序
"<binding dir>: dt-bindings: ..."主题的 80 个字符非常宝贵。建议不要使用 “Documentation”、“doc” 或 “YAML”，因为这些是隐含的。所有的绑定都是文档，且所有新的绑定都应该采用设备树 schema 格式。也应避免重复使用 “binding”，因此对于新设备，通常只需例如
"dt-bindings: iio: adc: Add ROHM BD79100G"将其他格式转换为 DT schema
"dt-bindings: iio: adc: adi,ad7476: Convert to DT schema"DT 绑定文件是使用 json-schema 词汇表和 YAML 文件格式以 DT schema 格式编写的。DT 绑定文件必须通过运行以下命令来通过验证
make dt_binding_check关于 schema 和工具设置的更多详情，请参阅 Writing Devicetree Bindings in json-schema。
DT 绑定文件应该是双重许可的。首选的许可标签是 (GPL-2.0-only OR BSD-2-Clause)。
将整个补丁系列提交到设备树邮件列表
并抄送 (Cc:) DT 维护者。使用 scripts/get_maintainer.pl 来确定所有的 DT 维护者。
补丁中 Documentation/ 的部分应该在实现该绑定的代码之前出现在补丁系列中。
在芯片或板级 DTS 文件中使用的任何兼容字符串必须预先记录在 Documentation/devicetree/bindings 中相应的 DT 绑定文件中。即使 Linux 设备驱动程序尚未匹配该兼容字符串，此规则也适用。[ 如果未遵循此步骤，checkpatch 将在 commit bff5da4335256513497cc8c79f9a9d1665e09864 (“checkpatch: add DT compatible string documentation checks”) 之后发出警告。 ]
DTS 通常被视为与驱动程序无关的硬件描述，因此任何 DTS 补丁，无论是否使用现有或新的绑定，都应单独发布，或者当与驱动程序补丁组合时，应放在补丁集的末尾，以表明驱动程序对 DTS 没有依赖关系。无论如何，DTS 都将通过单独的树或分支应用，因此不同的顺序会表明该系列不可二分。
如果驱动程序子系统维护者倾向于应用整个补丁集，而不是补丁集中与他们相关的部分，请将 DTS 补丁拆分为单独的补丁集，并在变更日志或封面信中引用邮件列表上的绑定提交。
如果已记录的兼容字符串尚未被驱动程序匹配，文档也应包含一个被驱动程序匹配的兼容字符串。
绑定不仅被 Linux 内核使用，还被多个其他项目积极使用，因此在对现有绑定进行更改时，可能需要格外小心和考虑。
II. 针对内核维护者¶
如果您不确定如何审查某个特定的绑定，请回复邮件并向设备树维护者寻求指导。这将有助于他们确定哪些需要优先审查，哪些可以放行。
对于驱动程序（非子系统）绑定：如果您对该绑定没问题，并且几周后仍未收到设备树维护者的 Acked-by，请直接采纳。
对于子系统绑定（任何影响多个设备的内容），必须由设备树维护者进行审查。
对于跨越多个树的系列，绑定补丁应与使用该绑定的驱动程序放在一起。
然而，DTS 文件永远不应通过驱动程序子系统树应用，而应始终通过平台 SoC 树上的专用分支应用（另请参阅 SoC Subsystem）。
III. 注释¶
关于设备树 ABI 的详情，请参阅 Devicetree (DT) ABI。
本文档旨在作为对 2013 年内核峰会上确定的流程的通用介绍。如有疑问，以当前设备树维护者的意见为准，而非本文档。在这种情况下，非常欢迎提交更新本文档的补丁。