From: Greg KH <gregkh@suse.de>
To: Simon Arlott <simon@fire.lp0.eu>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Rene Herman <rene.herman@keyaccess.nl>,
Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
Daniel Walker <dwalker@mvista.com>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH RFC] USB: Add HCD fastboot
Date: Wed, 6 Aug 2008 12:29:13 -0700 [thread overview]
Message-ID: <20080806192913.GA29239@suse.de> (raw)
In-Reply-To: <4899F96D.9060809@simon.arlott.org.uk>
On Wed, Aug 06, 2008 at 08:20:13PM +0100, Simon Arlott wrote:
> On 06/08/08 20:11, Alan Stern wrote:
>> On Wed, 6 Aug 2008, Simon Arlott wrote:
>>> On 31/07/08 20:16, Alan Stern wrote:
>>> >> > It's not entirely clear why usblp is blocking at all. Probably
>>> because
>>> >> > it is waiting on the device semaphores for devices that are
>>> currently
>>> >> > being probed -- the driver core won't allow two threads to probe the
>>> >> > same device concurrently.
>>> >> >> Ok - so there could be some big improvements to be had by making
>>> the hcd >> init happen as early as possible and the device initcalls
>>> later?
>>> > > Maybe. Perhaps a better approach would be to make the device driver
>>> > initcalls before there are any devices for their probe routines to >
>>> block on.
>>> What about this?
>>> The Makefiles become a bit messy, but by moving things around I get the
>>> desired effect without splitting their initcalls.
>> Wouldn't it be much simpler, and less objectionable, to do what I
>> suggested earlier? That is, add a 5-second delay at the start of
>> hub_thread() in drivers/usb/core/hub.c. No messing with Makefiles, no
>> changes to the initcall scheduling.
>
> Aside from 5 seconds being too long, and anything less being a race between
> hub_thread() and driver initcalls, it doesn't improve anything because
> it'll still have to wait for the devices to finish initialising in
> userspace instead.
And what is your boot time if the usb drivers are modules?
I'd much prefer that requirement to get a faster boot than to go around
mucking with the link-time ordering...
thanks,
greg k-h
next prev parent reply other threads:[~2008-08-06 19:32 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-20 15:59 [patch 4/3] fastboot: hold the BKL over the async init call sequence Arjan van de Ven
2008-07-20 16:00 ` [patch 5/3] fastboot: sync the async execution before late_initcall and move level 6s (sync) first Arjan van de Ven
2008-07-20 16:40 ` Ingo Molnar
2008-07-20 21:14 ` Daniel Walker
2008-07-20 21:23 ` Simon Arlott
2008-07-20 21:50 ` Arjan van de Ven
2008-07-29 21:00 ` Rene Herman
2008-07-29 21:04 ` Arjan van de Ven
2008-07-29 21:12 ` Rene Herman
2008-07-29 21:21 ` Arjan van de Ven
2008-07-29 22:30 ` Rene Herman
2008-07-29 22:34 ` Simon Arlott
2008-07-30 14:08 ` Alan Stern
2008-07-30 18:25 ` Simon Arlott
2008-07-30 19:41 ` Alan Stern
2008-07-31 11:49 ` Simon Arlott
2008-07-31 15:34 ` Alan Stern
2008-07-31 18:29 ` Simon Arlott
2008-07-31 18:56 ` Rene Herman
2008-07-31 19:27 ` Simon Arlott
2008-07-31 19:16 ` Alan Stern
2008-08-06 18:40 ` [PATCH RFC] USB: Add HCD fastboot Simon Arlott
2008-08-06 19:11 ` Alan Stern
2008-08-06 19:20 ` Simon Arlott
2008-08-06 19:29 ` Greg KH [this message]
2008-08-06 19:49 ` Alan Stern
2008-08-06 19:56 ` Arjan van de Ven
2008-08-06 20:09 ` Alan Stern
2008-08-06 20:17 ` Arjan van de Ven
2008-08-06 20:27 ` Alan Stern
2008-08-06 20:07 ` Simon Arlott
2008-08-06 20:26 ` Alan Stern
2008-08-06 21:49 ` Simon Arlott
2008-08-06 22:34 ` Alan Stern
2008-08-06 22:53 ` Simon Arlott
2008-08-07 14:14 ` Alan Stern
2008-08-07 3:29 ` David Brownell
2008-08-07 9:28 ` Emanoil Kotsev
2008-08-07 16:47 ` Alan Stern
2008-08-07 3:34 ` David Brownell
2008-08-08 9:24 ` Rene Herman
2008-08-08 11:29 ` Simon Arlott
2008-08-08 14:30 ` Rene Herman
2008-07-31 21:56 ` [patch 5/3] fastboot: sync the async execution before late_initcall and move level 6s (sync) first Greg KH
2008-07-31 22:12 ` Simon Arlott
2008-07-31 22:37 ` Simon Arlott
2008-09-16 22:19 ` Tim Bird
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080806192913.GA29239@suse.de \
--to=gregkh@suse.de \
--cc=arjan@infradead.org \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rene.herman@keyaccess.nl \
--cc=simon@fire.lp0.eu \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox