嵌入式系统中设备树的工作原理及与传统驱动匹配对比

传统平台驱动的探测流程 #

传统Linux平台字符设备的探测流程核心三步：

• 在设备模型中注册平台设备（注：并非直接注册到VFS，VFS负责文件系统层面管理，设备模型是内核设备管理的核心）
• 通过insmod等命令加载模块，注册平台驱动
• 若设备与驱动名称匹配，触发probe函数执行

这种名称匹配是platform_match函数中最后兜底的匹配逻辑，函数代码如下：

static int platform_match(struct device *dev, struct device_driver *drv)
{
    struct platform_device *pdev = to_platform_device(dev);
    struct platform_driver *pdrv = to_platform_driver(drv);

    /* When driver_override is set, only bind to the matching driver */
    if (pdev->driver_override)
        return !strcmp(pdev->driver_override, drv->name);

    /* Attempt an OF style match first */
    if (of_driver_match_device(dev, drv))
        return 1;

    /* Then try ACPI style match */
    if (acpi_driver_match_device(dev, drv))
        return 1;

    /* Then try to match against the id table */
    if (pdrv->id_table)
        return platform_match_id(pdrv->id_table, pdev) != NULL;

    /* fall-back to driver name match */
    return (strcmp(pdev->name, drv->name) == 0);
}

设备树方式的驱动绑定流程与底层机制 #

设备树方式依然遵循“设备注册→驱动注册→匹配触发probe”的核心三步，但设备来源、匹配逻辑存在差异：

1. 设备树节点转平台设备的过程 #

内核启动阶段会解析设备树二进制文件（DTB）：

• 遍历所有节点，筛选出status属性为"okay"（或未指定status但默认启用）的节点
• 对符合条件的节点，调用of_platform_device_create等接口生成struct platform_device实例：
  • 将节点指针填充到platform_device.dev.of_node字段，保存设备树节点的所有属性、子节点信息
  • 提取节点的compatible属性值，作为匹配的核心标识
  • 最终将该platform_device注册到内核设备模型中

2. 驱动注册与匹配触发 #

当通过insmod加载驱动模块时：

• 驱动初始化函数调用platform_driver_register，将struct platform_driver注册到设备模型
• 内核自动触发设备-驱动匹配，调用platform_match函数：
  • 优先执行of_driver_match_device（设备树匹配逻辑），对比设备树节点的compatible属性列表与驱动中struct of_device_id表定义的兼容字符串
  • 只要有一组字符串匹配成功，platform_match返回1，立即触发驱动的probe函数

3. 设备树的实际工作逻辑 #

设备树是硬件描述数据，核心作用是让内核脱离硬编码适配不同硬件：

• 内核解析DTB后，将硬件拓扑、设备参数（寄存器地址、中断号、时钟等）转换为struct device_node结构
• 驱动在probe函数中可通过dev->of_node调用of_property_read_u32、of_get_address等接口，读取设备树中的硬件参数，完成设备初始化
• 从platform_match代码可见，设备树匹配是优先级最高的匹配方式，优于ACPI、ID表、名称匹配

内容的提问来源于stack exchange，提问作者void_brain