Message-ID: <Pine.LNX.4.44L0.0808070956480.2598-100000@iolanthe.rowland.org>
Date:	Thu, 7 Aug 2008 10:14:49 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Simon Arlott <simon@...e.lp0.eu>
cc:	Rene Herman <rene.herman@...access.nl>,
	Arjan van de Ven <arjan@...radead.org>,
	<linux-kernel@...r.kernel.org>, <mingo@...e.hu>,
	Daniel Walker <dwalker@...sta.com>,
	USB list <linux-usb@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH RFC] USB: Add HCD fastboot

On Wed, 6 Aug 2008, Simon Arlott wrote:

> > Not exactly -- you should move most of usb/ forward so that it comes
> > before usb/host/.  Or alternatively move usb/host/ later so that it 
> > comes after the rest of usb/.
> 
> Well, putting usb/ before net/ etc. requires that usb/host/ is the usb/stuff/ or 
> they'll all wait until they can probe for devices.

I don't understand.

I never said you should move usb/.  I said you should move usb/host/ 
after all the rest of usb/*/.

> > Doesn't the host init _already_ come before device init?  If host init 
> > were moved _after_ device init, I don't think there would be a lot of 
> > side effects.  But it's hard to be sure without trying it.
> 
> Host init is before device init, as that's the Makefile link order. Any device 
> init causes it to wait for *all* devices,

"wait" is the wrong word.  Each device init (more accurately, each
device driver init) probes all the USB devices.  But it doesn't have to
wait if nothing else is probing those devices concurrently and if no 
hub activity is going on.

This means that you won't save much time by running multiple USB device
driver initialization threads.  Better to do all those inits in a
single thread.

The ideal situation is to have each device driver initcall run when 
there are _no_ USB devices to be probed -- i.e., before the host 
drivers have been initialized.

> so swapping them around means devices 
> are going to appear at any time after that - there's no device initcall to make 
> it block.
> 
> Presumably it would be possible to have a late_initcall (which would 
> be early in that list if usb was earlier) that could ensure khubd had finished 
> [its current queue] before continuing - as if there was a device driver initcall?
> 
> If someone currently has HCD init compiled in but nothing else, then the boot 
> process would block unnecessarily... the initcall would need to be disabled 
> in that case to maintain existing behaviour - which is why it probably needs 
> to be a config option, which requires some mess in the Makefile or a new 
> initcall type.

Again, I don't understand.  What's wrong with simply reordering 
drivers/usb/Makefile so that all the host/ entries come at the end?

> >> Lack of a keyboard makes it impossible to do anything if the module fails to 
> >> load... as I understand it when the HCD init runs, any BIOS emulation stops?
> > 
> > That's right.  The host driver kicks the BIOS off the hardware.

As David Brownell pointed out, I was wrong about this.  The BIOS gets 
kicked off even before the host driver starts running, as part of PCI 
initialization.

> It seems like there's always going to be a stage where there's no keyboard...

Yes.

> > I noticed in your logs earlier that some of your USB drivers were 
> > compiled in and others weren't.  Maybe if _all_ of them were compiled 
> > in you wouldn't experience as much contention and the init delays would 
> > be shorter.
> 
> I don't know where you got that from - they're definitely all compiled in. 
> Whichever is first to have its initcall run is blocked, and the logs may have 
> been from a test of that.

I must have misinterpreted one of the earlier messages in this thread.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists