On Fri, 2 Sep 2011, Sebastian Andrzej Siewior wrote: > On 09/02/2011 04:52 PM, Alan Stern wrote: > > Make each ehci-<arch>.c into a standalone module. Remove all the > > duplicated hc_drivers structures from these files, put a single > > publicly-available ehci_hc_driver in ehci-hcd.c, and make ehci-hcd a > > separate module containing just the core routines. > > I've posted a RFC series which did not introduce separate modules but > moved everything into one file. So you prefer having multiple modules? These are really two different, though related, issues. Coalescing a bunch of the arch-specific drivers would certainly be a good thing. But it's separate from moving the hc_driver structures. > > To make this work, we have to find a way to handle all the individual > > differences in the various hc_driver structures. Most of the > > differences lie in the product_desc and reset fields. > > Yes, and I proposed to handle reset as an argument to usb_add_hcd() Is that really the best way? I have the feeling that in many or most cases, the reset routine could easily be invoked directly from the probe routine before it calls usb_add_hcd(). One of the most difficult cases would be the PCI host drivers, oddly enough, because they all share a common probe routine. But even that could be handled. > > We can get rid of product_desc altogether, and in its place use the > > parent controller's driver name. I'm not sure exactly what would be > > needed for the reset routines, but it mostly looks like we just need to > > refactor some of the startup code. > > see above please. > > > A few drivers, like ehci-tegra.c, will be more troublesome. For such > > cases it might be better to have a private hc_driver structure with > > most of the entries copied from the public ehci_hc_driver. > > One special case out of ten is an improvement :) My thought exactly. > > How does that sound? > > Not bad :) I'll wait to hear from Felipe too... Alan Stern -- 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
