On Mon, 2 Feb 2015, Peter Chen wrote: > >> 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?
I don't understand the question. > 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? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return -ENODEV immediately. 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
