Hi, 2010/12/16 Felipe Balbi <balbi@xxxxxx>: > Hi, > > On Wed, Dec 15, 2010 at 09:50:46PM +0800, Ming Lei wrote: >>> >>> 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. > > you changed the behavior of that part, right ? thus fixing, with one > possible approach, the root cause ;-) Seems the option(USB_MUSB_OMAP2PLUS) shouldn't declared as bool since it may depend on one 'm' option(USB_MUSB_HDRC), so omap2430.o is not linked into vmlinux. Then the problem will return to the topic discussed in musb-cleanup thread this days: - driving multiple musb hw controllers using one same set of musb binary drivers I think it makes sense, for example mach-omap2 may support tusb, am35x and omap2430, so it is valuable for os-distribution(such as Ubuntu/angstrom/...) that one same omap2 image can support all the musb controllers for different omap2 boards. If we agree on the feature above makes sense, building glue layer driver as module is to be supported for memory footprint reason. Felipe and all, if you don't have objections, I will go ahead to work on musb-cleanup v1. Or any suggestions? thanks, -- 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
