On Fri, 30 Jan 2015, Peter Chen wrote: > > 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?
No, but it is odd and it requires some code to be duplicated. > > 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. Yes, it will work. But if you go back to the second message in this thread (http://marc.info/?l=linux-usb&m=142229289226237&w=2) you will see why that patch isn't a good idea: It means that the Intel MID platform cannot use a universal kernel build -- that is, one where every driver is included. > 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. You're right; ehci_pci_init isn't needed. But there's no way to eliminate it and still have a universal kernel build. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
