On Fri, Jan 30, 2015 at 10:49 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > Does the pci id can pass from platform code/table? How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? -- BR, 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
