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]”開頭，並使用簽名標籤而不是分支。此標籤應包含簡要描述，總結拉取請求中的更改。有關傳送拉取請求的更多詳細資訊，請參閱 建立拉取請求。