On Tue, 3 Feb 2015, Peter Chen wrote: > > > 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. > > > > It is module_init(ehci_pci_init) in ehci-pci.c, so ehci_pci_init will always be called. Oops, yes, you're right. I was thinking of ehci_pci_setup, sorry. ehci_pci_init will indeed get called. But it won't overwrite anything in ci_hdrc_host_init. The only thing it touches is its own private ehci_pci_hc_driver structure. 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
