On Thu, Jan 29, 2015 at 10:44:48AM -0500, Alan Stern wrote: > On Thu, 29 Jan 2015, Peter Chen wrote: > > > > > Then, it is strange. Do we need even two glue layer drivers for pci > > > > device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, > > > > and its host driver will call ehci_init_driver, it is definitely > > > > duplicated with usb/host/ehci-pci.c. > > > > > > ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c > > > is a driver for a USB Device Controller. > > > > > > > In fact, it is not, ci_hdrc_pci is the pci glue layer for chipidea > > driver. I am just wonder andy's v2 change is suitable or not, the > > right way should not call ehci_pci_init at all. > > The chipidea driver is structured in an odd way. It looks like the PCI > device combines a host controller and a device controller (and maybe > even an OTG controller) into a single device. > Any problems for that? > That's why the chipidea driver has to duplicate ehci-pci.c and register > various platform devices. If ehci-pci were allowed to bind to the > device then the gadget controller (and OTG controller?) would be > unusable, because ehci-pci doesn't know how to use them. > If the chipidea has host function, it doesn't need any drivers at usb/host/ehci-*.c, the v1 patch for this thread, it just doesn't compile ehci-pci.c, and it should work too. Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init is still needed to call? The chipidea driver has already done the same thing in ehci_pci_init. -- Best Regards, Peter Chen -- 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
