On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl 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.
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?
In the longer term I'd like to kill platform_bus on powerpc and only use of_platform_bus. Platform_bus seems to be functioning like a catch-all and collecting junk from lots of different platforms.
Not going to happen. of_platform_bus is not the right solution, and in fact we're looking at moving (gradually) away from using of_platform_bus, and instead using platform devices (along with the device node being available for *any* struct device via the arch_sysdata).