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 <f...@studiofuga.com> 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 Remote Procedure Call driver. Quoting the Kconfig file, "An rpmsg driver that exposes the Remote Procedure Call API to User Space, in order to allow applications to distribute remote call to more power efficient remote processors on OMAP4+ systems". It depends on rpmsg system. > 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. > omaprpc is out of the official mainline code, it's inside the official ti/omap branch/project. I guessed that the easier solution had been to change the initialization level, in a similar way it's done by the i2c bus driver for example. I don't know if this is the best solution to solve this, maybe the problem could be solved in the omaprpc driver (maybe this could be the right solution). > If your code is anyway out-of-tree, it'd probably make more sense if > this patch stays out of tree too (plus I have no way to review this > patch, and understand the issue it fixes, without seeing the relevant > code). > > If this really is about mainline kernel, let me know. > Really, I don't have enough experience to say if it should be solved this way or not. For what I can see, this seems absolutely logic that busses are initialized before other drivers, so subsys_initcall should be perfectly logic. But I don't have the complete view of the system, so I could be wrong. On the other hand, I didn't find another way to solve this dependency problem. I know there is also a Makefile approach, but the dependent driver (omaprpc) is in the staging driver directory, so I think is not feasible. Any other solution? Thanks Federico -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
