企业官网建设流程全解析

做Linux电源管理或者嵌入式低功耗调优的同学，大概率都撞过这几类问题：系统写mem之后一睡就醒，醒过来按什么都没反应，或者电量在待机时哗哗往下掉。我排查这类问题到最后，十有八九都会落到同一个点——Linux内核的中断唤醒链路。这篇内容基于内核suspend/resume的真实流程，把中断如何变成唤醒源、内核在什么时机处理唤醒事件、驱动侧要做什么配置一次讲清楚，同时给出一套可以直接上手的排查路径。我会尽量不写厂商私有代码，用通用设备模型和一块虚拟平台举例，你看完能直接迁移到自己手头的板上。

1. 中断唤醒的整套设计思路：硬件、内核、驱动各自负责什么

1.1 CPU睡眠后，中断线是怎么把系统重新拉起来的

先解决一个最基础的问题：CPU都睡死了，中断线凭什么还能把它拉起来？

现代CPU进入深度睡眠时，核心时钟会被关掉，流水线停止取指，ARM上执行WFI/WFE，x86上执行HLT。此时CPU本身对中断“没有反应能力”。但整个系统里还有一部分电路是保持供电的，也就是常说的always-on域。中断控制器、唤醒控制器、部分GPIO模块、RTC模块，只要设计得当，都在这个域里。

唤醒的完整链路大致是这样的：外部事件（按键按下、RTC闹钟到点）先在板级改变某条GPIO或专用信号线的电平/产生边沿，中断控制器捕获到这个变化，再检查这条IRQ是否被允许唤醒——注意这里的“允许”不是普通的中断使能，而是专门针对低功耗唤醒的配置——随后它向电源管理单元发出唤醒请求，电源管理单元逐级恢复主域供电、稳定时钟，CPU从WFI指令的下一条继续执行，进入异常向量开始处理中断。

这里有个非常关键的认识：深度睡眠阶段，普通中断根本送达不了CPU。普通中断最多只能以pending状态躺在中断控制器里，等系统被别的源唤醒之后再处理。只有被明确标记为唤醒源的IRQ，才能在CPU睡死时把它拽起来。这解释了为什么很多驱动明明request_irq了、中断处理函数写得天衣无缝，系统还是唤不醒——没做唤醒配置，等于白写。

另外要区分idle和suspend。CPU idle时本地中断还是可响应的，只是核心在偷懒；suspend时整个系统进入更高层次的睡眠，中断世界里只剩唤醒源一条通道。这个区别一开始就想清楚，后面排查方向才不会跑偏。

1.2 三层分工：中断控制器、内核IRQ核心、设备驱动的职责边界

我把整套唤醒机制按职责拆成三层：硬件层、内核IRQ核心层、驱动层。

硬件层的核心是irq_chip的irq_set_wake回调。每个中断控制器芯片驱动都得实现这个回调，作用就是把自己寄存器里对应的唤醒使能位配好。如果某个中断控制器根本不支持唤醒，那么enable_irq_wake返回-ENXIO。更要命的是电源域问题：有的SoC里GPIO控制器分两组，一组挂在always-on域里，睡眠不掉电，另一组跟着主域掉电。想用掉电那组的GPIO做唤醒，硬件上就不可能成立，软件怎么配都是白费。这种问题查到最后往往是硬件设计或引脚选型错误，中层和驱动层代码看起来完全正常。

内核IRQ核心层维护每个IRQ的irq_desc结构，记录IRQD_WAKEUP_SET这类标志位，维护一份“唤醒IRQ列表”。suspend流程走到suspend_device_irqs这一步时，它把非唤醒IRQ全部disable，唤醒IRQ保留不被mask；resume时再统一恢复。它同时负责wakeup_source的注册和事件计数，是全局状态的管理者。

驱动层则负责判断自己这个设备具不具备唤醒能力，具备就调用device_init_wakeup、enable_irq_wake或者dev_pm_set_wake_irq，还要在suspend回调里保存IO状态、在resume回调里恢复现场。

这三层为什么要分开？很简单，如果每个驱动都直接去操作中断控制器的寄存器，那内核全局的中断状态就乱了。让驱动只面向“我这个设备能不能唤醒”这个简单问题，把复杂的控制器配置留给IRQ核心和芯片驱动，这是Linux一贯的分层思路。调试的时候你也按这个顺序查：先查硬件层支不支持，再查IRQ核心有没有把这条IRQ归入唤醒列表，最后查驱动有没有正确注册。

1.3 睡眠与唤醒状态机：为什么“关中断”要放在最后一步

内核的标准suspend流程可以简化成下面这条线：

1. 冻结用户态进程和部分内核任务，保证没有进程再来碰设备；
2. dpm_suspend阶段，设备驱动把外设切到低功耗模式；
3. dpm_suspend_noirq阶段，驱动做最后整理，比如保存关键寄存器；
4. suspend_device_irqs，把非唤醒IRQ全部关掉，只留唤醒源；
5. syscore_suspend，关闭时间keeping等核心子系统；
6. CPU执行WFI/WFE/HLT进入睡眠。

resume则是完全反过来：唤醒IRQ先把CPU拉起来，然后syscore_resume恢复核心子系统，resume_device_irqs把普通中断统统打开，再做dpm_resume_noirq和普通resume，最后thaw_processes让进程恢复运行。

很多人不理解为什么关中断要放在第4步而不是一开始就关。原因有两个。第一，驱动在dpm_suspend阶段还需要等I/O完成中断，如果一开始就把中断关了，驱动在等待完成信号时会活活卡死或超时。第二，中断也不能拖到syscore之后才关，因为设备切换低功耗模式的过程中，中断乱入可能让软硬件状态不一致。所以内核把“关中断”压在设备全部suspend完、进入核心子系统之前，这是最稳妥的时机。resume方向同理，先把中断打开，让驱动能正常收发事件，再恢复设备和进程。

这套顺序在排查时特别有用。你只要看日志停在哪一步，就知道问题出在设备驱动、IRQ核心还是平台代码。

2. 核心机制拆解：wakeup_source、enable_irq_wake与竞态防护

2.1 wakeup_source：系统里那本“谁在唤醒/谁阻止睡眠”的账本

wakeup_source是Linux PM子系统里的一个核心数据结构，说它是一本账本非常贴切。每个可能唤醒系统、或者会产生影响睡眠事件的实体，都要在PM子系统里挂一个wakeup_source，然后通过几条简单的API记账。

驱动的典型用法是这样：

struct wakeup_source *ws; ws = wakeup_source_register(NULL, "my-device-wakeup"); if (!ws) return -ENOMEM; /* 事件到来时通知PM子系统 */ pm_wakeup_event(ws, 100); /* 100ms后自动relax */ /* 或者手动控制active状态 */ __pm_stay_awake(ws); /* 处理完事件 */ __pm_relax(ws);

pm_wakeup_event的意思是“我刚来了一件事，系统最近100ms内别睡或者说明唤醒原因”。内核PM核心用这些调用更新event_count、wakeup_count等统计量，还会在suspend入口检查 pm_wakeup_pending，如果刚才有事件还没来得及消化，就会让本次suspend失败返回，避免“刚睡下去又被同一个事件叫醒”。

设备模型层和它配合的是sysfs里的power/wakeup属性。驱动调用device_init_wakeup(dev, true)之后，你就能在对应设备目录下看到：

cat /sys/devices/platform/xxx/power/wakeup

输出enabled或disabled。你可以通过echo enabled/disabled动态开关某个设备的唤醒能力，这个在排查“谁在乱唤醒”的时候非常好用。我做功耗调试时有个习惯：先把所有设备wakeup都关掉，确认系统能老实睡着，然后逐个open，每开一个测一轮，谁开的瞬间系统开始乱醒，谁就是嫌疑犯。

这个账本最常见的错误是：驱动创建了wakeup_source但忘了add/register，或者事件处理分支提前return没执行__pm_relax。前者的表现是debugfs里根本看不到这个源，后者的表现是某个源长期处于active状态，系统待机功耗直线上升。

2.2 enable_irq_wake：把一条普通中断变成真正的唤醒源

wakeup_source是软件层面的账本，真正让一条中断线具备唤醒能力的是enable_irq_wake。驱动在自己的初始化代码里对要用的IRQ调用：

ret = enable_irq_wake(irq); if (ret) dev_err(dev, "irq %d cannot be enabled as wakeup: %d\n", irq, ret);

这个调用的底层会走进irq_set_irq_wake，经过IRQ核心层最终调用到对应irq_chip的irq_set_wake回调。也就是说，它同时做了两件事：在内核IRQ核心的数据结构里把这条IRQ标记为唤醒IRQ；在中断控制器硬件上配置这条线的唤醒逻辑。

需要注意几个点。第一，返回值必须检查。如果中断控制器芯片不支持唤醒，enable_irq_wake会返回-ENXIO。你代码写得再对，硬件不支持就是白搭，这属于前面说的硬件层问题。

第二，enable_irq_wake对同一条IRQ是可以多次调用的，内部有引用计数，disable_irq_wake也得配平。共享中断场景下尤其容易踩坑：两个驱动共享一条IRQ，各自都调了enable_irq_wake，其中一个驱动卸载时只调了一次disable_irq_wake，这条IRQ的唤醒标记还留着，行为就变得“说不清是谁在唤醒”。

第三，调用时机也有讲究。很多工程师习惯在probe里无脑调enable_irq_wake，但更稳的做法是结合device_may_wakeup判断，在设备的suspend阶段按需启用：

static int mydev_suspend(struct device *dev) { if (device_may_wakeup(dev)) enable_irq_wake(dev->irq); return 0; }

这样系统真正进入睡眠前才把IRQ切成唤醒模式，平时保持普通中断状态，行为更干净。如果你用设备模型里的标准接口，也可以交给dev_pm_set_wake_irq配合dev_pm_arm_wake_irq来管，内核PM核心会在合适的时机自动arm和disarm，比裸调enable_irq_wake少操心很多时序问题。

设备树方面，很多通用驱动看到wakeup-source属性就会自动初始化唤醒能力。比如gpio-keys、i2c、网络PHY这类驱动，节点里加wakeup-source，驱动内部就会走device_init_wakeup和enable_irq_wake这条路。这也是为什么我给新板子写DTS时，永远先确认设备节点到底有没有这个布尔属性。

2.3 wakeup_count：防止“刚要睡又来了事件”的竞态窗口

睡眠和唤醒之间有个很微妙的竞态：用户态决定“现在睡”，内核刚检查完“没有待处理唤醒事件”，结果一瞬间键盘事件或网络包到了。如果内核不设防，就会带着这个新鲜事件进入睡眠，然后立刻被同一个事件唤醒，表现为一睡就醒。

内核的解法是wakeup_count。正确姿势是这样的：

cat /sys/power/wakeup_count # 假设返回 5 echo 5 > /sys/power/wakeup_count echo mem > /sys/power/state

第一步读出当前计数；第二步把读到的值写回去，这个写操作会被内核拿来和当前计数比对，如果这段时间里没有新事件，写入成功；如果有新事件，计数已经变了，写入直接返回-EAGAIN，你需要重来一遍。只有写入成功后再写mem，这次睡眠才算“干净”。

我用这个机制写过一个小脚本做压力测试：

#!/bin/sh while true; do cnt=$(cat /sys/power/wakeup_count 2>/dev/null) || exit 1 if echo "$cnt" > /sys/power/wakeup_count 2>/dev/null; then echo mem > /sys/power/state break fi sleep 1 done

这个脚本模拟了很多电源管理守护进程的典型行为。你手头如果有自己写的睡眠管理程序，一定要走这条路，别直接echo mem。直接写的后果就是系统在事件密集时疯狂一睡就醒，短时间看不出，放到真实环境里要么耗电异常，要么睡眠成功率极低。

提示：做自动化睡眠测试时，系统里不一定只有你一个进程在操作wakeup_count，多线程来回读写会导致频繁-EAGAIN，属于正常现象，不是内核bug。

2.4 IRQF_NO_SUSPEND与真正唤醒源的区别

写中断驱动时还会接触IRQF_NO_SUSPEND这个标志。它和唤醒源是两码事，但非常容易被混为一谈。

IRQF_NO_SUSPEND的意思是：这条IRQ在suspend_device_irqs阶段不会被内核关掉，事件来了还能正常送到CPU去处理handler。说白了，它保证的是“系统还没睡死时，这条中断依然活着”。

而真正的唤醒源，走的是enable_irq_wake这条路，保证的是“CPU已经进入WFI/WFE/HLT这种睡死状态后，硬件能把电源拉起来让CPU复活”。这两个能力一前一后：CPU没睡死之前靠IRQF_NO_SUSPEND，CPU睡死之后只能靠唤醒源。

有些看门狗中断、跨核IPI确实会标IRQF_NO_SUSPEND，因为它们在系统睡眠的早期阶段还得工作。但如果你把普通设备的IRQ也标上这个标志，后果很严重：系统还在suspend过程中、驱动已经suspend了，结果这条中断来了，handler跑起来去访问一个已经断电或没恢复的设备，轻则状态错乱，重则死锁。我给某块板子调触摸屏唤醒时就踩过一次，触摸IRQ被标了IRQF_NO_SUSPEND，每次睡眠到一半那个中断就把系统砸醒，日志全是异常栈。

所以记住一句判断口诀：想让设备在睡眠后把系统叫醒，用enable_irq_wake这套；想中断在suspend前半段继续供驱动使用，用IRQF_NO_SUSPEND。两个标志解决的是不同时间窗口的问题，不要互相替代。

3. 实操：从内核配置到定位唤醒慢问题的完整路径

3.1 内核配置项：先把调试工具打开再谈排查

很多唤醒问题排查不下去，不是因为难，而是内核根本没编译调试选项，什么信息都看不到。下面这几个配置我建议做低功耗开发时无条件打开：

验证方法很简单，在你的目标板上执行：

zcat /proc/config.gz | grep -E "CONFIG_PM_TEST|CONFIG_PM_DEBUG|CONFIG_DEBUG_FS"

如果内核没开CONFIG_IKCONFIG_PROC，那就只能直接去翻内核源码的.config。没有这些选项，后面讲的pm_test和wakeup_sources全都用不了，等于瞎猜。

3.2 pm_test分阶段测试：五分钟定位挂起失败的环节

拿到一块新板子，第一步永远是确认“内核自己能不能睡、能不能醒”，而不是先上你自己的驱动。pm_test就是干这个的。

它把suspend流程切成五段：freezer、devices、platform、processors、core。每段测试的目的都是只走到该阶段就停止并自动resume，从而把问题逼到具体环节。

操作方式：

echo freezer > /sys/power/pm_test echo mem > /sys/power/state

如果freezer阶段就卡死，说明进程冻结环节有问题，通常是某个内核线程不响应冻结请求。成功后换devices：

echo devices > /sys/power/pm_test echo mem > /sys/power/state

卡在这里就是设备驱动suspend的问题。以此类推，platform阶段卡住找平台suspend回调，processors阶段卡住找CPU idle和热插拔逻辑，core阶段卡住说明最核心的睡眠机制有硬件问题。

测完一定要记得恢复：

echo none > /sys/power/pm_test

我调过一块开发板，表现为“写mem必死”。用pm_test从freezer一路测到core，前四段全过，最后core段必死，最后定位到是RTC作为唤醒源时和核心时钟配置冲突。没有pm_test，这个问题可能要查好几天。另外别忘了配合：

echo 1 > /sys/power/pm_print_times

这个开关让内核在日志里打印每个suspend/resume阶段耗时，是分析“睡眠慢”“醒得慢”最直接的依据。唤醒延迟优化基本全靠它。

3.3 debugfs wakeup_sources字段解读与使用姿势

wakeup_sources是排查唤醒问题最常用的debugfs节点：

cat /sys/kernel/debug/wakeup_sources

输出大致是这样一组列：

正确的用法是睡眠前和睡眠后各读一次，做diff。比如你故意按一下按键把系统唤醒，起来后立刻读这个文件，你会看到对应按键那条记录里event_count和wakeup_count都加了1。如果设备唤醒了但对应记录wakeup_count没变，说明它虽然是唤醒源但并不是这次唤醒的发起者，那就去查别的源。

这个节点对定位“待机漏电”也极其关键。如果某个源active_since非常新，而且两次读取之间total_time一直上涨，说明它长期处于active状态，极可能是驱动某条路径忘记调用__pm_relax。找到名字后回驱动代码里搜对应wakeup_source，十有八九能发现某个异常分支提前return了。

3.4 案例一：RTC定时唤醒的完整验证流程

RTC定时唤醒是验证睡眠唤醒通路最干净的手段，因为它不依赖外部按键，时间可控。我的标准流程是：

# 查看系统支持的睡眠状态 cat /sys/power/state # 用rtcwake设置10秒后唤醒并进入内存睡眠 rtcwake -d /dev/rtc0 -m mem -s 10

系统会在10秒后自己醒来。醒来后看日志：

dmesg | tail -n 50

能看到suspend entry、suspend exit一类的记录，同时确认唤醒原因。再对比唤醒前后的wakeup_sources，rtc0那条记录应该能看到event_count、wakeup_count增加。如果配合功耗仪，还能在睡眠的10秒里测到曲线下落和回升。

如果rtcwake报错，分几种情况：不支持mem，就改用-m freeze先验证s2idle通路；rtc设备路径不是/dev/rtc0，就查/dev下有哪些rtc设备；最隐蔽的是RTC闹钟中断虽然存在，但驱动根本没调enable_irq_wake，闹钟到点后只能让系统从idle醒，不能从mem醒。这种问题要看rtc驱动源码里的wakeup配置，别只查应用层。

手动方式也值得会，因为有些老平台rtcwake不可用：

echo 0 > /sys/class/rtc/rtc0/wakealarm # 先清掉旧闹钟 echo $(($(date +%s) + 10)) > /sys/class/rtc/rtc0/wakealarm echo mem > /sys/power/state

注意先清再写。不清就写，某些RTC芯片会给你保留旧闹钟，导致“设的是10秒结果1秒就醒”。

3.5 案例二：GPIO按键唤醒的驱动与DTS配置要点

按键唤醒是最常见的应用场景，也是坑最多的地方。设备树里一般长这样：

gpio-keys { compatible = "gpio-keys"; power-key { label = "Power Button"; gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; linux,code = <KEY_POWER>; wakeup-source; debounce-interval = <10>; }; };

wakeup-source这个布尔属性是关键。gpio-keys驱动看到它之后，会在内部调用device_init_wakeup和enable_irq_wake，把按键IRQ变成唤醒源。如果你自己写驱动，对应的代码就是：

device_init_wakeup(&pdev->dev, true); dev_pm_set_wake_irq(&pdev->dev, irq);

或者更直接：

enable_irq_wake(irq);

这里有几个实际调试得出的经验。第一，优先使用GPIO_ACTIVE_LOW。按键的一端通常接地，按下时引脚被拉低，低电平触发的方式比上升沿抗噪声强得多。第二，debounce-interval一定要设。按键是机械结构，按下瞬间会有抖动，没有硬件去抖时，睡眠期间一次抖动就能造成“假唤醒”，系统睡下去几秒钟又弹起来，看起来像完全没办法睡眠。第三，睡眠前检查按键是否处于按住状态。如果按键一直被按着，电平一直处于有效态，低电平触发的唤醒中断在睡眠那一刻就满足条件，于是系统一睡就醒。正确的驱动行为是在suspend回调里读一下当前按键电平，如果发现已经按下，就返回-EAGAIN让本次suspend失败，等用户松手再说。

还有一个隐藏点：GPIO控制器和中断控制器必须在睡眠时保持供电。有的SoC里GPIO0~3在always-on域里，GPIO4以后跟着主域掉电。如果你把唤醒按键接到掉电那组GPIO上，DTS写得再对都没用。这是一个非常容易被忽视的硬件约束。

4. 常见问题与排查技巧速查

4.1 系统怎么也唤不醒：按这条主线逐层排查

唤不醒的现象最折磨人，因为机器看起来完全没反应。我的排查顺序固定如下：

先确认系统确实进入了目标睡眠状态。看电流或者看日志，如果根本没进去，那是睡眠本身失败，不是唤醒问题。接着用rtcwake做最小验证，排除整块板的硬件问题。这一步过了，再查具体设备的唤醒注册：

驱动力面，最典型的问题就是只写了request_irq而忘了enable_irq_wake。我在代码评审里见到过太多次，中断申请了、handler写了、设备树里也写了wakeup-source，但驱动代码本身没有调device_init_wakeup或enable_irq_wake，导致设备树属性根本没生效。所以排查时不要只盯DTS，也要回驱动源码确认链路完整。

另一个常见原因是GPIO引脚在睡眠时被外部电路拉死了。比如按键引脚上接了LED驱动或上拉电阻，睡眠时该电路进入高阻或不稳定状态，把引脚电平弄到唤醒条件永远满足不了。这种情况软件查不出毛病，必须上示波器看睡眠前后的引脚电平变化。

4.2 一睡就醒：pending中断、电平触发和共享中断的坑

一睡就醒是另一个高频问题，成因通常有几种。

第一种，唤醒事件在系统睡眠前已经发生，但驱动没有消费掉，中断一直pending。内核在正式进入睡眠前会检查唤醒IRQ的pending状态，发现有人在等着，就直接中止本次睡眠。表现就是每次echo mem之后系统秒醒，日志里能看到这次睡眠被中止的痕迹。解法是回驱动确认事件处理程序是否真的把中断状态清掉了，特别看电平触发类型的中断——电平没释放，pending就永远存在。

第二种，电平触发方式选错。低电平触发的中断源，如果按键一直处于按下状态，或者引脚悬空被外部干扰拉到有效电平，睡眠一定失败。解决方案是检查按键是否释放后再进睡眠，给引脚配上正确的上拉/下拉电阻，必要时从边沿触发改成低电平加去抖，或者相反，结合硬件实际电平反向选择。

第三种，共享中断。两个设备共用一条IRQ线，其中一个设备配置了唤醒，另一个没有。结果是任何一个设备的事件都会通过这条共享线唤醒系统。排查手段是看/proc/interrupts里这条irq对应的设备列表，把不需要唤醒的设备wakeup属性关掉。

第四种，是用户态没做wakeup_count防护。前面讲过，直接echo mem不读wakeup_count，在事件密集场景下必然出现睡下就醒。这类问题在RTC定时唤醒下测不出来，因为RTC闹钟设的是未来时间，而真正的高频事件是网络包、传感器中断这种随时可能来的东西。

4.3 唤醒后系统挂死或中断风暴

如果系统能唤醒，但唤醒后马上死机、重启，或者某个中断疯狂触发，问题通常在resume时序。

一个典型场景是：唤醒IRQ在resume_device_irqs阶段被重新打开时，事件源还在有效电平，中断立刻再次触发。此时该设备的驱动还没完成resume，handler去访问还没恢复的外设寄存器，直接挂死。解决办法有两种：一种是在设备的resume_noirq回调里先disable_irq，等到普通resume阶段设备准备就绪后再enable_irq；另一种是使用线程化中断request_threaded_irq，让handler在独立线程里跑，时序更好控制。

中断风暴的表现是/proc/interrupts里某个IRQ的计数在1秒内暴涨几千上万。有个内核对“持续疯狂触发的中断”有保护，会在日志里打出“Disabling IRQ #NN”之类的字样，直接把这条中断关了。结果就是你按键按到天荒地老也没反应，因为中断被内核禁掉了。排查时如果看到这个日志，重点查这条中断对应的硬件是不是在睡眠期间引脚悬空、电平乱跳。

唤醒后死机还有一种常见原因是resume顺序：某个设备的resume依赖先恢复的中断控制器，而共享IRQ的handler在另一个设备还没resume时被调用，数据结构被访问到半初始化状态。这种问题往住要结合驱动代码和dmesg的“suspend/resume各阶段耗时”日志一起看，确认是不是某个驱动resume太慢导致后续设备超时。

4.4 唤醒源异常导致待机耗电的隐蔽问题

这类问题不会让系统醒不来，而是让系统“睡眠质量很差”，待机电流比预期高出一大截。最常见的原因是某个wakeup_source一直处于active状态。

排查方法很简单：间隔30秒连续读两次wakeup_sources：

cat /sys/kernel/debug/wakeup_sources > /tmp/ws1 sleep 30 cat /sys/kernel/debug/wakeup_sources > /tmp/ws2 diff /tmp/ws1 /tmp/ws2

对比两次输出，如果某个源的active_since一直停留在最近时间，total_time持续增长，说明这个源从未relax。常见的代码问题是在某个异常分支里直接return，跳过了后面的__pm_relax调用。

解决办法是在调用pm_wakeup_event时带上合理的超时时间，比如：

pm_wakeup_event(ws, 50); /* 50ms后自动relax */

这样就算驱动逻辑有漏洞，事件也不会永远卡住系统。但超时时间不能设太长，否则系统会在每次事件后长时间推迟睡眠，同样耗电。一般几十到几百毫秒看业务需要。

另外，有些网络设备默认开启远程唤醒功能，比如网卡收到广播包就上报wakeup事件。这种场景下wakeup_sources里对应设备event_count会平稳上涨，电流虽然不高但明显偏高。如果业务上不需要远程唤醒，直接：

echo disabled > /sys/devices/.../power/wakeup

关掉它，待机电流立刻掉下来。

提示：调试任何唤醒问题，都建议先做一次“最小睡眠验证”。用rtcwake确认内核自身睡眠唤醒通路完好，再逐个打开设备唤醒功能。这个基线的价值在于，当你把某个设备的wakeup打开后问题复现，就能确定问题的引入点就是那个设备，不用再从整条链路里大海捞针。

我个人在实际项目里养成的习惯是：拿到新板子，第一件事就是用rtcwake跑一个10秒定时唤醒，把内核本身的睡眠唤醒基线测通；之后每加一个设备唤醒源，就睡一次、量一次电流、读一次wakeup_sources，全部记录成一张对照表。这个办法看起来笨，但排查速度比直接扑到代码里快得多。碰到过好几块板子，最后都是靠这张表找到罪魁祸首——不是驱动逻辑多复杂，而是某个设备在睡眠时电平悬空，把整个功耗预算拉爆了。这套路不挑平台，不挑内核版本，建议你也试试。