年前在跟一个量产项目，现象很刁钻：同一台设备，插上原装充电器，状态栏没有任何变化，拔掉电源线的那一刻，反而弹出了“正在充电”。最开始怀疑是充电IC坏了，换了两块主板依然复现，后来才意识到问题根本不在硬件，而是 USB 状态更新没有按预期转换成充电事件。这个项目用的是 Unisoc 平台，内核切在 kernel 5.15，问题恰好卡在 USB 状态检测、内核事件上报和充电IC联动这条链路上。
当时我把/sys/class/power_supply/usb/online打开盯了好几分钟，看着它从 1 变 0 又变 1，才彻底搞明白：标题里写的“USB 状态更新充电事件”，本质上不是“读到VBUS高电平就完事”这么简单，而是要保证一次插拔动作能准确地、按顺序地触发上层关心的充电状态变化。这篇文章就围绕这个主题，把链路原理、方案选型、设备树配置、内核上报、充电类型映射以及实测中踩过的坑完整梳理一遍，适合做 Android BSP、充电驱动、TWS 充电仓或者智能硬件 Linux 驱动的工程师参考。
1. 需求拆解：一次USB插拔要穿越多少层才能变成充电图标
1.1 用户看到的“正在充电”到底是什么
从用户视角看，充电图标只是一个 UI 变化。但从内核工程师的视角看，这背后是一条完整的事件链：物理 VBUS 出现高电平；驱动检测到 USB 插入；power_supply或extcon子系统更新状态；内核发出uevent；用户态的healthd/HealthService收到事件；最终由SystemUI刷新锁屏充电状态。
每一步之间都有可能导致状态不一致。尤其是 Unisoc 平台这类项目，BSP 驱动往往由芯片厂商、方案商、整机厂多轮 patch 叠加，USB 状态更新链路可能被不同的驱动分别维护。你这个“充电事件”只要有一层没有同步，呈现出来的现象就千奇百怪：插上没反应、拔了还在充、充电速率被锁死、Type-C 正反插表现不一致等等。
1.2 USB状态与充电事件为什么不能直接画等号
很多初次接触这块的同学容易把“USB 状态”和“充电事件”当成一回事，这是最大的误区。USB 状态是一个宽泛概念：它至少包括连接状态、断开状态、Type-C 方向、数据角色、PD 协商结果等。而充电事件只是其中一小部分，而且它关心的是另外三个问题：
- 线是否插上了（online 状态）；
- 插上的是什么类型的 USB 口（SDP/CDP/DCP/PD）；
- 当前允许从 VBUS 抽取多大电流。
在 kernel 5.15 上，驱动至少要同时回答这三个问题，才能算一次完整的充电事件上报。如果只把“VBUS 拉高”当成“充电器插入”来处理，就会得到一台能显示充电、但电流永远被锁在 500mA 的机器。原因很简单：没有告诉上层这是 DCP 还是 SDP，上层只能按最保守的 USB 口来推测。
1.3 为什么在 kernel 5.15 上这个问题更值得关注
kernel 5.15 相比老内核，变化最明显的就是 USB Type-C 子系统的成熟度大幅提升，typec、usb_role_switch、extcon这些机制都在往“各司其职”的方向演进。但现实项目里，Android 传统链路依然保留了power_supply那一套，两套体系交叉作用，很容易出现状态源重复或冲突。
我在实际项目里遇到过类似状态：typec驱动负责上报 USB 方向与角色，充电驱动负责上报charge_type，两者各自维护一套状态机，只要有一方没有把状态同步到另一方，就会出现“在线状态已经变了，但充电事件没跟上”的情况。这也是为什么在 Unisoc + kernel 5.15 这种组合下，必须把链路理清楚再动手改代码。
2. VBUS检测方案选型：ADC轮询、GPIO中断还是PHY状态
2.1 三种主流检测方式的取舍
Unisoc 平台做 USB 状态检测，最常用的就是下面三种方式。我按实际工程中的使用频率和坑的多少来对比：
| 检测方式 | 原理 | 优点 | 缺点 | 典型场景 |
|---|---|---|---|---|
| PMIC ADC 轮询 | 通过 ADC 通道读 VBUS 电压，阈值判定 | 不依赖 GPIO 占用，硬件简单，能读到电压数值 | 实时性差，VBUS 放电慢时在线状态残留 | 低成本方案、工程机 |
| GPIO 中断 | VBUS 经分压之后接到 GPIO，上升/下降沿触发 | 响应快，逻辑简单，功耗低 | 需要确认分压与电压域，对毛刺敏感 | 绝大部分量产机 |
| USB PHY 状态 | PHY 内部监测总线有效状态 | 状态最准确，不需要额外检测硬件 | 硬件排线必须把 VBUS 检测接到 PHY，部分平台不好移植 | 标准 Type-C 口 |
我在量产项目里更倾向于“GPIO 中断为主 + ADC 复核为辅”的组合。GPIO 负责快速响应插拔，ADC 负责二次确认，防止 GPIO 检测线上因为分压电容、ESD 器件导致的电压爬升或跌落过慢而误触发。
2.2 设备树里我是怎么配的
以某个 Unisoc 平台项目为例（这里不写具体芯片型号，配置思路是通用的），设备树中通常定义一个节点来描述 VBUS 检测 GPIO：
vbus_detect: vbus-detect { compatible = "vendor,vbus-detect"; vbus-gpio = <&ap_gpio 47 GPIO_ACTIVE_HIGH>; debounce-ms = <30>; wakeup-source; status = "okay"; };三个字段需要注意：
vbus-gpio：GPIO 的active电平取决于硬件分压方式，有些硬件 VBUS 在线时 GPIO 被拉低，有些是拉高，必须对照原理图确认，不要只看默认配置。debounce-ms：这个值太短会引入大量误报，太长会丢失快速插拔。我一般从 20ms 到 50ms 之间调，最后量产机型稳定在 30ms。wakeup-source：关闭屏幕时，VBUS 上升沿必须能够唤醒 AP。这个字段漏掉之后，会出现息屏插入充电器，系统不亮屏也不提示充电的诡异现象。
2.3 中断触发驱动的几个工程细节
GPIO 中断注册没那么复杂，但有几个点非常容易被坑：
第一，上升沿和下降沿都必须注册。很多驱动只处理了上升沿，结果 USB 断开时状态完全没更新，表现为“拔了线还在充”。这个 bug 很隐蔽，因为拔掉瞬间电量还在涨，测试不容易立刻发现。
第二，中断处理函数里不要做重量级操作。正确做法是request_threaded_irq或者只置标志位、起一个delayed_work，真正去更新online状态和上报 uevent 的动作放到线程上下文。如果在中断上下文直接操作充电IC的 I2C，大概率会遇到 I2C 总线忙、mutex 冲突，直接把系统卡住。
第三，针对 GPIO 毛刺，驱动里要配合mod_delayed_work做二次确认：中断触发后不立即更新状态，而是等若干毫秒再读一次 GPIO 电平，确认稳定后才算数。我遇到过一次项目，ESD 防护器件导致插拔瞬间 GPIO 出现约 10ms 的抖动，不加确认机制的话，一次插拔会触发三四次状态翻转。
3. 状态上报路径选择：power_supply与extcon，谁才是充电事件的出口
3.1 两条路径的本质区别
检测到 VBUS 之后，下一步就是状态上报。Unisoc 平台 kernel 5.15 里，常见的有两条路径：power_supply子系统上报，或者extcon子系统上报。
它们的分工其实很清楚。extcon面向外部连接器，适合上报 Type-C 方向、USB 线类型、音频附件等，内核里监听的一方是其他驱动；power_supply面向电源设备，上报的是online、type、voltage_now、current_now这些属性，最终用户态healthd读的就是它。
如果你把充电事件放在extcon里上报，用户态不一定能直接感知，还需要另一层驱动做中转。所以我的结论很直接：最终给上层看的充电在线状态，必须以power_supply为出口。extcon可以作为中间状态存在，但不能把外设驱动对外报的关键信息漏掉。
3.2 一次uevent是怎么组装出来的
power_supply触发上报的核心调用是power_supply_changed()，它会生成一条 uevent。在/sys/class/power_supply/usb/节点上，uevent文件里可以看到类似内容：
POWER_SUPPLY_NAME=usb POWER_SUPPLY_TYPE=USB_DCP POWER_SUPPLY_ONLINE=1这里有一个关键点：POWER_SUPPLY_TYPE和POWER_SUPPLY_ONLINE的出现顺序，是由驱动内部更新属性的时序决定的。我在项目里经过反复验证，得到的结论是：插入时一定要先更新type，再更新online；拔线时则反过来，先清online，再回退type。
为什么？用户态处理 uevent 时，通常是按事件整体来读。如果online=1先到而type还是旧的USB，上层可能按 SDP 限流逻辑走一遍，后面再收到 type 变更事件时，充电IC已经按 500mA 初始化了，需要额外一次 renegotiate 才能提升电流。这个时间差在现场表现为“插上适配器之后，要过几秒钟电流才上来”。
3.3 5.15内核里，typec、extcon、power_supply如何协同
kernel 5.15 上还有一个绕不开的角色：typec子系统。它会管理 CC 引脚、数据角色、PD 协商等，但它的状态并不直接等于充电状态。我的处理习惯是：
typec驱动只负责上报连接器状态和角色的变化；extcon或专门的 VBUS 检测驱动负责监听这些变化，并过滤出“对外设来说有价值”的信息；power_supply驱动作为最后的出口，把过滤后的结果转换成online和type；- 充电IC驱动挂在
power_supply上，通过power_supply_changed的回调收到事件。
这样就把“检测到底层状态”和“消费上层事件”解耦了。调试的时候也容易隔离开：看typec状态判断物理连接，看power_supply状态判断充电逻辑，哪一层不对就查哪一层。
4. 充电事件加工：从online=1到充电IC输入限流的完整映射
4.1 为什么BC1.2识别和PD协商要排在状态后面
“VBUS 有电压”并不等于“这是个充电器”。USB 口类型决定了 VBUS 能提供多大的电流，所以在power_supply的type属性上，不能简单填一个USB。常见的类型包括：
USB：默认 SDP 逻辑，电流上限一般 500mA；USB_DCP：专用充电口，比如常见的充电头，电流按适配器能力来；USB_CDP：可以一边传数据一边充电的类型；USB_PD：PD 协商后的受电能力，电流电压由 PD 协议决定。
Unisoc 平台的充电驱动一般会先通过 D+/D- 检测完成 BC1.2 识别，或者等待 PD 协商结果，然后才把type更新成最终类型。在这之前，online可以先置 1，但type不要急着改。如果这个顺序没处理好，上层会误以为这是一个标准 USB 口，把充电电流限制得很保守。
BC1.2 检测本身需要时间，D+ 和 D- 的采样、比较器的建立稳定、软件消抖，可能让 type 更新比 VBUS 出现晚几十到几百毫秒。这个时间窗口里，充电IC需要有一个明确的默认状态：VBUS 在线但类型未知，按 500mA 预充，等类型确认后再切换限流。
4.2 一张表看懂USB状态到充电事件的映射
我在量产项目里维护过一张状态映射表，排查问题全靠它对照：
| 底层状态 | power_supply type | online | 充电行为 |
|---|---|---|---|
| VBUS未连接 | USB | 0 | 关闭充电路径，charge_type=NONE |
| VBUS在线，BC1.2未完成 | USB | 1 | 按SDP预充，限制500mA |
| BC1.2识别为DCP | USB_DCP | 1 | 按DCP限流，走适配器快速充电 |
| BC1.2识别为CDP | USB_CDP | 1 | 允许数据+充电同时进行 |
| BC1.2识别为SDP | USB_SDP | 1 | 按标准USB口限流 |
| 识别为PD适配器 | USB_PD | 1 | 等待PD协商，按PDO电压电流配置 |
这张表看着简单，但实际项目里有不少分支细节。比如支持无线充电的设备，无线充电器的online也是 1，但它的usb_type是USB或者Unknown，不能因为充电事件触发就顺手去初始化 USB 的 BC1.2 检测逻辑。又比如带着 USB 线做 DFU 升级时，online=1是必然的，但此时不能走正常充电路径去降低数据通信的可靠性。
4.3 顺序问题与事件节流的工程处理
插拔状态变化时，最忌讳的就是每个字段都独立触发一次power_supply_changed()。一次插入动作如果同时更新了online、type、voltage_now，就会连续冒出好几条 uevent，上层逻辑在短时间窗口内会被反复唤醒，日志里能看到一长串重复事件。
我的做法是做一个简单的“事件节流器”：状态发生变化时，先把所有需要更新的字段写入本地缓存，再统一调用一次power_supply_changed()。这样一次插拔最多触发一条有效事件。如果状态连续抖动（比如劣质线材导致接触不良），还可以在驱动里加一个状态机，要求新状态必须稳定保持超过 100ms 才允许对外上报。
这个设计我当时是从“防 uevent 风暴”的角度做的，后来发现它顺带解决了另一个问题：用户态拿到的事件是全量的、自洽的，不会读到“type=USB_DCP 但 online=0”这种中间态。
5. 踩坑复盘：误报、漏报和时延问题的完整排查链路
5.1 案例一：拔线后状态栏一直显示“正在充电”
这个就是我文章开头说的那个诡异的量产项目问题。先说排查链路，再给结论。
第一步，硬件确认。用万用表量 VBUS，拔线之后电压确实是按预期跌落的。这说明问题不在物理电源。
第二步，确认 GPIO 电平。在设备树节点下读 GPIO 值，发现拔线瞬间 GPIO 已经被硬件拉到了空闲电平。说明硬件检测部分也是对的。
第三步，看内核态状态。cat /sys/class/power_supply/usb/online，发现它依然是 1。到这里问题就锁定在驱动软件层面：GPIO 中断没有成功触发，或者触发了但状态没有更新。
第四步，开 dynamic_debug 看中断日志。结果发现，拔线下降沿没有打印任何中断服务函数日志。再翻代码，发现驱动注册中断时用的是IRQF_TRIGGER_RISING，只处理了上升沿。
根因就是这么简单：驱动只注册了 VBUS 插入中断，把断开中断漏掉了。修复方法也很直接，改成IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING，同时配合 debounce 机制。这个坑我认为是这一类问题里最常见的一类，排查链路本身比最终修复更有参考价值。
5.2 案例二：插入后充电状态更新明显偏慢
另外一个项目里，插入充电器后，锁屏显示充电图标要等 2 到 3 秒。如果只看现象，很容易怀疑是系统 UI 性能问题，但其实链路卡在内核。
排查过程里最关键的证据来自 tracepoint。kernel 5.15 里power_supply_changed事件可以在/sys/kernel/tracing/events/power/power_supply_changed/下抓到。我通过 trace 发现，VBUS 中断早就触发了，但对应的power_supply_changed()调用被阻塞了很久。
继续往下挖，阻塞点在充电IC驱动向power_supply_changed注册的回调里：这个回调直接在做 I2C 读操作，而另一个并发线程持有 I2C bus 的 mutex，刚好赶上它在做长时间的温度补偿计算。
这类问题的改法不是改 USB 状态检测，而是改充电IC驱动的回调策略。中断来的那一刻，回调里只标记“需要处理”，由独立的工作队列去做真正的 I2C 操作和状态轮询。这样 USB 状态上报链路就不会被 I2C 卡住。
5.3 调试USB状态更新充电事件的三板斧
调试这类问题，我最常用是三个手段，优先级从高到低：
- sysfs 节点：
cat /sys/class/power_supply/usb/online、cat /sys/class/power_supply/usb/type、cat /sys/class/power_supply/battery/status，最快的状态确认方式。 - dynamic_debug：
echo "file drivers/power/supply/* +p" > /sys/kernel/debug/dynamic_debug/control，把内核日志打开，直接看power_supply层发生了什么。 - tracepoint：
/sys/kernel/tracing/events/power/power_supply_changed/，能准确抓到每次上报的时间点，用于判定“是没上报，还是上报太晚”。
用户态这边，logcat -s HealthService BatteryProperties可以直接看到上层收到的事件。如果一个事件在内核里已经上报了，但用户态没有收到，那问题一般在ueventd的权限过滤或者 SELinux 策略上，而不是驱动本身。
5.4 量产前的USB充电状态验证清单
最后分享一份我在项目里持续维护的验证清单，专门用来测 USB 状态更新到充电事件的完整性：
| 测试项 | 操作 | 预期结果 |
|---|---|---|
| 标准充电器插入 | 息屏状态下插入 | 状态栏充电图标出现，type=USB_DCP，电流达到适配器能力 |
| 标准充电器拔出 | 充电中直接拔掉 | 状态栏充电图标消失，online=0，charge_type回落 |
| PC USB口插入 | 插电脑USB口 | type=USB_SDP，限流500mA，数据功能正常 |
| 正向/反向插入 | Type-C 正反各插一次 | 状态事件一致性，无差异化表现 |
| 快速连续插拔 | 3秒内插拔5次 | 无异常死机，无 uevent 风暴，状态稳定跟随 |
| 低电量插入 | 电量低于5%时插入 | 充电路径开启，无断流，图标正常显示 |
| 息屏唤醒 | 息屏时插入充电器 | 设备唤醒并提示充电状态 |
我个人调试这类问题的通用套路是：先把链路每一步的可观测性做出来。硬件上脉冲计数看插拔是否真实发生，sysfs 看内核状态是否跟随，tracepoint 看事件上报时延，logcat 看用户态是否消费。哪一层数据对不上，就缩小到哪一层去查。大多数 USB 状态更新充电事件相关的疑难日志，追到最后往往不是高深的技术，而是某个驱动少注册了一个中断、某个回调里做了重操作、或者 devicetree 里漏掉了一个wakeup-source。把链路看清楚了，问题就藏不住。
