[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070509111515.0cb3e63a@gondolin.boeblingen.de.ibm.com>
Date: Wed, 9 May 2007 11:15:15 +0200
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: david@...g.hm
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Adrian Bunk <bunk@...sta.de>, Greg K-H <greg@...ah.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Duncan Sands <duncan.sands@...h.u-psud.fr>
Subject: Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11
(PCI_MULTITHREAD_PROBE)
On Wed, 9 May 2007 01:33:14 -0700 (PDT),
david@...g.hm wrote:
> 1. why should different, unrelated busses need to wait for each other?
> picking two, why can't you have SCSI and USB going through their timeouts
> at the same time?
If they don't have dependencies on each other, yes. Some busses should
be finished before probing for others start (e.g. low-level busses).
> 2. I'm not sure that you can always do the device enumeration before you
> do the slow probing, there's another message in this thread that talks
> about a USB device where you need to load firmware to it before you can
> find out what is really there. in a case like this devices would either
> show up in a random order during step #2, or they should not be added to
> the system until step #3, which makes step #3 more then just waiting for
> the async portions to finish.
I'm not sure whether that is not really a question of "one depends upon
the other". If the low level bus knows where to point its probe at, the
higher level should be able to look at sane devices after the firmware
has been loaded (or am I misunderstanding the situation here?)
-
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