2. SoC 子系统

2.1. 概述

SoC 子系统是 SoC 特定代码的聚合地。该子系统的主要组成部分是

  • 用于 32 位和 64 位 ARM 以及 RISC-V 的设备树

  • 32 位 ARM 板文件 (arch/arm/mach*)

  • 32 位和 64 位 ARM defconfig

  • 跨架构的 SoC 特定驱动程序，特别是用于 32 位和 64 位 ARM、RISC-V 和 Loongarch

这些“SoC 特定驱动程序”不包括具有其他顶级维护者的时钟、GPIO 等驱动程序。 drivers/soc/ 目录通常用于内核内部驱动程序，这些驱动程序由其他驱动程序使用，以提供特定于 SoC 的功能，例如识别 SoC 修订版或与电源域接口。

SoC 子系统也用作驱动程序/总线、驱动程序/固件、驱动程序/复位和驱动程序/内存更改的中间位置。新平台的添加或现有平台的删除通常通过 SoC 树作为涵盖多个子系统的专用分支。

主 SoC 树位于 git.kernel.org 上

https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/

2.2. 维护者

显然，这是一个相当广泛的主题，任何一个人，甚至一小群人，都无法维护。相反，SoC 子系统由许多子维护者（平台维护者）组成，每个人负责维护各自的平台和驱动程序子目录。在这方面，“平台”通常指的是来自给定供应商的一系列 SoC，例如 Nvidia 的 Tegra SoC 系列。许多子维护者在供应商级别运作，负责多个产品线。由于多种原因，包括公司内的收购/不同的业务部门，情况差异很大。各种子维护者记录在 MAINTAINERS 文件中。

大多数这些子维护者都有自己的树，他们在那里暂存补丁，并将拉取请求发送到主 SoC 树。这些树通常（但不总是）列在 MAINTAINERS 中。

然而，SoC 树不是架构特定代码更改的位置。每个架构都有自己的维护者，他们负责架构细节、CPU 勘误表等。

2.2.1. 提交给定 SoC 的补丁

所有典型的平台相关补丁都应通过 SoC 子维护者（平台特定的维护者）发送。这也包括对每个平台或共享的 defconfig 的更改（在这种情况下，scripts/get_maintainer.pl 可能无法提供正确的地址）。

2.2.2. 向主 SoC 维护者提交补丁

只有在以下情况下，才能通过别名 soc@kernel.org 联系到主 SoC 维护者

  1. 没有平台特定的维护者。

  2. 平台特定的维护者没有响应。

  3. 引入一个全新的 SoC 平台。这种新的 SoC 工作应首先发送到 scripts/get_maintainer.pl 指出的通用邮件列表，以供社区审查。在社区积极审查后，应在一个补丁集中将工作发送到 soc@kernel.org，其中包含新的 arch/foo/Kconfig 条目、DTS 文件、MAINTAINERS 文件条目以及可选的初始驱动程序及其设备树绑定。 MAINTAINERS 文件条目应列出新的平台特定维护者，他们将负责处理从现在开始的平台补丁。

请注意，soc@kernel.org 通常不是讨论补丁的地方，因此发送到此地址的工作应已被社区认为是可接受的。

2.3. （新）子维护者的信息

随着新平台的出现，它们通常会带来新的子维护者，其中许多人为硅供应商工作，可能不熟悉该流程。

2.3.1. 设备树 ABI 稳定性

也许需要强调的最重要的事情之一是 dt-bindings 文档记录了设备树和内核之间的 ABI。请阅读 设备树 (DT) ABI。

如果对设备树进行了与旧内核不兼容的更改，则在驱动程序准备就绪或适当的时间之后，才应应用设备树补丁。最重要的是，任何不兼容的更改都应在补丁说明和拉取请求中清楚地指出，以及对现有用户（例如引导加载程序或其他操作系统）的预期影响。

2.3.2. 驱动程序分支依赖关系

一个常见的问题是同步设备驱动程序和设备树文件之间的更改。即使更改在两个方向上都兼容，这也可能需要协调如何通过不同的维护者树合并更改。

通常，包含驱动程序更改的分支也将包含对设备树绑定描述的相应更改，以确保它们实际上是兼容的。这意味着设备树分支最终可能会导致“make dtbs_check”步骤中的警告。如果设备树更改依赖于 include/dt-bindings/ 中缺少标头文件的添加，它将使“make dtbs”步骤失败并且不会被合并。

有多种方法可以解决此问题

  • 避免在 include/dt-bindings/ 中为可以从数据手册派生的硬件常量定义自定义宏 - 只有在没有自然方法定义绑定时，才应将标头文件中的绑定宏作为最后的手段使用

  • 即使需要标头，也使用设备树文件中的文字值代替宏，并在后续版本中将它们更改为命名表示形式

  • 将设备树更改推迟到绑定和驱动程序已经合并后的版本

  • 在共享的不可变分支中更改绑定，该分支用作驱动程序更改和设备树更改的基础

  • 在设备树文件中添加由 #ifndef 部分保护的重复定义，并在以后的版本中删除它们

2.3.3. 设备树命名约定

设备树文件的一般命名方案如下。在 SoC 级别设置的平台的各个方面（例如 CPU 内核）包含在名为 $soc.dtsi 的文件中，例如 jh7100.dtsi。集成细节（因主板而异）在 $soc-$board.dts 中描述。一个例子是 jh7100-beaglev-starlight.dts。通常，许多主板都是一个主题的变体，并且经常存在中间文件，例如 jh7100-common.dtsi，它们位于 $soc.dtsi 和 $soc-$board.dts 文件之间，其中包含对常见硬件的描述。

某些平台还具有包含 SoC 的系统模块，然后将其集成到几个不同的主板中。对于这些平台，$soc-$som.dtsi 和 $soc-$som-$board.dts 是典型的。

目录通常以包含时 SoC 的供应商命名，从而导致树中出现一些历史目录名称。

2.3.4. 验证设备树文件

make dtbs_check 可用于验证设备树文件是否符合描述 ABI 的 dt-bindings。有关验证设备树的更多信息，请阅读 用 json-schema 编写设备树绑定 的“运行检查”部分。

对于新平台或对现有平台的添加，make dtbs_check 不应添加任何新警告。对于 RISC-V 和 Samsung SoC，需要 make dtbs_check W=1 以不添加任何新警告。如果对设备树更改有任何疑问，请联系设备树维护者。

2.3.5. 分支和拉取请求

正如主 SoC 树有多个分支一样，预计子维护者也会这样做。驱动程序、defconfig 和设备树更改都应拆分为单独的分支，并显示在发送给 SoC 维护者的单独拉取请求中。每个分支都应可以单独使用，并避免因依赖其他分支而产生的回归。

少量补丁也可以作为单独的电子邮件发送到 soc@kernel.org，并分组到相同的类别中。

如果更改不符合正常模式，则可以有其他顶级分支，例如，用于全树重做，或添加包含 dts 文件和驱动程序的新 SoC 平台。

大量更改的分支可以从拆分为单独的主题分支中受益，即使它们最终被合并到 SoC 树的同一分支中。这里的一个例子是用于修复设备树警告的一个分支，用于重做的一个分支，以及用于新添加的主板的一个分支。

拆分更改的另一种常见方法是在 rc1 和 rc4 之间的某个时间点发送一个早期拉取请求，其中包含大部分更改，然后在周期结束时跟进一个或多个较小的拉取请求，这些拉取请求可以添加后期更改或解决在测试第一组时发现的问题。

虽然没有后期拉取请求的截止时间，但随着时间越来越接近合并窗口，仅发送小分支会有所帮助。

可以随时发送当前版本错误修复的拉取请求，但同样，拥有多个较小的分支比尝试将太多补丁组合到一个拉取请求中更好。

拉取请求的主题行应以“[GIT PULL]”开头，并使用签名标签而不是分支。此标签应包含简要描述，总结拉取请求中的更改。有关发送拉取请求的更多详细信息，请参阅 创建拉取请求。