4. 传统同步probe机制：probe函数的阻塞特性与启动延迟问题

在嵌入式Linux系统中，传统的驱动probe机制采用同步阻塞模式。当内核发现设备与驱动匹配时，会立即调用驱动的probe函数，并且必须等待probe函数执行完毕并返回后，内核才能继续处理下一个设备的匹配与probe。这种串行化的执行方式在设备数量较少时问题不大，但随着嵌入式系统外设日益复杂，同步probe带来的启动延迟问题变得不可忽视。

4.1 同步probe的执行流程

同步probe的典型调用链如下：

1. 总线（如platform总线）扫描已注册的设备与驱动。
2. 匹配成功后，总线调用驱动的probe函数。
3. probe函数执行硬件初始化、资源申请、中断注册等操作。
4. probe函数返回0（成功）或负值（失败）。
5. 总线继续扫描下一个匹配对。

4.2 probe函数的阻塞来源分析

probe函数的阻塞时间由多个因素叠加而成，下表列出了主要的阻塞来源及其典型耗时：

4.3 启动延迟问题的量化分析

假设一个嵌入式系统有N个设备需要probe，每个设备的平均probe时间为T_avg，则总启动延迟D_sync为：

D_sync = Σ(T_probe_i)   (i = 1 to N)

当N较大且T_avg不可忽略时，延迟呈线性增长。以一个典型的路由器/网关设备为例：

• 网络PHY（2个）：每个probe耗时约120ms（含MDIO通信+自协商等待）
• WiFi模块（1个）：probe耗时约350ms（含固件加载+RF校准）
• 音频Codec（1个）：probe耗时约80ms（含I2C配置+时钟稳定）
• USB控制器（1个）：probe耗时约200ms（含PHY初始化+电源序列）
• 其他传感器/GPIO扩展（5个）：每个约30ms

总延迟计算：

D_sync = 2×120 + 1×350 + 1×80 + 1×200 + 5×30
       = 240 + 350 + 80 + 200 + 150
       = 1020 ms

这意味着仅驱动probe阶段就消耗了超过1秒的启动时间，而这还不包括内核解压、文件系统挂载、init进程启动等环节。

4.4 同步probe的时序示意图

下图展示了同步probe模式下多个设备的串行执行时序：

4.5 同步probe的主要缺陷

• CPU利用率低： probe函数在等待硬件就绪时（如I2C应答、GPIO电平变化），CPU处于空闲等待状态，无法执行其他初始化任务。
• 头阻塞效应： 排在队列前面的慢速设备会阻塞后面所有设备的probe，即使后面的设备可以快速完成初始化。
• 启动时间不可预测： 如果某个外设的probe依赖于外部硬件状态（如SD卡插入检测、传感器上电时序），启动时间会随硬件状态波动。
• 不利于系统快速启动： 对于需要快速启动的场景（如车载娱乐系统、工业控制器），同步probe往往成为启动瓶颈。

4.6 同步probe vs 异步probe：初步对比

4.7 实际案例：某工业控制器的启动延迟分析

某基于i.MX6ULL的工业控制器，系统启动过程中同步probe的耗时分布如下：

[    1.234] platform fec.0: probe start
[    1.354] platform fec.0: probe done (120ms)
[    1.355] platform 2188000.ethernet: probe start
[    1.475] platform 2188000.ethernet: probe done (120ms)
[    1.476] spi_imx 2008000.spi: probe start
[    1.496] spi_imx 2008000.spi: probe done (20ms)
[    1.497] spi_imx 200c000.spi: probe start
[    1.517] spi_imx 200c000.spi: probe done (20ms)
[    1.518] at24 0-0050: probe start
[    1.558] at24 0-0050: probe done (40ms)
[    1.559] mcp251x 1-0000: probe start
[    1.759] mcp251x 1-0000: probe done (200ms)  // CAN控制器，SPI通信慢
[    1.760] wm8960 2-001a: probe start
[    1.840] wm8960 2-001a: probe done (80ms)
[    1.841] gpio-keys: probe start
[    1.842] gpio-keys: probe done (1ms)
...
[    2.350] init: starting init process

从日志可以看出，仅驱动probe阶段就消耗了约1.1秒（从1.234s到2.350s），其中CAN控制器的probe占了200ms，两个网络PHY占了240ms。如果采用异步probe，这些耗时操作可以并行执行，理论上可以将probe阶段的总延迟降低到最慢设备的probe时间（约200ms）加上调度开销。