[PATCH v2t2 00/17] omap: mailbox:

[Felipe Contreras]

On Sat, May 22, 2010 at 12:57 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> 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