On Sat, May 22, 2010 at 12:57 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Sat, May 22, 2010 at 12:44:32AM +0300, Felipe Contreras wrote: >> [no changes since the last v2, just rebased on top of the latest >> git://gitorious.org/~doyu/lk/mainline.git for-tony-mailbox] >> >> Currently, the code is split into three places: >> 1) mach-omapX/devices.c: for platform_device_register() the resources >> 2) mach-omapX/mailbox.c: do platform_driver_register(), fetch the resources, >> and register logical mailboxes with omap_mbox_register() >> 3) plat-omap/mailbox.c: implement omap_mbox_register() to add the mbox >> to an internal linked list (static struct omap_mbox *mboxes) >> >> So, obviously 1) is always built-in, but 2) can't be because of the >> dependency of omap_mbox_register(), which is in 3) and cannot be taken >> out. >> >> Users of mailbox will load 3) due to omap_mbox_get(), but not 2), >> therefore, no mailboxes will be registered. > > This doesn't make sense - why would 3 be loaded due to the dependency > which comes from 2, but not 2? All the exported functions, including omap_mbox_get(), are in 3). 2) depends on 3) because 3) implements omap_mbox_register(). 3) doesn't depend on 2). > The only reason 3 would be loaded due to that dependency is if 2 were > being modprobed, which means it's going to be inserted after 3 anyway. > > I don't see anything else in 3 which would trigger it to be loaded. > > The "platform:omap2-mailbox" module alias of 2 should result in 2 > being modprobed, I see, at initialization? > causing 3 to be loaded to satisfy the dependency. > As already pointed out, this should happen as a result of udev or > (older) hotplug initialization. Well, in the minimal system I have in my beagleboard it doesn't happen. I load bridgedriver, which loads mailbox, but fails immediately because mailbox_mach is not there. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
