Re: cvs commit: src/sys/bus/usb usb.c

[Michael Neumann <mneumann@xxxxxxxx>]

Matthew Dillon wrote:
> :mneumann    2008/05/25 09:53:41 PDT
> :
> :DragonFly src repository
> :
> :  Modified files:
> :    sys/bus/usb          usb.c 
> :  Log:
> :  Defer boot-time exploration of USB busses until all devices in the
> :  system have been attached, but no later. This ensures that we do
> :  not explore ohci or uhci busses before the companion ehci controller
> :  has been initialised, so it should fix the problem of multi-speed
> :  USB devices getting attached as USB 1 devices first and then
> :  re-attached as USB 2.
> :  
> :  This fixes issue #946 for qemu and my HP Compaq 6710b laptop.
> :  
> :  Obtained-from:  FreeBSD/usb.c 1.104 to 1.106 and NetBSD/usb.c 1.35
> :  Dragonfly-bug:  <http://bugs.dragonflybsd.org/issue947>
> :  
> :  Revision  Changes    Path
> :  1.44      +31 -10    src/sys/bus/usb/usb.c
>
>     Make sure USB keyboards still work :-)  There was some code in there
>     to probe for a USB keyboard very early in the boot sequence.  I forget
>     where exactly.

Oh yes, my commit seems to revert usb.c rev 1.24 [1]. I should have read
this before. But I don't think rev 1.24 is very good, as it leads to
kernel panics :).

What exactly is cold boot? Is it what I think it is:

  cold boot = machine is powered on for the first time
  warm boot = just do a jump to the BIOS init routine

I wonder how FreeBSD has solved the problem, if at all, because I do not
see any further special code that would handle USB keyboards early at
boot.

I don't understand what exactly is the reason why cold boot is
distinguished from warm boot when configuring devices. Maybe they go
amock for warm boot because they are already configured?

[1]:
http://www.dragonflybsd.org/cvsweb/src/sys/bus/usb/usb.c.diff?r1=1.23&r2=1.24&f=h