dts 内核展开平台设备

The trick is that the kernel starts at the root of the tree and looks
332 for nodes that have a 'compatible' property.  First, it is generally
333 assumed that any node with a 'compatible' property represents a device
334 of some kind, and second, it can be assumed that any node at the root
335 of the tree is either directly attached to the processor bus, or is a
336 miscellaneous system device that cannot be described any other way.
337 For each of these nodes, Linux allocates and registers a
338 platform_device, which in turn may get bound to a platform_driver.
339
340 Why is using a platform_device for these nodes a safe assumption?
341 Well, for the way that Linux models devices, just about all bus_types
342 assume that its devices are children of a bus controller.  For
343 example, each i2c_client is a child of an i2c_master.  Each spi_device
344 is a child of an SPI bus.  Similarly for USB, PCI, MDIO, etc.  The
345 same hierarchy is also found in the DT, where I2C device nodes only
346 ever appear as children of an I2C bus node.  Ditto for SPI, MDIO, USB,
347 etc.  The only devices which do not require a specific type of parent
348 device are platform_devices (and amba_devices, but more on that
349 later), which will happily live at the base of the Linux /sys/devices
350 tree.  Therefore, if a DT node is at the root of the tree, then it
351 really probably is best registered as a platform_device.
352
353 Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL)
354 to kick off discovery of devices at the root of the tree.  The
355 parameters are all NULL because when starting from the root of the
356 tree, there is no need to provide a starting node (the first NULL), a
357 parent struct device (the last NULL), and we're not using a match
358 table (yet).  For a board that only needs to register devices,
359 .init_machine() can be completely empty except for the
360 of_platform_populate() call.
361
362 In the Tegra example, this accounts for the /soc and /sound nodes, but
363 what about the children of the SoC node?  Shouldn't they be registered
364 as platform devices too?  For Linux DT support, the generic behaviour
365 is for child devices to be registered by the parent's device driver at
366 driver .probe() time.  So, an i2c bus device driver will register a
367 i2c_client for each child node, an SPI bus driver will register
368 its spi_device children, and similarly for other bus_types.
369 According to that model, a driver could be written that binds to the
370 SoC node and simply registers platform_devices for each of its
371 children.  The board support code would allocate and register an SoC
372 device, a (theoretical) SoC device driver could bind to the SoC device,
373 and register platform_devices for /soc/interrupt-controller, /soc/serial,
374 /soc/i2s, and /soc/i2c in its .probe() hook.  Easy, right?
375
376 Actually, it turns out that registering children of some
377 platform_devices as more platform_devices is a common pattern, and the
378 device tree support code reflects that and makes the above example
379 simpler.  The second argument to of_platform_populate() is an
380 of_device_id table, and any node that matches an entry in that table
381 will also get its child nodes registered.  In the Tegra case, the code
382 can look something like this:
383
384 static void __init harmony_init_machine(void)
385 {
386     /* ... */
387     of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
388 }
389
390 "simple-bus" is defined in the ePAPR 1.0 specification as a property
391 meaning a simple memory mapped bus, so the of_platform_populate() code
392 could be written to just assume simple-bus compatible nodes will
393 always be traversed.  However, we pass it in as an argument so that
394 board support code can always override the default behaviour.
395
396 [Need to add discussion of adding i2c/spi/etc child devices]

参考of_platform_populate函数可以发现，第一层有compatible属性的的节点都会被创建平台设备，

若该节点符合of_default_bus_match_table，则该节点的子节点也会被创建平台设备。