ACPI 與 Linux Kernel 整合

前面 24 章，你一直站在「韌體端」寫 ASL、除錯 ASL。本章換到桌子的 另一側：OS 工程師拿到你的 DSDT，是怎麼把 變成 、把 變成 的參數、 把 Method 變成一個 C 函式呼叫的？這是全書最長的一章，也是把你從 「會寫 ASL 的人」升級成「能做系統整合的韌體工程師」的一章—— 第 26 章 Project 1 的 裝置正是本章的主角。

全景圖：兩條路在核心會合

先把課綱的中心圖攤開。ACPI 這門技術有兩條產線：開發端把 人寫的 ASL 編譯成 AML、包進 DSDT／SSDT 燒入韌體；執行端 由 OS 內建的 interpreter 把 AML 解譯成 Namespace。兩條路在 Linux kernel 會合，往下才是 driver 與真正的硬體：

本章路線：25.2 先練 C 的暫存器基本功（圖的最底層）；25.3 看核心 怎麼列舉；25.4 寫出完整的 platform driver；25.5 與 25.6 補齊各 子系統與參數傳遞的膠水；25.7 回到韌體端看 EDK II 生產線；25.8 用一顆 LED 把全鏈路串一遍。

韌體工程師的 C 語言功力

為什麼講 ASL 的書要教 C？因為 ACPI 的兩端都是 C：韌體端的 EDK II 與 OS 端的 kernel／ACPICA 都是 C 專案，ASL 只是中間那層 描述語言。同一件事——讀一個暫存器的某幾個 bit——你必須會用兩種 語言寫，並且知道它們最後落到同一次匯流排存取。

pointer 與 volatile：跟編譯器搶控制權

C 的指標讓你把「位址」當一般變數操作，這是直接戳硬體的基礎。 但編譯器不知道某個位址背後是硬體：它看到迴圈裡重複讀同一個位址， 會「好心」只讀一次、把值快取在 CPU 暫存器——對一般記憶體是最佳化， 對硬體暫存器是災難。 就是告訴編譯器： 每次讀寫都必須真的執行，不准合併、不准刪除。

拿掉 ，開最佳化（）後這個迴圈會變成 死迴圈： 只被讀一次。另外注意 ——這正是第 24 章 的教訓在 C 端的 版本：輪詢硬體永遠要有停損。

同一件事在 ASL 怎麼寫？宣告 OperationRegion 與 Field，在 迴圈裡讀那個 Field（見 25.2.3 與第 9–11 章）。 關鍵差異是 ASL 不需要 volatile：Field 存取每次都由 interpreter 真的執行一次匯流排存取，天生 volatile。還要記得 只約束編譯器，不提供跨 CPU 的同步保證； kernel 裡也幾乎不直接解參考指標讀硬體，而是用 25.2.4 的 ／——它們把 volatile 語意、必要的 記憶體排序與可攜性一次包好。

struct 對齊與 __packed：描述線上格式

ACPI Table 是「線上格式」（wire format）：每個欄位的 byte 位置由 規格釘死。用 C struct 描述它時要小心對齊：編譯器為了讓 落在 4 的倍數位址，會在成員之間塞看不見的 padding， 一塞整個表就對不上了。 屬性禁止 padding：

這個 36 byte 的表頭你已經在第 22 章用 親眼看過。 實務備註：這個 layout 恰好天然對齊（欄位排列本來就沒有洞）， kernel 內建定義因此沒加 ，但描述韌體資料結構時 防禦性地加上是業界慣例；checksum 規則是「全表 byte 總和 mod 256 為 0」——第 21 章 iasl 幫你算，自己拼表（25.7 節）就得自己算。 對照 ASL： 的參數填的正是這些欄位， length 與 checksum 由 iasl 代勞。

位元操作：mask 與 shift 的肌肉記憶

硬體暫存器慣用「一個 32 bit 暫存器塞好幾個欄位」。C 端的標準動作 是 read-modify-write（RMW）：讀出、清掉目標欄位、填新值、寫回。 kernel 提供 、、 讓意圖一目瞭然：

同一顆暫存器在 ASL 裡怎麼描述？Field 直接把 bit 欄位「切」出名字， RMW 由 interpreter 代勞（ 正是「寫欄位時保留其他 bit」的意思，第 10 章）：

兩相對照就看出分工：ASL 把「欄位在哪」宣告成資料，C 把「欄位在哪」 寫成程式。韌體工程師的日常，就是拿著同一份暫存器規格表， 在兩邊寫出彼此一致的描述——欄位位置抄錯一位，兩邊就開始互相說謊。

MMIO 與 Port I/O：兩種戳硬體的匯流排

x86 平台有兩套定址空間。MMIO（memory-mapped I/O）把裝置 暫存器映進實體位址空間，kernel 中先 取得虛擬位址， 再用 ／ 存取；port I/O 是獨立的 64 KB I/O 空間，用 ／ 指令存取：

回傳的是帶 註記的 cookie， 不可直接解參考（靜態檢查工具 sparse 會抓），一律透過 ／ 系列；port I/O 則是 這樣的一行（0x80 是經典的 POST code 埠）。 ASL 端用 OperationRegion 的空間型別區分這兩種匯流排： 對應 MMIO（上一小節的 LEDR）， 對應 port I/O——宣告 加一個 8 bit Field 後，對該 Field 賦值就等於 。

四塊拼圖到此湊齊：指標與 volatile、struct 與對齊、bit 操作、 MMIO／port I/O。接下來看核心怎麼把 ASL 描述的裝置送到你的 C 程式手上。

Linux ACPI Subsystem：從 Namespace 到 device model

Linux 的 ACPI 程式碼分兩層，位置要背起來：

• ——： interpreter、Namespace、事件處理。這份程式碼與 iasl、 acpiexec 同一個上游專案，OS 無關。

• ——Linux 膠水層： （列舉）、、……把 ACPI 物件接上 Linux 自己的裝置模型。

• ——驅動工程師的 API 入口。

開機時，膠水層走訪 Namespace，替每個 建立一個 ——第 22 章在 看到的每個目錄就是它。這個結構 打包了韌體節點的一切：成員 存 ／ 等身分、 記錄 D-state、 是 25.6 節屬性 API 的掛載點，最後內嵌一個 讓它加入統一裝置模型。但 只是「韌體節點」 的化身，多數 driver 並不直接綁它。對於有 資源、 又不屬於特定匯流排的裝置，膠水層會再生一個 ——Linux 用來承載「不可列舉裝置」的 通用容器：

兩個世界在 sysfs 互相指認——ACPI 裝置目錄下的 symlink 指向 platform 裝置目錄，後者的 又指回來，用 即可驗證。 兩個例外先記著，25.5 節會展開： 裡若是 I2C／SPI 的 serial bus 描述子，裝置改由對應的 controller driver 建立 ／；PCI 裝置本來就自我列舉， ACPI 節點只是「伴侶」（companion），driver 可用 取回 呼叫 Method。

實作：綁定 DEMO0001 的 platform driver

理論夠了，動手寫。目標：一個完整可編譯的 kernel module，綁定 為 的裝置：probe 時讀出 的 MMIO 資源、呼叫 ASL 的 、把結果匯出成 sysfs attribute。它正是第 26 章 Project 1 的主角——先看 ASL 端：

沒寫 時核心視同「存在且啟用」（第 8 章）。driver 全文約 75 行，分兩段列出，第一段是私有資料與 sysfs attribute：

第二段是主體：probe 取資源、呼叫 ASL 的 、掛上 attribute，加上比對表與模組樣板：

逐段拆解： 拿到的 是 ACPI core 解析 的成果； 取回裝置的 Namespace 節點， 以它為起點用相對路徑 執行方法，參數包成 送進 ——kernel 電池驅動呼叫 （第 22 章）用的 是同一套機制。綁定則靠三件套： 表、 ，以及把表匯出成 modalias 別名 （）讓 udev 自動 的 。Makefile 與操作步驟：

整條鏈在這一刻閉合： 變成 dmesg 那行 MMIO 資源範圍；C 端傳入的 21 走進 乘以 2 回來；夾在中間的 是 ASL 方法執行的現場證明（需要第 23 章的兩道 閘門打開才看得到）。

各子系統的 ACPI 膠水

DEMO0001 走的是 platform bus；真實平台上更多裝置掛在 GPIO、I2C、 SPI、PCI 上。ACPI 對每種匯流排都定義了資源描述子，kernel 的對應 子系統負責翻譯： 配上 命名，C 端就能用 要腳位；／ 會自動生出 ／ ；PCI 裝置則以 與 配對。以下逐一給最小對照。

GPIO：GpioIo 加 _DSD 命名

ASL 端在 放 （或 ）描述 腳位，再用 給每組 GPIO 一個名字——C 端就是 用這個名字來要腳位的：

條目的值是四元素 Package：指回持有 的 裝置、 中第幾個 GPIO 資源、資源內第幾根腳、以及 active-low 旗標（此處 One 表示低電位有效）。C 端把 去掉字尾變成名字 ：

注意 API 談的是邏輯值： 已宣告 active-low，邏輯 1（assert reset）在硬體上輸出低電位。極性由韌體 描述、C 程式碼保持中立——這正是把硬體細節放進 ACPI 的價值。

I2C 與 SPI：描述即列舉

I2C 裝置的位址、速度、掛在哪個 controller，全部寫在 裡。當 I2C controller driver 註冊 adapter 時，核心掃描 Namespace，替每個引用它的裝置自動建立 ——driver 完全不用自己 instantiate：

註冊樣板與 25.4 同構，不再重列： 表填 ，掛進 的比對表欄位，最後用 收尾。SPI 的邏輯也完全同構： 描述 chip select、線模式、速度與時脈 極性，controller 註冊時自動生出 ，由 以同樣的比對表認領：

PCI：_ADR 配對與 _PRT 一句話

PCI 裝置能自我列舉（第 1 章），所以 ACPI 節點不負責「發現」， 只負責「補充」：以 （高 16 bit 是 device、低 16 bit 是 function）宣告自己對應哪個 PCI 位址，核心據此把 ACPI 節點與 配成 companion，電源方法（／ ）與 才有處落地：

至於中斷：PCI root bridge 下的 （PCI Routing Table） 負責把每個裝置的 INTA–INTD 腳對應到中斷控制器輸入——一句話記住 它：PCI 傳統中斷的路由表由 ACPI 提供，MSI 則不經過它。

_DSD 與 device properties：韌體傳參數給驅動

GPIO 小節已經偷用過 （Device Specific Data）；它的 一般形式是「UUID 加 key-value Package」，等於韌體塞給 driver 的 組態檔。搭配的 C 端 API 是 家族：

字串與布林屬性各有對應 API（；布林以 查「存在即為真」）。命名慣例： 屬性名用小寫加連字號（沿襲 Device Tree 傳統），單位直接寫進名字 （、）讓讀的人不用猜。

韌體端：EDK II 的 ACPI 表生產線

視角換回韌體端。你寫好的 在 UEFI 韌體專案 （）裡是這樣被生產、運送、交貨的。先看它住哪裡：

由 iasl 編譯； 是 EDK II 慣例的 「用 C 寫的表」——像 FADT 這種純欄位的表，直接定義一個 25.2.2 風格的 struct 常數即可。建置時 iasl 以 選項執行，除了 還會多吐一個 ——AML 映像的 C 陣列版，讓韌體能以原始碼形式攜帶這張表：

開頭八個 byte 正是 25.2.2 表頭 struct 的前兩個欄位： 與 little-endian 的長度 0xFC0＝4032。整條生產線：

開機時，平台的 driver 在 FV 裡按 GUID 找到 裝表的 FFS 檔，逐張呼叫 ：把表複製到 ACPI 保留記憶體、填進 XSDT、重算 checksum——第 1 章那條 「RSDP \(\to\) XSDT \(\to\) 各表」的鏈就是在這一刻搭好的。

最後，bring-up 時三張「非 AML」的表各自要填什麼 （DSDT 描述裝置，這三張描述平台骨架）：

端到端案例：一顆 LED 的旅程

收尾前，把全書串成一個故事。硬體工程師遞來一頁規格：「LED 控制器，MMIO 基底 ，offset 0 是控制暫存器： bit 0 enable、bits 7..4 亮度，開機預設關。讓使用者能從 Linux 控制它。」你的整合路線：

每一站都是你已經修過的學分：讀懂暫存器規格、規劃 bit 欄位靠 25.2 的 C 功力與第 9–11 章的 Field 語意；寫 Device、 、 是第 8 章與第 18–20 章的 SSDT 實戰； 編譯與靜態驗證交給第 21 章的 iasl 與 fwts；整合進韌體走 25.7 的 EDK II 生產線（或第 23 章的 initrd 捷徑）；列舉與 driver 綁定是 25.3 與 25.4；驗證與除錯的整套工具則在 Module 10（第 22–24 章）。

ASL 端你已經會了：25.2.3 的 region 加 ／ 兩個欄位，包成一個 為 的 Device，配上對應的 。driver 端沿用 25.4 的骨架， 兩處小改：probe 用 把資源映成 指標；sysfs attribute 換成可寫版本，先以 把字串轉成 0–15 的亮度值， 再照搬 25.2.3 的 那組 RMW 序列寫進暫存器， 回傳 收工。

於是「」 這個再平凡不過的指令，背後是：韌體描述（ASL）\(\to\) 編譯（iasl） \(\to\) 韌體安裝（EDK II）\(\to\) 核心列舉（ACPI subsystem）\(\to\) driver 綁定（）\(\to\) 位址翻譯（ 加 ）\(\to\) 位元操作（RMW）\(\to\) 光子離開 LED。 若哪一站斷了，Module 10 的整套工具（dmesg、sysfs、Debug 物件、 ACPI Error 解剖）都在等你。第 26 章起的實戰專案，會讓你把這條鏈 親手走上五遍。