Re: Question about EHCI and UHCI/OHCI driver load

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 18, 2011 at 11:50:23AM -0400, Alan Stern wrote:
> On Tue, 17 May 2011, Greg KH wrote:
> 
> > On Tue, May 17, 2011 at 02:46:26PM -0700, Sarah Sharp wrote:
> > > I see that ehci-hcd.c has a warning in when either the UHCI or OHCI
> > > driver is loaded before the EHCI driver:
> > > 
> > >         set_bit(USB_EHCI_LOADED, &usb_hcds_loaded);
> > >         if (test_bit(USB_UHCI_LOADED, &usb_hcds_loaded) ||
> > >                         test_bit(USB_OHCI_LOADED, &usb_hcds_loaded))
> > >                 printk(KERN_WARNING "Warning! ehci_hcd should always be loaded"
> > >                                 " before uhci_hcd and ohci_hcd, not after\n");
> > > 
> > > What actually prevents the UHCI or OHCI driver from being loaded before
> > > the EHCI driver?  Is it left up to userspace?
> > 
> > Yes.  Hopefully all of the distros now have properly modprobe rules to
> > load these before the ehci driver, otherwise we would be getting the
> > kernel warnings sent to us :)
> 
> 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
assume there's only one EHCI and UHCI/OHCI combo per PCI slot?  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?

> > > Since PCI devices can be initialized in parallel, even if the EHCI
> > > driver is loaded first, that doesn't guarantee that the PCI probe for
> > > the EHCI controller actually finishes before the UHCI/OHCI PCI probe,
> > > right?
> > 
> > I didn't think that PCI devices were initialized in parallel all that
> > often, so this might be pretty rare.
> 
> In particular, the pci_scan_child_bus() and pci_scan_slot() routines
> in drivers/pci/probe.c don't contain any parallelization.
> 
> 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?  The usb-storage
driver waits 5 seconds to start filesystem setup, but the UAS driver has
no such lag.

Sarah Sharp
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux