Messages in this thread | | | Date | Wed, 9 May 2007 10:53:52 -0700 (PDT) | From | david@lang ... | Subject | Re: Please revert 5adc55da4a7758021bcc374904b0f8b076508a11 (PCI_MULTITHREAD_PROBE) |
| |
On Wed, 9 May 2007, Cornelia Huck wrote:
> On Wed, 9 May 2007 10:09:33 -0700 (PDT), > david@lang.hm wrote: > >>> Hm, so that sound like a case for a distinct setup() routine: >>> >>> 1. bus calls ->probe(), which return synchronously >>> 2. bus calls ->probe_async() for all devices (optional) >>> 3. bus waits for all probes to finish >>> 4. bus calls ->setup() for all devices (which does the registering) >> >> this is exactly what I've been trying to describe. > > Nearly, but with a slightly different spin... > >> >>> (->setup() can but need not be sync, although it should be for your >>> case) >> >> if it's not sync then you have race conditions again > > ...but not all busses will care. If your bus wants to enforce ordering, > it must enforce it to be sync. If your bus allows hotplug and calling > setup() later on, it may also allow async. (setup() is a bit > dual-purpose in this idea.)
if you want the registration to use hotplug and be async then do do the registration during step 2 and make step 4 be a noop, in fact some drivers may do all their work in step 2, while others (everything currently) will do all their work during step 1
David Lang
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |