[toc]

drivers/base/syscore.c 系统核心操作(System Core Operations) 管理核心系统组件的休眠与关闭

历史与背景

这项技术是为了解决什么特定问题而诞生的？

drivers/base/syscore.c 文件实现了内核的“系统核心操作”（System Core Operations）框架。这项技术的诞生是为了解决一个非常底层且关键的问题：在系统范围的电源状态转换（如休眠、恢复、关闭）期间，如何以正确的顺序管理那些比普通设备更基础、更核心的系统组件。

常规的设备驱动程序通过其 .suspend 和 .resume 回调函数参与电源管理。然而，系统中存在一些组件，它们：

  1. 不是标准的“设备”：它们可能没有 struct device 实例，因此无法使用标准的设备电源管理（Device PM）框架。
  2. 具有严格的顺序依赖：它们的休眠和唤醒操作必须在所有普通设备之前或之后执行。

最典型的例子就是中断控制器（如ARM GIC）。在系统休眠时，必须在所有使用中断的设备都已经被挂起之后，才能挂起中断控制器本身。反之，在系统唤醒时，必须在任何设备尝试恢复并可能需要中断之前，就先将中断控制器恢复到工作状态。

syscore 框架就是为了给这些核心组件提供一个轻量级的、有严格顺序保证的钩子（hook），让它们能插入到系统电源转换的关键节点。

它的发展经历了哪些重要的里程碑或版本迭代？

syscore 框架的出现不是一个突然的革命，而是内核电源管理子系统精细化演进的结果。随着内核对复杂SoC（片上系统）支持的深入，开发者们意识到仅有设备级的PM回调是不够的。

  • 概念形成：内核社区认识到需要一个独立于设备模型的机制来处理像中断控制器、定时器、sched_clock 等核心子系统的状态。
  • 简单实现：该框架的设计从一开始就非常简洁。它只包含一个全局链表（syscore_ops_list）和一个自旋锁。注册的操作被添加到这个链表中。
  • 集成到核心流程：syscore 的回调被战略性地插入到 drivers/base/power/main.c 的核心休眠/唤醒流程中，确保了其执行顺序的正确性。具体来说，syscore_suspend() 在设备挂起之后、平台进入休眠之前被调用；而 syscore_resume() 在平台被唤醒之后、设备恢复之前被调用。

目前该技术的社区活跃度和主流应用情况如何？

syscore 是一个非常稳定、成熟且基础的内核框架。它不经常变动，因为它的功能非常专一和底层。它被所有支持深度休眠的现代硬件平台（特别是ARM、ARM64、RISC-V等SoC平台）所广泛使用。任何需要编写内核底层架构支持代码或核心驱动（如中断控制器、定时器、CPU Hotplug）的开发者都会直接或间接地与它交互。

核心原理与设计

它的核心工作原理是什么？

syscore 的核心原理极其简单，基于一个全局的回调函数链表。

  1. 定义操作集：内核定义了一个简单的结构体 struct syscore_ops，其中只包含几个函数指针，主要是 .suspend(), .resume(), 和 .shutdown()。
  2. 注册：需要使用此框架的内核子系统（如GIC驱动）会定义一个静态的 syscore_ops 实例，并在其初始化代码中调用 register_syscore_ops()。这个函数只是简单地将该实例添加到一个全局的、受自旋锁保护的链表 syscore_ops_list 中。
  3. 在关键点调用：内核的电源管理核心代码在执行系统级的状态转换时，会在特定的时间点遍历 syscore_ops_list 并调用相应的回调函数。
    • 休眠（Suspend）流程：
      1. 冻结用户进程。
      2. 调用常规设备的 .suspend() 回调（dpm_suspend）。
      3. 调用 syscore_ops 的 .suspend() 回调（syscore_suspend）。
      4. 让平台/CPU进入最终的低功耗状态。
    • 恢复（Resume）流程：
      1. 平台/CPU被唤醒。
      2. 调用 syscore_ops 的 .resume() 回调（syscore_resume）。
      3. 调用常规设备的 .resume() 回调（dpm_resume）。
      4. 解冻用户进程。
    • 关闭（Shutdown）流程：在系统关闭的最后阶段，会调用 .shutdown() 回调。

这个严格的执行顺序（休眠时在设备之后，唤醒时在设备之前）是syscore框架存在的根本价值。

它的主要优势体现在哪些方面？

  • 严格的顺序保证：提供了在常规设备之外的、关键的执行时间窗口。
  • 极其轻量：实现非常简单，只有一个链表和一个锁，开销极小。
  • 独立于设备模型：它不依赖于 struct device，使得任何内核子系统都可以注册回调，即使它不代表一个物理设备。
  • 集中管理：将所有核心系统组件的电源管理钩子集中在一个地方，使得核心流程清晰可控。

它存在哪些已知的劣势、局限性或在特定场景下的不适用性？

  • 强大的破坏力：syscore 回调运行在系统状态转换的关键路径上。任何在回调函数中的错误、死锁或过长的延迟都可能导致整个系统休眠/唤醒失败。因此，它是一个专家级的工具。
  • 功能单一：它只提供 suspend, resume, shutdown 三个钩子，不支持更复杂的电源管理特性，如运行时电源管理（Runtime PM）或异步操作。
  • 同步执行：所有的 syscore 回调都是同步地、依次执行的，这可能会略微增加休眠/唤醒的延迟。

使用场景

在哪些具体的业务或技术场景下，它是首选解决方案？请举例说明。

syscore 是为那些对电源状态转换顺序有严格要求，且不适合或不能作为常规设备管理的底层核心系统组件提供的唯一且首选的解决方案。

  • 场景一：中断控制器驱动（如ARM GIC）
    这是最经典的用例。GIC驱动会注册一个 syscore_ops。其 .suspend 函数会保存GIC的分发器和CPU接口的状态，这必须在所有设备停止产生中断后进行。其 .resume 函数会恢复这些状态，这必须在任何设备驱动的.resume函数可能需要重新请求中断之前完成。
  • 场景二：内核调度器时钟（sched_clock）
    sched_clock 依赖于一个稳定的硬件计数器。在系统休眠前，syscore 的 suspend 回调需要保存这个计数器的状态；在恢复后，resume 回调需要恢复它，以保证系统时间戳的连续性。
  • 场景三：CPU热插拔与SMP管理
    CPU的上线/离线过程与系统休眠/唤醒有相似之处。syscore 框架也被用于在这些过程中保存和恢复per-CPU的核心状态。

是否有不推荐使用该技术的场景？为什么？

  • 任何常规设备驱动：例如I2C传感器、SPI闪存、USB设备、PCIe网卡等。这些设备必须使用标准的设备电源管理框架（dev_pm_ops）。如果一个常规设备驱动错误地使用了 syscore，它会打破内核精心设计的PM顺序，导致未定义的行为，例如在中断控制器已经关闭后还尝试使用中断。

对比分析

请将其 与 其他相似技术 进行详细对比。

syscore 框架最直接的对比对象就是标准的设备电源管理（Device PM）回调机制。

特性 syscore_ops (系统核心操作) dev_pm_ops (标准设备PM操作)
管理对象 核心系统组件。通常不关联struct device，如中断控制器、核心定时器。 标准设备。必须关联一个struct device实例。
注册方式 通过register_syscore_ops()注册到一个全局链表。 定义在struct device_driver中，与驱动绑定，其实例附加在dev->driver->pm。
休眠执行顺序 晚（Late）。在所有常规设备都suspend之后执行。 早（Early）。在syscore操作之前执行。
恢复执行顺序 早（Early）。在所有常规设备resume之前执行。 晚（Late）。在syscore操作之后执行。
功能复杂度 极简。只提供suspend, resume, shutdown。 丰富。支持系统休眠、运行时PM、异步操作、唤醒源管理等。
适用场景 底层、架构相关的代码，对执行顺序有最严格的要求。 所有通用的设备驱动程序。
举例 ARM GIC中断控制器、sched_clock。 I2C传感器驱动、USB网卡驱动、PCIe显卡驱动。

syscore_shutdown: 执行核心系统设备的关闭回调

此函数是系统关机流程中一个非常靠后的阶段, 在device_shutdown之后被kernel_power_off调用。它的核心原理是为那些最基础、最核心的系统硬件(System Core Hardware)提供一个最后的、有序的关闭机会。这些”核心硬件”通常是指那些必须维持运行直到系统最后一刻的设备, 例如中断控制器(ARM NVIC)、系统定时器(SysTick)、DMA控制器等, 它们是整个系统运行的基础, 不能在常规的device_shutdown阶段被关闭。

这个函数的设计简单而关键, 其核心逻辑在于:

  1. 反向顺序遍历: 函数通过list_for_each_entry_reverse宏, 反向遍历一个全局的syscore_ops_list链表。内核中的核心硬件驱动在初始化时, 会按照依赖顺序将自己的操作集(syscore_ops)注册到这个链表中。因此, 在关机时以注册的相反顺序来执行它们的shutdown回调, 就自然地保证了依赖关系的正确性。例如, 内核会确保在关闭中断控制器之前, 先关闭所有依赖于中断的设备。
  2. 互斥访问: 整个遍历和调用过程都被一个互斥锁syscore_ops_lock保护。在STM32H750这样的单核抢占式系统上, 这个锁能够防止在遍历链表并调用回调的中间过程, 被另一个任务抢占, 从而保证了整个关闭序列的原子性和完整性。
  3. 选择性调用: 它会检查每个操作集ops中是否真的提供了一个非空的shutdown函数指针, 只有在指针有效时才会执行调用。这增加了框架的灵活性和健壮性。

当device_shutdown已经关闭了所有”普通”设备(如SPI、I2C、网络设备)之后, syscore_shutdown就开始接手, 对系统进行最后的”硬件清理”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
/**
 * syscore_shutdown - 执行所有已注册的核心系统关闭回调.
 */
void syscore_shutdown(void)
{
	/* 定义一个指向 syscore_ops 结构体的指针 ops, 用于遍历. */
	struct syscore_ops *ops;

	/*
	 * 获取一个互斥锁, 用于保护全局的 syscore_ops_list 链表,
	 * 防止在遍历过程中发生并发修改.
	 */
	mutex_lock(&syscore_ops_lock);

	/*
	 * 使用 list_for_each_entry_reverse 宏反向遍历 syscore_ops_list 链表.
	 * "反向"是关键, 它确保了关闭操作是以注册操作的相反顺序执行的,
	 * 从而正确地处理了核心设备之间的依赖关系.
	 */
	list_for_each_entry_reverse(ops, &syscore_ops_list, node)
		/* 检查当前操作集 ops 是否提供了一个有效的 shutdown 回调函数. */
		if (ops->shutdown) {
			/* 如果内核开启了 initcall_debug, 则打印一条调试信息, 显示将要调用的函数. */
			if (initcall_debug)
				pr_info("PM: Calling %pS\n", ops->shutdown);
			/* 调用驱动提供的 shutdown 回调函数, 执行硬件相关的最后清理工作. */
			ops->shutdown();
		}

	/*
	 * 所有回调都已执行完毕, 释放互斥锁.
	 */
	mutex_unlock(&syscore_ops_lock);
}

内核回调注册：构建系统核心操作的执行链表

本代码片段是syscore_ops框架的“登记处”。它的核心功能是提供一个全局的、线程安全的函数register_syscore_ops，允许内核中不同的核心子系统（例如我们上一节分析的“通用中断芯片”管理代码）将它们自己的电源管理操作集（struct syscore_ops）注册到一个中央链表中。

您可以将这个机制想象成一个大楼的消防应急预案登记中心：

  • syscore_ops_list: 这是挂在消防中心墙上的一块主白板，上面将列出所有部门的应急联系人及其职责。
  • syscore_ops_lock: 这是消防中心的门锁。为了防止混乱，规定一次只能有一个部门经理进来登记，他必须先锁上门。
  • register_syscore_ops: 这就是登记流程。当电力部门（一个核心子系统）的经理（init函数）需要登记他的应急操作时，他会：
    1. 带着写有“关总闸”、“恢复供电”等操作的表格（struct syscore_ops）来到消防中心。
    2. 锁上门 (mutex_lock)。
    3. 把他的表格挂在主白板的末尾 (list_add_tail)。
    4. 打开门锁，离开 (mutex_unlock)。

之后，当火警真的拉响时（系统关机或挂起），消防总指挥（内核电源管理核心）就会来到这块白板前，按照上面挂着的表格顺序，逐一通知每个部门执行他们的应急操作。

实现原理分析

这段代码的实现非常经典，体现了内核编程的基础要素：

  1. 全局数据结构:

    • static LIST_HEAD(syscore_ops_list);: LIST_HEAD是一个宏，它在编译时静态地声明并初始化一个名为syscore_ops_list的双向循环链表头。这个链表头本身不包含数据，它只是一个“锚点”，所有注册的syscore_ops结构体都将通过它们的node成员链接到这个锚点上。static关键字意味着这个链表头是本文件私有的，外部无法直接访问它。
    • static DEFINE_MUTEX(syscore_ops_lock);: DEFINE_MUTEX宏同样在编译时静态地声明并初始化一个名为syscore_ops_lock的互斥锁（mutex）。这个锁的唯一职责就是保护syscore_ops_list链表，防止对它的并发访问导致链表损坏。

  2. 注册函数 (register_syscore_ops):

    • 线程安全: 函数的第一步和最后一步分别是加锁和解锁。mutex_lock(&syscore_ops_lock);确保了在任何时刻，只有一个CPU核心或任务能够执行链表添加操作。这至关重要，因为在多核系统的启动过程中，不同的子系统初始化函数可能会并行执行，如果没有锁，它们同时修改链表指针就会导致数据竞争和系统崩溃。
    • 链表操作: list_add_tail(&ops->node, &syscore_ops_list);是核心操作。list_add_tail是内核链表API的一部分，它将ops->node（ops是调用者传入的结构体，node是它内部的struct list_head成员）添加到syscore_ops_list链表的尾部。添加到尾部可以保持注册的顺序性，这在电源管理中通常很重要（恢复resume操作的顺序往往与挂起suspend的顺序相反）。
    • 符号导出: EXPORT_SYMBOL_GPL(register_syscore_ops);是一个非常重要的声明。它将register_syscore_ops这个函数名和地址导出到内核的符号表中。这使得**可加载内核模块（.ko文件）**也能够调用这个函数。如果没有这个声明，那么只有静态编译进内核主体的代码才能注册syscore_ops。GPL后缀意味着，只有遵循GPL兼容许可证的模块才能使用此函数，这是内核许可证策略的一部分。

代码分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// 声明一个静态的链表头，作为所有syscore_ops注册的锚点。
// LIST_HEAD宏会创建一个名为syscore_ops_list的`struct list_head`变量，并初始化它的next和prev指针都指向自己，表示这是一个空链表。
static LIST_HEAD(syscore_ops_list);

// 声明并静态定义一个互斥锁。
// DEFINE_MUTEX宏会创建一个名为syscore_ops_lock的`struct mutex`变量，并完成所有必要的初始化。
static DEFINE_MUTEX(syscore_ops_lock);

/**
 * register_syscore_ops - 注册一个系统核心操作集。
 * @ops: 要注册的系统核心操作结构体。
 */
void register_syscore_ops(struct syscore_ops *ops)
{
	// 获取互斥锁。如果锁已被其他任务持有，当前任务将在此处睡眠等待，直到锁被释放。
	// 这是保证链表操作线程安全的关键。
	mutex_lock(&syscore_ops_lock);

	// 将调用者传入的ops结构体中的node成员，添加到全局syscore_ops_list链表的尾部。
	list_add_tail(&ops->node, &syscore_ops_list);

	// 释放互斥锁，允许其他任务进入此函数。
	mutex_unlock(&syscore_ops_lock);
}

// 将register_syscore_ops函数导出，使其对GPL兼容的可加载内核模块可见。
EXPORT_SYMBOL_GPL(register_syscore_ops);