It _is_ confusing. There's so much going on at boot time, with tons of
processes all trying to run at once... Small changes can have
unexpectedly large effects.
What I said before was that the UHCI controllers are discovered and
registered before the EHCI controller. That's different from the order
in which the drivers are loaded, however; driver loading is managed
by the hotplug infrastructure in userspace, which is outside the
kernel's control. If your drivers had been built into the kernel
instead of as separate modules, then they would be probed in order of
discovery -- which would mean ehci-hcd would _always_ come after
uhci-hcd, not what you want.
(Actually even this might not be true any more. There are patches in
development which make certain parts of the kernel initialization,
including driver probing, run in parallel threads rather than
serially.)
So it worked as intended.
Both statements are correct. The initialization of the devices on
buses 3 and 4 _was_ complete. But the drivers were loaded later, so
driver probing and/or normal driver operation were in progress when
ehci-hcd interrupted things. Initialization != probing.
Remember what I said earlier, that EHCI initialization would interfere
with _any_ ongoing operations on the companion controllers? Now you're
seeing that effect in action.
I still regard this more as a band-aid than anything else. In fact, it
should (in theory) be _safer_ to interrupt things during device
initialization than later, after the driver has started up. So I'm not
at all certain the patch should be merged.
Tomorrow I'll try asking for comments from other people on the mailing
list...
Alan Stern
--
