尧图网页设计 
Linux 内核 Devicetree Binding 补丁提交指南从 schema 编写到合入的完整流程【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linuxDevicetreeDTbinding 是描述硬件节点与属性契约的规范文档它是内核中连接设备树DTS与设备驱动的重要桥梁。本文以 Documentation/devicetree/bindings/submitting-patches.rst 为核心系统讲解 Linux 内核中 DT binding 补丁的提交规范、审查流程与验证工具链从补丁拆分、主题前缀、json-schema/YAML 格式要求到make dt_binding_check验证、compatible 字符串文档化规则以及维护者的合入决策标准。读完本文你将能够按照内核社区认可的流程正确撰写、验证并提交一份合规的 DT binding 补丁。一、DT binding 补丁的定位与整体流程在 Linux 内核中DT binding 补丁并非普通的功能补丁它有自己独立的提交流程。文档开篇即明确原文档 I.0通用补丁提交规则同样适用其基础是 Documentation/process/submitting-patches.rst。这意味着checkpatch.pl、正确的 commit message 格式、Signed-off-by等通用要求一个都不能少。在此基础上DT binding 补丁还叠加了以下特殊约束文档与代码分离Documentation/与include/dt-bindings/相关的部分应作为独立补丁提交原文档 I.1必须通过 schema 验证binding 文件必须通过make dt_binding_check原文档 I.2遵循双重许可推荐(GPL-2.0-only OR BSD-2-Clause)许可标签原文档 I.3发往专用邮件列表提交到devicetreevger.kernel.org并抄送 DT 维护者原文档 I.4先文档后代码Documentation/部分应排在实现代码之前进入系列patchset原文档 I.5。从仓库结构可以看到DT binding 文件全部集中在 Documentation/devicetree/bindings/ 目录下按子系统如iio/、gpio/、clock/分目录组织每个 binding 是一个独立的.yaml文件。二、补丁拆分与主题前缀规范2.1 推荐前缀dt-bindings: : ...原文档 I.1 明确推荐 DT binding 补丁的主题前缀格式为dt-bindings: binding dir: ...例如新增一个 ROHM BD79100G ADC 芯片的 binding主题可以写成dt-bindings: iio: adc: Add ROHM BD79100G注意其中的细节80 字符的标题栏subject非常宝贵因此不推荐再写Documentation、doc或YAML等词——因为所有 binding 都是文档且所有新 binding 都必须是 DT schema即 YAML格式这些词属于冗余信息。同样应避免重复出现binding一词。2.2 少数子系统的反序前缀原文档 I.1 特别指出少数子系统期望反序前缀即基于子系统名binding dir: dt-bindings: ...这些子系统包括ASoC音频、media、regulators、SCSI、SPI 和 UFS。提交这些子系统的 binding 时需要先写 binding 目录再写dt-bindings。例如 SPI 子系统的写法应为spi: dt-bindings: ...而非dt-bindings: spi: ...。2.3 格式转换补丁的命名如果要将旧格式的 binding 转换为 DT schemaYAML推荐格式为dt-bindings: iio: adc: adi,ad7476: Convert to DT schema即包含原 binding 名如adi,ad7476与Convert to DT schema动作描述。三、DT schema 格式与双重验证要求3.1 binding 文件的格式本质原文档 I.2 规定DT binding 文件使用 json-schema 词汇表与 YAML 文件格式编写。YAML 之所以被选用是因为它是 JSON 兼容的子集且更易读、支持#注释。完整的 schema 编写规范见 Documentation/devicetree/bindings/writing-schema.rst其中定义了顶层关键字$id唯一 URI 标识必须以http://devicetree.org/schemas/开头、$schema元 schema、title、maintainers、description、select、allOf、properties、patternProperties、required、additionalProperties/unevaluatedProperties、examples等。一份可直接参考的完整示例位于 Documentation/devicetree/bindings/example-schema.yaml其中演示了compatible的oneOf写法、reg/reg-names的 items 约束、interrupts的可变数量、厂商特定属性必须引用/schemas/types.yaml#/definitions/uint32等类型定义并附带description、子节点的additionalProperties处理、if:then:条件约束、以及examples中 DTS 片段的四空格缩进写法等。3.2 必须通过make dt_binding_check原文档 I.2 的核心硬性要求是binding 文件必须通过验证make dt_binding_check该目标在 Documentation/devicetree/bindings/Makefile 中定义实际包含三条子检查.dt-binding.checked调用dt-doc-validate用元 schemaschema 的 schema验证每个 binding 文件既是合法 json-schema 又是合法 binding schema.yamllint.checked调用yamllint做 YAML 语法与风格检查未安装时仅告警并跳过.dt-style.checked调用 scripts/dtc/dt-check-style 检查示例 DTS 的编码风格。3.3 示例 DTS 的 strict 模式风格检查原文档 I.2 还要求新 binding 中的示例 DTS 应通过scripts/dtc/dt-check-style的 strict 模式且无警告。从 scripts/dtc/dt-check-style 源码可以看到strict 模式启用了indent-unit缩进单位必须为 4 空格、indent-consistent、blank-lines、child-address-order、child-name-order、property-order、hex-case、unit-address-format、value-whitespace、node-close-alone、line-length、continuation-alignment、unused-labels等规则并附有注释说明 strict rules are opt-in (e.g. for new submissions via ...)——即新提交必须满足。DTS 编码风格细则可参考 Documentation/devicetree/bindings/dts-coding-style.rst例如节点/属性名仅允许[a-z]、[0-9]、-单位地址用无前导零的小写十六进制属性顺序为device_type→compatible→reg→ranges→公共属性→厂商属性→status→子节点等。四、许可、邮件列表与提交顺序4.1 双重许可原文档 I.3DT binding 文件应使用双重许可推荐许可标签为(GPL-2.0-only OR BSD-2-Clause)。仓库中的 Documentation/devicetree/bindings/example-schema.yaml 第一行即为此标签的实际范例。这样做的目的是便于其他项目如 U-Boot、Zephyr、dtc 等复用这份硬件描述。4.2 发往 devicetree 邮件列表原文档 I.4整个补丁系列应提交到 devicetree 邮件列表devicetreevger.kernel.org并抄送CcDT 维护者。使用 scripts/get_maintainer.pl 可以自动识别所有相关维护者./scripts/get_maintainer.pl 补丁文件4.3 先文档、后代码原文档 I.5Documentation/部分即 binding 文档应在实现该 binding 的代码之前进入补丁系列。这种顺序确保评审者先看到硬件契约的完整定义再审视驱动对契约的实现符合契约先行的工程实践。五、compatible 字符串的文档化硬性规则5.1 先有文档后有使用原文档 I.6原文档 I.6 是一条不容忽视的硬性规则任何出现在芯片chip或板级boardDTS 文件中的 compatible 字符串必须事先在 Documentation/devicetree/bindings 目录下对应的 DT binding 文件中记录在案。即使对应的 Linux 设备驱动尚未匹配该字符串这一规则依然生效——因为 DTS 被视作独立于驱动的硬件描述。这条规则由checkpatch.pl强制执行。从 scripts/checkpatch.pl 源码可见它会检测 DT compatible string ... appears un-documented 并发出警告该检查自 commitbff5da4335256513497cc8c79f9a9d1665e09864checkpatch: add DT compatible string documentation checks起生效。同时 scripts/checkpatch.pl 也会识别补丁是否涉及Documentation/devicetree/或include/dt-bindings/从而对 binding 补丁施加相应规则。5.2 驱动匹配字符串必须体现原文档 I.8反向的补充规则原文档 I.8如果文档化的 compatible 字符串尚未被驱动匹配那么文档中还应包含一个驱动确实会匹配的 compatible 字符串。这保证了 binding 文档与实际驱动行为始终存在交集避免出现文档描述了一堆字符串但驱动一个都不认的悬空状态。六、DTS 补丁的独立性与可二分性原文档 I.7 强调DTS 在原则上被视作与驱动无关的硬件描述。因此任何 DTS 补丁都应单独发布posting若与驱动补丁合并则应放置在补丁集的末尾以表明驱动不依赖 DTS原因在于 DTS 会通过独立的树或分支应用通常是平台 SoC 树如果 DTS 补丁混在驱动补丁中间会破坏整个系列的可二分性bisectable即逐补丁编译时可能出现中间态不可用的情况若驱动子系统维护者希望整体应用整套补丁则应将 DTS 补丁拆分成独立补丁集并在 changelog 或 cover letter 中引用对应 binding 的邮件列表提交。从源码结构看DTS 文件分散在各架构目录如 arch/arm64/boot/dts/、arch/arm/boot/dts/与 binding 文档Documentation/devicetree/bindings/分属不同的树维护正印证了这一分工。七、现有 binding 的稳定性与 ABI 意识7.1 多项目共用的谨慎原文档 I.9原文档 I.9 提醒binding 并非只有 Linux 内核在使用其他多个项目同样积极消费这些契约。因此修改现有 binding 时需要格外谨慎任何语义变更都可能波及内核之外的生态。7.2 DT ABI 的稳定原则原文档 III.0原文档 III.0 指向 Documentation/devicetree/bindings/ABI.rst后者引用了 2013 ARM mini-summit 的结论stable binding 意味着更新版本的内核不会在新内核上破坏旧的设备树但 binding 并非永久冻结。允许的演进方式包括新增属性时若该属性缺失则默认回退到旧行为确需不兼容变更时同时更换 compatible 字符串让驱动同时匹配新旧字符串。此外还有若干通用规则不要因为追求完美而阻塞 binding 合入dont let perfect be the enemy of good使用足够具体的 compatible 字符串以便未来演进可以增补属性但不得改变既有属性的含义驱动在新属性缺失时保持原有行为不要为 staging 或不稳定的代码提交 binding。八、内核维护者的审查与合入决策原文档第二部分II专门面向内核维护者规定了 binding 补丁的审查分工求助机制如果对某个 binding 的审查没有把握应回复并请求 devicetree 维护者指导这有助于他们区分优先审查项与可放行项合入权限分层对驱动非子系统binding若你熟悉该 binding且数周内未收到 devicetree 维护者的 Acked-by可以自行合入对子系统 binding影响超过单个设备的任何变更必须经过 devicetree 维护者审查不可绕过跨树系列当一个系列会经过多棵树时binding 补丁应与使用该 binding 的驱动保持在同一条树路径中DTS 的合入通道DTS 文件绝不应通过驱动子系统树应用而必须通过平台 SoC 树上的专用分支应用参见 Documentation/process/maintainer-soc.rst。九、实战验证工具链搭建与常用命令结合 Documentation/devicetree/bindings/writing-schema.rst 与 Documentation/devicetree/bindings/Makefile完整的验证环境搭建与命令如下。9.1 安装 dtschema 工具DT schema 验证依赖dtschemaPython 包通过 pip 安装pip3 install dtschema在 Debian/Ubuntu 系上dtschema依赖swig与 Python 开发头文件需先安装apt install swig python3-dev安装后会提供dt-doc-validate、dt-mk-schema、dt-validate等可执行文件请确保它们位于 PATH 中默认在~/.local/bin。推荐同时安装yamllintdtschema 检测到时会自动使用。仓库 Documentation/devicetree/bindings/Makefile 还规定dtschema最低版本为v2024.4版本不足会直接报错。9.2 验证命令速查命令作用make dt_binding_check校验所有 binding 文档元 schema 校验 yamllint 示例 DTS 风格make sram/sram.yaml只校验单个 schema 及其示例make dtbs_check用 DT schema 校验 DTS 源文件会跳过有错误的 binding schemamake dt_binding_check dtbs_check一次执行两类检查make dt_binding_check DT_SCHEMA_FILEStrivial-devices.yaml只检查指定 schema 文件make dt_binding_check DT_SCHEMA_FILEStrivial-devices.yaml:rtc.yaml同时指定多个文件以:分隔make dtbs_check DT_SCHEMA_FILES/gpio/按目录/前缀模式过滤匹配的 schema注意dtbs_check会跳过任何有错误的 binding schema 文件因此要拿到 binding 文件本身的全部错误必须运行dt_binding_check。DT_SCHEMA_FILES支持固定字符串的部分匹配用于在大型内核源码树上快速迭代单个文件。十、提交前自检清单综合全文档提交一份 DT binding 补丁前请逐项确认已按通用规则编写 commit message 并附带Signed-off-by见 Documentation/process/submitting-patches.rstDocumentation/与include/dt-bindings/内容已拆分为独立补丁主题前缀符合dt-bindings: binding dir: ...ASoC/media/regulators/SCSI/SPI/UFS 为反序且 80 字符内无冗余词binding 文件为 json-schema YAML 格式make dt_binding_check全部通过示例 DTS 通过scripts/dtc/dt-check-stylestrict 模式且无警告文件头部使用(GPL-2.0-only OR BSD-2-Clause)双重许可标签系列已提交至devicetreevger.kernel.org并通过scripts/get_maintainer.pl抄送维护者Documentation/部分排在实现代码之前所有 compatible 字符串已文档化checkpatch 无 un-documented 警告且至少有一个字符串与驱动实际匹配DTS 补丁已单独发布或置于补丁集末尾保证可二分性修改既有 binding 时已评估对内核外项目与 DT ABI 稳定性的影响。最后如原文档 III.1 所述本流程是 2013 Kernel Summit 所确定机制的通用介绍当有疑问时devicetree 维护者的最新意见具有最终效力若发现流程与实际有出入欢迎提交更新本文档的补丁。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Linux 内核 Devicetree Binding 补丁提交指南：从 schema 编写到合入的完整流程
Linux 内核 Devicetree Binding 补丁提交指南从 schema 编写到合入的完整流程【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linuxDevicetreeDTbinding 是描述硬件节点与属性契约的规范文档它是内核中连接设备树DTS与设备驱动的重要桥梁。本文以 Documentation/devicetree/bindings/submitting-patches.rst 为核心系统讲解 Linux 内核中 DT binding 补丁的提交规范、审查流程与验证工具链从补丁拆分、主题前缀、json-schema/YAML 格式要求到make dt_binding_check验证、compatible 字符串文档化规则以及维护者的合入决策标准。读完本文你将能够按照内核社区认可的流程正确撰写、验证并提交一份合规的 DT binding 补丁。一、DT binding 补丁的定位与整体流程在 Linux 内核中DT binding 补丁并非普通的功能补丁它有自己独立的提交流程。文档开篇即明确原文档 I.0通用补丁提交规则同样适用其基础是 Documentation/process/submitting-patches.rst。这意味着checkpatch.pl、正确的 commit message 格式、Signed-off-by等通用要求一个都不能少。在此基础上DT binding 补丁还叠加了以下特殊约束文档与代码分离Documentation/与include/dt-bindings/相关的部分应作为独立补丁提交原文档 I.1必须通过 schema 验证binding 文件必须通过make dt_binding_check原文档 I.2遵循双重许可推荐(GPL-2.0-only OR BSD-2-Clause)许可标签原文档 I.3发往专用邮件列表提交到devicetreevger.kernel.org并抄送 DT 维护者原文档 I.4先文档后代码Documentation/部分应排在实现代码之前进入系列patchset原文档 I.5。从仓库结构可以看到DT binding 文件全部集中在 Documentation/devicetree/bindings/ 目录下按子系统如iio/、gpio/、clock/分目录组织每个 binding 是一个独立的.yaml文件。二、补丁拆分与主题前缀规范2.1 推荐前缀dt-bindings: : ...原文档 I.1 明确推荐 DT binding 补丁的主题前缀格式为dt-bindings: binding dir: ...例如新增一个 ROHM BD79100G ADC 芯片的 binding主题可以写成dt-bindings: iio: adc: Add ROHM BD79100G注意其中的细节80 字符的标题栏subject非常宝贵因此不推荐再写Documentation、doc或YAML等词——因为所有 binding 都是文档且所有新 binding 都必须是 DT schema即 YAML格式这些词属于冗余信息。同样应避免重复出现binding一词。2.2 少数子系统的反序前缀原文档 I.1 特别指出少数子系统期望反序前缀即基于子系统名binding dir: dt-bindings: ...这些子系统包括ASoC音频、media、regulators、SCSI、SPI 和 UFS。提交这些子系统的 binding 时需要先写 binding 目录再写dt-bindings。例如 SPI 子系统的写法应为spi: dt-bindings: ...而非dt-bindings: spi: ...。2.3 格式转换补丁的命名如果要将旧格式的 binding 转换为 DT schemaYAML推荐格式为dt-bindings: iio: adc: adi,ad7476: Convert to DT schema即包含原 binding 名如adi,ad7476与Convert to DT schema动作描述。三、DT schema 格式与双重验证要求3.1 binding 文件的格式本质原文档 I.2 规定DT binding 文件使用 json-schema 词汇表与 YAML 文件格式编写。YAML 之所以被选用是因为它是 JSON 兼容的子集且更易读、支持#注释。完整的 schema 编写规范见 Documentation/devicetree/bindings/writing-schema.rst其中定义了顶层关键字$id唯一 URI 标识必须以http://devicetree.org/schemas/开头、$schema元 schema、title、maintainers、description、select、allOf、properties、patternProperties、required、additionalProperties/unevaluatedProperties、examples等。一份可直接参考的完整示例位于 Documentation/devicetree/bindings/example-schema.yaml其中演示了compatible的oneOf写法、reg/reg-names的 items 约束、interrupts的可变数量、厂商特定属性必须引用/schemas/types.yaml#/definitions/uint32等类型定义并附带description、子节点的additionalProperties处理、if:then:条件约束、以及examples中 DTS 片段的四空格缩进写法等。3.2 必须通过make dt_binding_check原文档 I.2 的核心硬性要求是binding 文件必须通过验证make dt_binding_check该目标在 Documentation/devicetree/bindings/Makefile 中定义实际包含三条子检查.dt-binding.checked调用dt-doc-validate用元 schemaschema 的 schema验证每个 binding 文件既是合法 json-schema 又是合法 binding schema.yamllint.checked调用yamllint做 YAML 语法与风格检查未安装时仅告警并跳过.dt-style.checked调用 scripts/dtc/dt-check-style 检查示例 DTS 的编码风格。3.3 示例 DTS 的 strict 模式风格检查原文档 I.2 还要求新 binding 中的示例 DTS 应通过scripts/dtc/dt-check-style的 strict 模式且无警告。从 scripts/dtc/dt-check-style 源码可以看到strict 模式启用了indent-unit缩进单位必须为 4 空格、indent-consistent、blank-lines、child-address-order、child-name-order、property-order、hex-case、unit-address-format、value-whitespace、node-close-alone、line-length、continuation-alignment、unused-labels等规则并附有注释说明 strict rules are opt-in (e.g. for new submissions via ...)——即新提交必须满足。DTS 编码风格细则可参考 Documentation/devicetree/bindings/dts-coding-style.rst例如节点/属性名仅允许[a-z]、[0-9]、-单位地址用无前导零的小写十六进制属性顺序为device_type→compatible→reg→ranges→公共属性→厂商属性→status→子节点等。四、许可、邮件列表与提交顺序4.1 双重许可原文档 I.3DT binding 文件应使用双重许可推荐许可标签为(GPL-2.0-only OR BSD-2-Clause)。仓库中的 Documentation/devicetree/bindings/example-schema.yaml 第一行即为此标签的实际范例。这样做的目的是便于其他项目如 U-Boot、Zephyr、dtc 等复用这份硬件描述。4.2 发往 devicetree 邮件列表原文档 I.4整个补丁系列应提交到 devicetree 邮件列表devicetreevger.kernel.org并抄送CcDT 维护者。使用 scripts/get_maintainer.pl 可以自动识别所有相关维护者./scripts/get_maintainer.pl 补丁文件4.3 先文档、后代码原文档 I.5Documentation/部分即 binding 文档应在实现该 binding 的代码之前进入补丁系列。这种顺序确保评审者先看到硬件契约的完整定义再审视驱动对契约的实现符合契约先行的工程实践。五、compatible 字符串的文档化硬性规则5.1 先有文档后有使用原文档 I.6原文档 I.6 是一条不容忽视的硬性规则任何出现在芯片chip或板级boardDTS 文件中的 compatible 字符串必须事先在 Documentation/devicetree/bindings 目录下对应的 DT binding 文件中记录在案。即使对应的 Linux 设备驱动尚未匹配该字符串这一规则依然生效——因为 DTS 被视作独立于驱动的硬件描述。这条规则由checkpatch.pl强制执行。从 scripts/checkpatch.pl 源码可见它会检测 DT compatible string ... appears un-documented 并发出警告该检查自 commitbff5da4335256513497cc8c79f9a9d1665e09864checkpatch: add DT compatible string documentation checks起生效。同时 scripts/checkpatch.pl 也会识别补丁是否涉及Documentation/devicetree/或include/dt-bindings/从而对 binding 补丁施加相应规则。5.2 驱动匹配字符串必须体现原文档 I.8反向的补充规则原文档 I.8如果文档化的 compatible 字符串尚未被驱动匹配那么文档中还应包含一个驱动确实会匹配的 compatible 字符串。这保证了 binding 文档与实际驱动行为始终存在交集避免出现文档描述了一堆字符串但驱动一个都不认的悬空状态。六、DTS 补丁的独立性与可二分性原文档 I.7 强调DTS 在原则上被视作与驱动无关的硬件描述。因此任何 DTS 补丁都应单独发布posting若与驱动补丁合并则应放置在补丁集的末尾以表明驱动不依赖 DTS原因在于 DTS 会通过独立的树或分支应用通常是平台 SoC 树如果 DTS 补丁混在驱动补丁中间会破坏整个系列的可二分性bisectable即逐补丁编译时可能出现中间态不可用的情况若驱动子系统维护者希望整体应用整套补丁则应将 DTS 补丁拆分成独立补丁集并在 changelog 或 cover letter 中引用对应 binding 的邮件列表提交。从源码结构看DTS 文件分散在各架构目录如 arch/arm64/boot/dts/、arch/arm/boot/dts/与 binding 文档Documentation/devicetree/bindings/分属不同的树维护正印证了这一分工。七、现有 binding 的稳定性与 ABI 意识7.1 多项目共用的谨慎原文档 I.9原文档 I.9 提醒binding 并非只有 Linux 内核在使用其他多个项目同样积极消费这些契约。因此修改现有 binding 时需要格外谨慎任何语义变更都可能波及内核之外的生态。7.2 DT ABI 的稳定原则原文档 III.0原文档 III.0 指向 Documentation/devicetree/bindings/ABI.rst后者引用了 2013 ARM mini-summit 的结论stable binding 意味着更新版本的内核不会在新内核上破坏旧的设备树但 binding 并非永久冻结。允许的演进方式包括新增属性时若该属性缺失则默认回退到旧行为确需不兼容变更时同时更换 compatible 字符串让驱动同时匹配新旧字符串。此外还有若干通用规则不要因为追求完美而阻塞 binding 合入dont let perfect be the enemy of good使用足够具体的 compatible 字符串以便未来演进可以增补属性但不得改变既有属性的含义驱动在新属性缺失时保持原有行为不要为 staging 或不稳定的代码提交 binding。八、内核维护者的审查与合入决策原文档第二部分II专门面向内核维护者规定了 binding 补丁的审查分工求助机制如果对某个 binding 的审查没有把握应回复并请求 devicetree 维护者指导这有助于他们区分优先审查项与可放行项合入权限分层对驱动非子系统binding若你熟悉该 binding且数周内未收到 devicetree 维护者的 Acked-by可以自行合入对子系统 binding影响超过单个设备的任何变更必须经过 devicetree 维护者审查不可绕过跨树系列当一个系列会经过多棵树时binding 补丁应与使用该 binding 的驱动保持在同一条树路径中DTS 的合入通道DTS 文件绝不应通过驱动子系统树应用而必须通过平台 SoC 树上的专用分支应用参见 Documentation/process/maintainer-soc.rst。九、实战验证工具链搭建与常用命令结合 Documentation/devicetree/bindings/writing-schema.rst 与 Documentation/devicetree/bindings/Makefile完整的验证环境搭建与命令如下。9.1 安装 dtschema 工具DT schema 验证依赖dtschemaPython 包通过 pip 安装pip3 install dtschema在 Debian/Ubuntu 系上dtschema依赖swig与 Python 开发头文件需先安装apt install swig python3-dev安装后会提供dt-doc-validate、dt-mk-schema、dt-validate等可执行文件请确保它们位于 PATH 中默认在~/.local/bin。推荐同时安装yamllintdtschema 检测到时会自动使用。仓库 Documentation/devicetree/bindings/Makefile 还规定dtschema最低版本为v2024.4版本不足会直接报错。9.2 验证命令速查命令作用make dt_binding_check校验所有 binding 文档元 schema 校验 yamllint 示例 DTS 风格make sram/sram.yaml只校验单个 schema 及其示例make dtbs_check用 DT schema 校验 DTS 源文件会跳过有错误的 binding schemamake dt_binding_check dtbs_check一次执行两类检查make dt_binding_check DT_SCHEMA_FILEStrivial-devices.yaml只检查指定 schema 文件make dt_binding_check DT_SCHEMA_FILEStrivial-devices.yaml:rtc.yaml同时指定多个文件以:分隔make dtbs_check DT_SCHEMA_FILES/gpio/按目录/前缀模式过滤匹配的 schema注意dtbs_check会跳过任何有错误的 binding schema 文件因此要拿到 binding 文件本身的全部错误必须运行dt_binding_check。DT_SCHEMA_FILES支持固定字符串的部分匹配用于在大型内核源码树上快速迭代单个文件。十、提交前自检清单综合全文档提交一份 DT binding 补丁前请逐项确认已按通用规则编写 commit message 并附带Signed-off-by见 Documentation/process/submitting-patches.rstDocumentation/与include/dt-bindings/内容已拆分为独立补丁主题前缀符合dt-bindings: binding dir: ...ASoC/media/regulators/SCSI/SPI/UFS 为反序且 80 字符内无冗余词binding 文件为 json-schema YAML 格式make dt_binding_check全部通过示例 DTS 通过scripts/dtc/dt-check-stylestrict 模式且无警告文件头部使用(GPL-2.0-only OR BSD-2-Clause)双重许可标签系列已提交至devicetreevger.kernel.org并通过scripts/get_maintainer.pl抄送维护者Documentation/部分排在实现代码之前所有 compatible 字符串已文档化checkpatch 无 un-documented 警告且至少有一个字符串与驱动实际匹配DTS 补丁已单独发布或置于补丁集末尾保证可二分性修改既有 binding 时已评估对内核外项目与 DT ABI 稳定性的影响。最后如原文档 III.1 所述本流程是 2013 Kernel Summit 所确定机制的通用介绍当有疑问时devicetree 维护者的最新意见具有最终效力若发现流程与实际有出入欢迎提交更新本文档的补丁。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考