Linux reset 框架深度解析：功耗管理中的复位控制与驱动实践

1. 功耗子系统里的 reset 框架到底在管什么搞 Linux 功耗管理这块的人迟早会撞上 reset 子系统。不是因为它多复杂而是因为它太容易被忽略——大部分驱动工程师第一次接触 reset 框架都是在调试某个外设死活不工作的时候翻遍时钟、电源、引脚配置都没问题最后发现是 reset 线没释放。这种坑踩过一次就忘不了。reset 通用框架reset controller framework是 Linux 内核提供的一套标准化接口用来管理 SoC 内部各个外设的复位信号。它解决的核心问题是在一个 SoC 里几十甚至上百个外设模块各自有独立的复位线这些复位线可能挂在不同的寄存器上有的在 CRUClock Reset Unit有的在 PRCMPower Reset Clock Management有的散落在各个 IP 自己的寄存器空间里。如果没有统一框架每个驱动都要自己写寄存器操作代码重复不说时序还容易出错。这套框架适合谁看做嵌入式 Linux BSP 开发的、写外设驱动的、调试功耗问题的以及那些面试时被问到Linux 里怎么控制外设复位的候选人。它不属于那种天天用的东西但一旦涉及外设初始化、低功耗唤醒、系统恢复这些场景reset 框架就是绕不过去的基础设施。我个人的经验是reset 框架在功耗子系统里的角色类似于一个开关管理员。功耗管理关心的是什么时候关掉某个模块的时钟、切断它的电源但关之前你得先让它进入复位状态否则残留状态可能导致漏电或者唤醒异常。reset 框架就是干这个的——它不直接省电但它保证了省电操作的安全性和可恢复性。2. reset 框架的整体设计与核心数据结构2.1 为什么需要通用框架而不是各管各的早期内核里外设复位就是直接操作寄存器。比如某个网卡驱动要复位自己就在 probe 函数里写writel(0x1, base RESET_REG)然后延时再writel(0x0, base RESET_REG)。这种做法在单平台时代没问题但到了多平台、多驱动复用的阶段问题就暴露了。第一个问题是寄存器地址不统一。同一个外设 IP 在不同 SoC 上复位寄存器可能挂在完全不同的位置。驱动代码里硬编码地址移植性极差。第二个问题是复位线共享。有些外设共用一条复位线A 驱动复位时把 B 也复位了B 驱动完全不知情。第三个问题是时序要求不同。有的外设要求复位保持至少 1ms有的要求 10us驱动各自实现容易遗漏。reset 框架的设计思路很直接把复位控制器抽象成一个 provider把需要复位的外设抽象成 consumer中间通过 device tree 或者硬件描述建立映射关系。Provider 负责实现具体的复位操作consumer 只管调用reset_control_assert()和reset_control_deassert()不关心底层怎么实现。这种 provider/consumer 模型在内核里很常见clk 框架、regulator 框架、gpio 框架都是类似思路。reset 框架的特殊之处在于它的操作语义非常明确——assert 就是拉低复位进入复位状态deassert 就是释放复位退出复位状态。没有中间态没有渐变就是二值操作。2.2 核心数据结构拆解理解 reset 框架关键要搞清楚三个结构体reset_controller_dev、reset_control、reset_ops。reset_controller_dev代表一个复位控制器实例。它包含一个reset_ops指针、一个of_xlate回调、复位线数量nr_resets以及一个reset_control_head链表头用来挂载所有属于这个控制器的 consumer 句柄。在 device tree 里每个提供复位功能的节点都会对应一个reset_controller_dev。reset_control是 consumer 拿到的句柄。它里面有一个rcdev指针指回控制器一个id表示这是第几号复位线还有acquired、shared等标志位。驱动调用reset_control_get()时框架会根据 device tree 里的resets属性找到对应的控制器和线号分配一个reset_control结构返回。reset_ops是控制器驱动需要实现的回调集合。核心就两个assert和deassert。可选的有resetassert 后延时再 deassert、status查询当前复位状态。有些控制器还实现reset_control_reset()对应的reset回调用于执行一次完整的复位脉冲。struct reset_control_ops { int (*reset)(struct reset_controller_dev *rcdev, unsigned long id); int (*assert)(struct reset_controller_dev *rcdev, unsigned long id); int (*deassert)(struct reset_controller_dev *rcdev, unsigned long id); int (*status)(struct reset_controller_dev *rcdev, unsigned long id); };这个结构体设计得很克制没有搞一堆花哨的回调。因为复位操作本质上就是拉高拉低不需要复杂的参数。id参数用来区分同一个控制器下的不同复位线具体怎么映射到寄存器位由控制器驱动自己决定。2.3 device tree 里的 reset 描述方式在 device tree 里consumer 通过resets属性引用控制器uart0: serial10000000 { compatible vendor,uart; reg 0x10000000 0x1000; resets cru RESET_UART0; reset-names uart0_rst; };resets属性是一个 phandle 加参数的列表。phandle 指向控制器节点后面的参数由控制器的of_xlate回调解析。大多数控制器只用一个参数表示线号但有些复杂控制器可能需要两个参数比如一个表示寄存器组一个表示位偏移。reset-names是可选的用来给复位线起名字。如果驱动里用reset_control_get(dev, uart0_rst)获取句柄就需要这个名字。如果只用reset_control_get(dev, NULL)获取第一条复位线名字可以省略。这里有个容易踩的坑resets属性里的线号宏定义通常放在include/dt-bindings/reset/目录下。如果你自己写控制器驱动记得也要提供对应的头文件否则 device tree 编译会报错。我见过有人直接把数字写进去短期能跑但后期维护就是灾难。3. 控制器驱动的实现要点与实操细节3.1 注册一个 reset controller 的完整流程写一个 reset controller 驱动核心步骤就四步定义reset_controller_dev、实现reset_ops、填充of_xlate、调用注册函数。先看一个最简实现struct my_reset_priv { struct reset_controller_dev rcdev; void __iomem *base; struct spinlock lock; }; static int my_reset_assert(struct reset_controller_dev *rcdev, unsigned long id) { struct my_reset_priv *priv container_of(rcdev, struct my_reset_priv, rcdev); unsigned long flags; u32 val; spin_lock_irqsave(priv-lock, flags); val readl(priv-base RESET_REG); val | BIT(id); writel(val, priv-base RESET_REG); spin_unlock_irqrestore(priv-lock, flags); return 0; } static int my_reset_deassert(struct reset_controller_dev *rcdev, unsigned long id) { struct my_reset_priv *priv container_of(rcdev, struct my_reset_priv, rcdev); unsigned long flags; u32 val; spin_lock_irqsave(priv-lock, flags); val readl(priv-base RESET_REG); val ~BIT(id); writel(val, priv-base RESET_REG); spin_unlock_irqrestore(priv-lock, flags); return 0; } static const struct reset_control_ops my_reset_ops { .assert my_reset_assert, .deassert my_reset_deassert, }; static int my_reset_xlate(struct reset_controller_dev *rcdev, const struct of_phandle_args *reset_spec) { unsigned long id reset_spec-args[0]; if (id rcdev-nr_resets) return -EINVAL; return id; } static int my_reset_probe(struct platform_device *pdev) { struct my_reset_priv *priv; struct resource *res; priv devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; res platform_get_resource(pdev, IORESOURCE_MEM, 0); priv-base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(priv-base)) return PTR_ERR(priv-base); spin_lock_init(priv-lock); priv-rcdev.ops my_reset_ops; priv-rcdev.owner THIS_MODULE; priv-rcdev.nr_resets 32; priv-rcdev.of_node pdev-dev.of_node; priv-rcdev.of_xlate my_reset_xlate; priv-rcdev.of_reset_n_cells 1; return devm_reset_controller_register(pdev-dev, priv-rcdev); }这段代码看起来简单但有几个细节值得展开说。of_reset_n_cells必须和 device tree 里resets属性的参数个数一致。如果设成 1但 dts 里写了两个参数of_xlate拿到的args_count会对不上直接报错。反过来也一样。我调试过一个案例控制器驱动里设了of_reset_n_cells 1但 dts 里习惯性写了cru RESET_UART0 0多了一个 0结果 probe 一直返回-EINVAL查了半天才发现是参数个数不匹配。devm_reset_controller_register是带资源管理的注册函数它会自动处理注销。如果你的驱动不支持 device tree可以用reset_controller_register但需要自己管理生命周期。现在新写的驱动基本都用 devm 版本。3.2 assert 和 deassert 的时序陷阱复位操作不是简单的寄存器写 0 写 1。很多外设对复位脉冲宽度有要求比如复位信号至少保持 10 个时钟周期。如果控制器驱动只是立刻拉高又立刻拉低外设可能根本没复位成功。正确的做法是在assert和deassert之间加延时。但延时加在哪里有讲究。如果加在assert回调里那每次 assert 都会延时即使后面不 deassert 也延时浪费。如果加在deassert里又不符合语义——deassert 只是释放复位不应该承担延时的责任。内核提供的方案是reset_control_reset()它对应控制器的reset回调。这个回调的语义是执行一次完整的复位脉冲控制器驱动可以在这里实现 assert、延时、deassert 的完整序列。consumer 调用reset_control_reset()时框架会优先调用控制器的reset回调如果控制器没实现框架会退化成先 assert 再 deassert但不会自动加延时。static int my_reset_reset(struct reset_controller_dev *rcdev, unsigned long id) { my_reset_assert(rcdev, id); udelay(10); my_reset_deassert(rcdev, id); return 0; }这里用udelay还是msleep取决于复位保持时间。如果要求 1ms 以上用msleep更合适避免忙等。但注意msleep不能在原子上下文调用如果控制器驱动可能在中断里被调用就得用udelay或者usleep_range。还有一个坑有些外设要求复位释放后等待一段时间才能访问寄存器。这个延时不应该由 reset 控制器负责而是 consumer 驱动自己在reset_control_deassert()之后加。因为不同外设的等待时间不同控制器不可能知道每个外设的需求。3.3 共享复位线的处理策略共享复位线是个麻烦事。假设 UART0 和 UART1 共用一条复位线UART0 驱动先 probe调用reset_control_deassert()释放复位。然后 UART1 驱动 probe也调用reset_control_deassert()。如果控制器驱动只是简单写寄存器第二次 deassert 会把复位线又拉低一次导致 UART0 意外复位。内核的解决方案是引用计数。reset_control结构里有deassert_count字段每次 deassert 递增assert 递减。只有计数从 0 变 1 时才真正操作硬件从 1 变 0 时才真正拉低复位。这样多个 consumer 共享一条复位线时只要还有一个 consumer 需要它复位就不会被拉低。但引用计数只对同一个reset_control句柄有效。如果两个驱动各自调用reset_control_get()获取句柄框架会返回两个不同的reset_control结构引用计数不共享。这时候就需要用reset_control_get_shared()它返回的句柄会标记shared标志框架内部会维护一个共享列表确保同一条复位线只有一个共享句柄。rst devm_reset_control_get_shared(pdev-dev, shared_rst); if (IS_ERR(rst)) return PTR_ERR(rst); reset_control_deassert(rst);用 shared 句柄时要注意reset_control_assert()在共享模式下可能不会立即生效因为还有其他 consumer 在用。框架会等所有共享者都调用 assert 后才真正拉低。这个行为在调试时容易让人困惑——明明调了 assert怎么复位线还是高的查一下deassert_count就明白了。4. consumer 侧的使用方法与功耗场景结合4.1 驱动里怎么正确获取和释放 reset 句柄consumer 驱动使用 reset 框架标准流程是probe 里获取句柄初始化时 deassert 释放复位suspend 时 assert 进入复位resume 时 deassert 退出复位remove 时释放句柄。struct my_dev { struct reset_control *rst; struct clk *clk; }; static int my_probe(struct platform_device *pdev) { struct my_dev *dev; int ret; dev devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-rst devm_reset_control_get_exclusive(pdev-dev, NULL); if (IS_ERR(dev-rst)) return PTR_ERR(dev-rst); dev-clk devm_clk_get(pdev-dev, NULL); if (IS_ERR(dev-clk)) return PTR_ERR(dev-clk); ret clk_prepare_enable(dev-clk); if (ret) return ret; reset_control_deassert(dev-rst); /* 等待外设稳定 */ usleep_range(100, 200); /* 继续初始化 */ ... return 0; }这里有个顺序问题先开时钟还是先释放复位大多数外设要求先有时钟再释放复位因为复位释放后外设需要时钟来同步内部状态。如果先释放复位再开时钟外设可能处于不确定状态。所以标准顺序是clk_prepare_enable-reset_control_deassert- 延时 - 访问寄存器。devm_reset_control_get_exclusive和devm_reset_control_get_shared的区别前面说过了。还有一个devm_reset_control_get_optional它在句柄不存在时返回 NULL 而不是错误适合那些复位线可选的驱动。用 optional 版本时后续调用reset_control_deassert(NULL)是安全的框架会直接返回 0。4.2 suspend/resume 中的 reset 操作在功耗管理场景里reset 框架的使用要更谨慎。suspend 时 assert 复位resume 时 deassert 复位看起来很简单但实际要考虑几个问题。第一有些外设的唤醒能力依赖复位状态。如果 suspend 时 assert 了复位外设可能无法产生唤醒事件。这种情况下就不能在 suspend 里 assert只能关时钟。第二resume 时 deassert 之后外设的所有寄存器都回到默认值驱动需要重新初始化。如果驱动在 resume 回调里只做了 deassert 而没有重新配置寄存器外设可能工作不正常。我见过一个案例网卡驱动在 resume 时 deassert 了复位但没有重新写 MAC 地址寄存器结果唤醒后网卡地址变成全 0。第三suspend/resume 的调用顺序和 probe 不同。在 system suspend 流程里suspend_noirq阶段会关闭时钟resume_noirq阶段会重新开时钟。reset 操作通常放在suspend和resume阶段而不是 noirq 阶段因为 reset 控制器可能依赖时钟或电源。static int my_suspend(struct device *dev) { struct my_dev *d dev_get_drvdata(dev); reset_control_assert(d-rst); clk_disable_unprepare(d-clk); return 0; } static int my_resume(struct device *dev) { struct my_dev *d dev_get_drvdata(dev); int ret; ret clk_prepare_enable(d-clk); if (ret) return ret; reset_control_deassert(d-rst); usleep_range(100, 200); /* 重新初始化外设寄存器 */ my_hw_init(d); return 0; }4.3 reset 与 runtime PM 的配合Runtime PM 场景下reset 操作更频繁。每次 runtime resume 都可能需要 deassertruntime suspend 都可能需要 assert。但频繁的 assert/deassert 会带来性能开销因为每次复位后外设都要重新初始化。一个常见的优化策略是runtime suspend 时只关时钟不 assert 复位。因为关时钟已经能省电复位带来的额外省电有限但重新初始化的代价很高。只有在 system suspend 或者外设确实需要完全断电时才 assert 复位。这个策略不是绝对的取决于具体外设。有些外设即使关了时钟也有漏电必须 assert 复位才能把漏电降到最低。这时候就要权衡省电和性能。我的经验是对于高速外设如 USB、PCIeruntime suspend 不 assert对于低速外设如 I2C、SPI可以 assert因为重新初始化成本低。5. 调试 reset 问题的常用手段与排查思路5.1 从 sysfs 和 debugfs 看复位状态内核提供了/sys/kernel/debug/reset目录需要 CONFIG_RESET_CONTROLLER 和 debugfs里面可以看到所有注册的 reset controller 和它们的复位线状态。不过这个接口不是所有内核版本都有具体取决于配置。更通用的方法是看/sys/kernel/debug/clk/clk_summary和/sys/kernel/debug/pm_genpd/pm_genpd_summary结合复位状态一起分析。如果某个外设不工作先确认它的时钟有没有开电源域有没有上电最后再看复位有没有释放。有些 SoC 厂商会在自己的 debugfs 里提供复位寄存器 dump比如/sys/kernel/debug/regmap/下面可以看寄存器值。如果控制器驱动用了 regmap可以直接读寄存器确认复位位的状态。5.2 常见问题速查表现象可能原因排查方法probe 返回 -EPROBE_DEFER控制器还没注册检查控制器驱动是否编译进内核probe 顺序是否靠后reset_control_deassert 返回 -EINVAL线号越界或参数不匹配检查 dts 里 resets 参数个数和 of_reset_n_cells 是否一致外设复位后不工作复位释放后未重新初始化在 deassert 后加延时重新配置寄存器共享复位线冲突未使用 shared 句柄改用 devm_reset_control_get_sharedsuspend 后无法唤醒suspend 时 assert 了复位检查唤醒源是否依赖复位状态复位操作无效果控制器驱动 assert/deassert 写反读寄存器确认位操作是否正确5.3 一个真实的调试案例之前调试一个 SPI 控制器现象是 probe 成功但第一次传输就超时。查了时钟、引脚、DMA 都没问题。最后用逻辑分析仪抓 SPI 波形发现 CLK 线上完全没有信号。回头查代码发现 SPI 驱动在 probe 里调用了reset_control_deassert但控制器驱动的deassert回调里写的是val | BIT(id)而assert里写的是val ~BIT(id)。也就是说deassert 实际上把复位线拉高了assert 反而拉低了。两个操作写反了。这个 bug 之所以难查是因为它不会导致 probe 失败寄存器读写也正常只是外设不工作。逻辑分析仪抓不到波形才暴露出来。后来我养成了一个习惯写 reset 控制器驱动时先确认复位寄存器的极性——是写 1 复位还是写 0 复位。很多 SoC 的复位寄存器是低有效但也有一些是高有效不能想当然。6. 从功耗子系统视角看 reset 框架的扩展与演进6.1 reset 与 power domain 的联动在现代 SoC 里reset 和 power domain 经常是联动的。一个 power domain 下电时里面的外设会自动进入复位状态上电时复位状态需要显式释放。这种联动关系在 device tree 里通过power-domains属性描述但 reset 框架本身不处理这个逻辑需要 consumer 驱动自己协调。典型的做法是在 runtime resume 时先确保 power domain 上电再 deassert 复位在 runtime suspend 时先 assert 复位再让 power domain 下电。顺序反了可能导致外设处于不确定状态。有些 SoC 提供了复位保持功能即 power domain 下电时自动 assert 复位上电时自动 deassert。这种情况下驱动不需要手动操作 reset但需要在 dts 里正确配置。具体怎么配要看 SoC 的 TRM 和内核文档。6.2 reset 框架的未来方向reset 框架本身已经比较稳定不太会有大的架构变化。但有两个方向值得关注。一是reset 与 clock 的进一步整合。有些 SoC 的复位和时钟是同一个寄存器控制比如 CRU 里一个寄存器同时有时钟门控位和复位位。目前 reset 框架和 clk 框架是分开的驱动需要分别获取 reset 和 clk 句柄。未来可能会有更紧密的整合减少驱动侧的重复代码。二是reset 状态的细粒度控制。目前 reset 框架只支持 assert/deassert 二值操作但有些外设需要部分复位比如只复位数据通路不复位配置寄存器。这种需求目前只能通过控制器驱动自己实现多个复位线来模拟未来可能会有更灵活的接口。不过这些都是锦上添花核心的 provider/consumer 模型和 assert/deassert 语义不会变。对于大多数驱动开发者来说掌握现有的 reset 框架用法就足够了。6.3 面试中常见的 reset 框架问题如果你在准备嵌入式 Linux 面试reset 框架相关的问题通常不会单独问而是夹杂在驱动模型、设备树、功耗管理这些话题里。常见的有Linux 里怎么控制外设复位——答 reset 框架provider/consumer 模型assert/deassert 语义。reset 和 clock 的操作顺序是什么——先开时钟再释放复位复位释放后加延时再访问寄存器。共享复位线怎么处理——引用计数shared 句柄deassert_count 机制。reset 控制器驱动怎么写——实现 reset_ops填充 reset_controller_dev调用 devm_reset_controller_register。这些问题看起来简单但能答清楚细节的人不多。我面试过不少人能说出 assert/deassert 的很多但能说清楚 of_xlate 和 of_reset_n_cells 关系的很少。如果你能把前面几节的细节讲明白面试官基本会认可你对内核框架的理解深度。最后分享一个我自己的习惯每次写新的 reset 控制器驱动我都会先写一个最小的测试模块在 probe 里 assert 然后 deassert用示波器或者逻辑分析仪确认复位线的电平变化。确认硬件操作正确后再写完整的驱动逻辑。这个习惯帮我省了很多调试时间因为复位线的问题一旦混在复杂驱动里排查成本会高很多。