On Wed, Dec 15, 2010 at 07:42:45PM +0800, Ming Lei wrote:
2010/12/10 Felipe Balbi <balbi@xxxxxx>:
On Thu, Dec 09, 2010 at 05:15:04PM +0300, Sergei Shtylyov wrote:
Hello.
On 09-12-2010 16:54, Felipe Balbi wrote:
On Tue, Dec 07, 2010 at 06:36:10PM +0200, Felipe Balbi wrote:
Finally, now it should all be great. I'll send the patches
as a reply to this email soon.
I also added a compile error from Ajay added by
commit 4814ced5116e3b73dc4f63eec84999739fc8ed11
(OMAP: control: move plat-omap/control.h to
mach-omap2/control.h) which is necessary to get am35x
to work again.
Sorry for the mess I did this time, it doesn't matter
now the reasons but I can detail the reason of cooking
these patches so quickly in a separate mail, although
I think it's unecessary. It won't happen again.
Anyway, patches follow.
branch updated, sorry about that.
Thanks Sergei for the time spent reviewing.
I'm still seeing issues (not compilation) in the patch 26.
Just fixed. Hema had noticed the same. Thanks, pushed to same branch.
Seeing compilation issue in patch 9 and Kconfig option misnaming in patch
5... :-/
I fixed your three comments and am looking into the module stuff. Looks
weird. Symbols are added to built-in.o but not to vmlinux. Makefile
evaluates to obj-y so it should go to vmlinux unless I'm missing
something.
I'll keep on looking for the root cause, but the thing is just that
since omap2430.o symbols aren't in vmlinux, there's never a driver to
match that device and musb-hdrc can't be probed.
The same problem touches me too, and seems it is not trivial thing,
maybe we should fix it in this patches.
not changing the pull request again, sorry. We will fix during -rc
cycle, even if it means changing musb from tristate to bool for the time
being.
The real issue is that we can't build glue layer as built-in drivers
with musb as dynamic module due to the exported symbols from one
another, that's why I want to avoid exported symbols in the first case.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
