Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

2012-07-16 Thread Ohad Ben-Cohen
Hi Federico, On Fri, Jul 13, 2012 at 9:00 PM, Ohad Ben-Cohen wrote: > I agree. I'll take it, but will change the commit log to make it > omaprpc-agnostic. Here's what I'm going to apply: commit 913552b8c7a0f06cc1bff27f8e9953bffe6a1817 Author: Federico Fuga Date: Mon Jul 16 10:36:51 2012 +030

Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

2012-07-13 Thread Ohad Ben-Cohen
Hi Federico, On Wed, Jul 11, 2012 at 10:14 AM, Federico Fuga wrote: > it triggers a BUG() in drivers/base/driver.c line 169 Thanks for sharing this; it definitely makes sense now. > The subsys_initcall indeed solve this issue I agree. I'll take it, but will change the commit log to make it oma

Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

2012-07-10 Thread Ohad Ben-Cohen
Hi Federico, On Tue, Jul 10, 2012 at 7:43 PM, Federico Fuga wrote: > omaprpc is out of the official mainline code, it's inside the official > ti/omap branch/project. Ok, thanks for the explanation. In general, we don't change the mainline kernel to solve issues with out-of-tree code. > I guess

Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

2012-07-10 Thread Federico Fuga
Hi Ohad, Il giorno 10/lug/2012, alle ore 18:22, Ohad Ben-Cohen ha scritto: > On Tue, Jul 10, 2012 at 7:07 PM, Federico Fuga wrote: >> omaprpc depends on the rpmsg bus. > > Sorry for the ignorance, but what's omaprpc ? :) > You're right, I should have explained this! :-) omaprpc is the Omap R

Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

2012-07-10 Thread Ohad Ben-Cohen
Hi Federico, On Tue, Jul 10, 2012 at 7:07 PM, Federico Fuga wrote: > omaprpc depends on the rpmsg bus. Sorry for the ignorance, but what's omaprpc ? :) I guess it's some out-of-tree module (which I've never seen) so I'm not sure we want change mainline code to fix issues with it. If your code

[PATCH] rpmsg bus subsys_initcall initialization ordering

2012-07-10 Thread Federico Fuga
omaprpc depends on the rpmsg bus. When those two modules are compiled statically, the omaprpc is initialized before the rpmsg bus, triggering a BUG() in driver_register. This of course can be prevented if they are compiled as modules and loaded in the right order. This patch solves this problem b