On Wed, 18 May 2011, Sarah Sharp wrote: > > Right. In kernels where the drivers are compiled in rather than being > > built as modules, the binding takes place in the right order because > > PCI functions are probed in order of function number, and an EHCI > > controller is always the highest-numbered function in its slot (this is > > required by the EHCI spec). > > Ah, ok, good to know. So that's how the PCI probes between EHCI and > UHCI/OHCI are serialized, once the EHCI driver is loaded first. I I wouldn't put it quite like that. That's how the probes are _ordered_; they are _serialized_ merely by virtue of the fact that the PCI core doesn't probe things in parallel. Furthermore, the order of probing is not directly related to the order of driver loading (although it is _indirectly_ related, because if the drivers aren't already present when the devices are probed then each probe will cause the modprobe system to try to load the corresponding driver). > assume there's only one EHCI and UHCI/OHCI combo per PCI slot? In all the controller cards or chipsets I have seen, each PCI slot holds no more than one EHCI controller. They generally have multiple UHCI or OHCI controllers. > If there > are other devices in that slot besides those two, does EHCI have to have > the highest numbered function of all those devices? Or just higher than > the companion controller? Just higher than the companions. (See the third paragraph of section 4.2 in the EHCI-1.0 spec.) But I've never run across a PCI slot that combined USB controllers with any other devices. > > As a matter of fact, it's generally not so terrible if the drivers get > > loaded in the wrong order. What happens is a few devices connect first > > at full speed to the OHCI or UHCI controller, and then when ehci-hcd > > starts up, the device is disconnected and then reconnected at high > > speed (if the device supports it) or at full speed again. This > > disconnection/reconnection sequence is awkward, looks funny in the > > logs, and can cause problems for a few devices. But mostly it doesn't > > matter. > > What if your root filesystem is on a USB storage device when this > disconnect happens? Or any filesystem, in general? If the startup code tries to mount the root filesystem too early (before it has migrated over to the EHCI controller), the boot will fail when ehci-hcd takes over. Likewise with any other mount. > The usb-storage > driver waits 5 seconds to start filesystem setup, but the UAS driver has > no such lag. That 5-second value is only a default; it can be changed. I set it to 0 on my systems -- only a few types of USB storage devices need it (some early iPods, for example). I think some distros may reduce it. 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
