linux-kernel - Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Jul 2012 18:43:35 +0200
From:	Federico Fuga <fuga@...diofuga.com>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH] rpmsg bus subsys_initcall initialization ordering

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 <fuga@...diofuga.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/