设备树中I²C子节点是否会在of_platform_populate()流程中被实例化为platform_device的疑问及机制确认

你对of_platform_populate()整个流程的梳理非常精准，先给你点个赞！针对你的核心疑问，咱们直接给出结论再拆解细节：

核心结论 #

I²C控制器的子节点不会被of_platform_populate()实例化为platform_device，你的理解和DT示例都是完全正确的。

具体机制拆解 #

1. 递归停止的触发条件
   你已经注意到，of_platform_bus_create()里有这么一段关键逻辑：

   if (!dev || !of_match_node(matches, bus)) return 0;
   

   这里的matches就是传入的match_table（包含simple-bus、simple-mfd这类总线兼容字符串）。对于你的I²C控制器节点i2c0来说：

   • 它会被成功创建为platform_device（因为是根节点的子节点，有compatible属性，未被标记跳过/已实例化）
   • 但它的compatible是vendor,foo-i2c，不在match_table的匹配列表里，所以of_match_node()会返回NULL
   • 这直接触发了返回0的逻辑，递归处理子节点的流程就此终止，所以它下面的I²C设备节点根本不会被of_platform_populate()触及。

2. I²C子节点的正确处理路径
   那I²C设备节点怎么被实例化呢？这要靠I²C控制器对应的platform_driver来完成：

   • 当I²C控制器的platform_device和platform_driver匹配成功后，驱动的probe函数会被调用
   • 在probe函数里，驱动会先注册I²C适配器（比如调用i2c_add_numbered_adapter()）
   • 之后，驱动会通过of_i2c_register_devices()（或内部封装的类似逻辑）去解析控制器节点的子节点，把它们实例化为i2c_client设备，而非platform_device
   • 最终这些i2c_client会和对应的I²C设备驱动（i2c_driver）匹配，完成设备的初始化工作。

关于你的DT示例的确认 #

你提供的DT片段完全符合实际的内核处理逻辑：

• 根节点下的i2c0节点：会被of_platform_populate()创建为platform_device，因为它通过了所有前置检查
• 它的子节点temperature-sensor@48和eeprom@50：不会被of_platform_populate()处理，而是等待I²C控制器驱动去解析，最终成为i2c_client设备。

额外补充：为什么platform_device现在也用DT？ #

你提到的“platform_device原本是给非可发现硬件”是早期的定义，现在嵌入式系统里，platform总线更多是作为一种通用总线，用来处理那些没有专门总线协议（比如I²C、SPI、PCI）的设备，或者总线控制器本身。这些设备通过DT来描述，实现硬件的可发现性，这是内核发展过程中形成的合理用法。

内容来源于stack exchange