2010/12/15 Felipe Balbi <balbi@xxxxxx>: > 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. In fact, if you try applying all the musb cleanup patches against the musb_hw branch of your tree, you will find there does not have the issue any longer, either built as all modules or all built-in, so I don't think the root cause is exported symbols. -- Lei Ming -- 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
