Asahi Linux 团队发了 Linux 7.2 的进展报告。这类报告我每期都看，因为它是少数几个"大规模逆向未公开硬件"的一线记录——你要在没有文档、没有厂商支持的前提下，把一整块 SoC 接到 Linux 上，遇到的每个问题都是新的。

这一期有两个进展值得单独说：M3 系列的 USB 3.0 和雷电支持打通了，以及苹果的电源管理基础设施终于有了一个能被上游接受的接口。

问题：苹果的电源管理不走标准路

报告开篇讲的是 Apple Silicon 的电源管理架构，这是理解后面所有工作的前提。

苹果把电源管理职责拆到了多个硬件块上，报告里点了三个：SMC（System Management Controller）、PMGR（Power Manager）、PMP。这三者之间怎么协作、谁负责给谁上电、时序怎么排，全部没有公开文档。

正常情况下，一块 SoC 的电源管理对操作系统来说是"调一个标准接口"的事。但在 arm64 上，上游内核有一个硬性要求：所有要进主线的硬件必须使用 PSCI（Power State Coordination Interface）来做电源管理。arm64 的架构维护者明确反对在核心里塞厂商私有的电源管理钩子，理由很直接——如果每家都往里加自己的 hack，arm64 的架构代码会退化成一堆特例的集合。

苹果不用 PSCI。它有自己的那一套（SMC/PMGR/PMP）。所以在 Asahi 的语境里，"支持电源管理"这件事变成了：写一层把苹果的私有机制包装成 PSCI 语义的适配层，让内核以为自己面对的是一个标准接口。

这个决定影响很深。适配层不只是"翻译调用"，还要处理 PSCI 假定的状态模型（CPU idle、hotplug、suspend）和苹果实际状态机之间的语义差异。做得不完整，表现就是睡眠唤醒随机失败、CPU 热插拔崩核这类难查的问题。

M3 的 USB3 与雷电

这期报告里最实在的进展是：SPMI 接口和 ACE3 现在能在 Asahi Linux 上工作了，结果是 M3 系列设备拿到了 USB 3.0 和雷电支持。

对 M3 用户来说，这意味着外接硬盘、扩展坞、雷电显示器这一整类外设从"不工作"变成"能用"。这类进展在逆向 Linux 的语境里，通常代表团队已经摸清了控制器与电源块之间的初始化序列——哪些寄存器要先配、哪个电源域要先开、时序上哪些步骤不能乱。SPMI（System Power Management Interface）就是这类带内电源管理总线，苹果用它做细粒度的电压/时钟协商。把它跑通，是让高速外设真正动起来的前提。

显示：追 ABI 的代价

报告里还有一段关于显示的内容，讲的是 DCP（Display Coprocessor）。

苹果的显示控制器跑的是自己的固件，Linux 侧要跟它通信，就得按苹果定的 ABI 来。麻烦在于这个 ABI 会随 macOS 版本变化：M1/M2 用的是 macOS 13.5 这一版的 ABI，而 M3 系列现在要针对 macOS 14.8.3 的 ABI。

"追 ABI"是逆向平台特有的一种长期负担。你不是在实现一个稳定接口，而是在实现一个厂商随时会改的接口。每次 macOS 大版本升级，团队都要重新逆向一遍差异，把 Linux 侧的驱动跟上去。报告说 M3 的 DCP 支持已经"几乎达到与 M1/M2 所使用的 13.5 ABI 同等的功能覆盖"，这是相当扎实的一步。

为什么这件事对普通 Linux 用户也有意义

就算你不用 Mac，Asahi 的工作也在往上游回馈：

  • 电源管理适配层里对 PSCI 语义的处理，暴露了标准接口在真实硬件上的边界情况，这些讨论会改进上游的通用代码。
  • 高速外设（USB4/雷电）的驱动工作，很多部分最后会以通用形式进入内核，惠及非苹果的同类控制器。
  • 逆向出来的行为约束（时序、状态机）经常会变成内核里的注释和断言，让后来者少踩坑。

我的做法

看 Asahi 报告这几年，我形成了一个判断硬件逆向项目进展的方法：不看"支持了哪些设备"的列表，看它花了多久从'能认到硬件'走到'能稳定跑外设'。

  • 认到硬件（设备树能匹配、能枚举）通常最快，几周就有。
  • 能读写寄存器、跑通中断，是第二阶段。
  • 让高速外设稳定跑起来，是最难的一段——因为它依赖电源、时钟、固件 ABI 三件事同时对。

Asahi 这期报告的位置，就在第三段的收尾。这类工程没有捷径，只有一层一层把未公开的时序关系试出来。报告的价值也在这里：它把"逆向一块没有文档的 SoC"到底要做什么，写成了可读的记录。