Replying to myself... > From: Paul Zimmerman > Sent: Friday, January 11, 2013 2:22 PM > > > From: Felipe Balbi [mailto:balbi@xxxxxx] > > Sent: Friday, January 11, 2013 1:44 AM < snip > > > I would like it much better if you would follow what we did for dwc3 and > > have core IP in a separate driver with pci/exynos/whatever glue in a > > parent device driver. Still, if you really want to make core IP driver a > > library, then at a minimum do it right, don't expose ALL functions, make > > sure you have a small set of APIs for the glue to call. Encapsulate > > implementation details from your users, they really don't need to call > > each function separately. Ideally pci glue would call dwc2_initialize() > > on probe() and that's it. > > Once we get to the point of integrating another interface, like for a > platform driver, I plan to make the core code a separate module, so > the code can be shared instead of being duplicated in each driver. But > we're not quite there yet. > > But I disagree with the "small set of APIs" thing. It would be a HUGE > amount of effort to rewrite the code like that. The reason the code > is in separate files is to give it a somewhat logical arrangement, and to > avoid having one gargantuan source file. There is no intention to have > individual APIs for each of the files. I disagree that there are any > external "users" like you mention above, it is all one driver. After rereading this, I think I misunderstood what you were saying. If you mean have a small API between the core module and the bus glue module, then I agree. I think it's already fairly small, but I can look at trimming it down some more. -- Paul -- 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
