On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote: mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate the correct fabric device (probably as a platform_device) from the platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The platform code can create a device that isn't bound to a driver. So why not make this an of_platform_device? This is basically a pseudo device that isn't in the device tree.
Simply because it doesn't have a device node. That's the prime characteristc that differentiates platform_bus from of_platform_bus. What do you bind against in of_platform_bus if you don't have a specific node for it?
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
Yes, but it requires the core ASoC code to not be a module. Then you can use machine_device_initcall() to register the device at a later time.
Cheers, g.