On 08/08/16 18:15, Santosh Shilimkar wrote: > > > On 8/8/2016 6:11 PM, Frank Rowand wrote: >> On 08/08/16 14:51, Qing Huang wrote: >>> >>> >>> On 08/08/2016 01:44 PM, Frank Rowand wrote: >>>> On 07/29/16 22:39, Qing Huang wrote: >>>>> In normal condition, the device probe requests kept in deferred >>>>> queue would only be triggered for re-probing when another new device >>>>> probe is finished successfully. This change will set up a delayed >>>>> trigger work request if the current deferred probe being added is >>>>> the only one in the queue. This delayed work request will try to >>>>> reactivate any device from the deferred queue for re-probing later. >>>>> >>>>> By doing this, if the last device being probed in system boot process >>>>> has a deferred probe error, this particular device will still be able >>>>> to be probed again. >>>> I am trying to understand the use case. >>>> >>>> Can you explain the scenario you are trying to fix? If I understand >>>> correctly, you expect that something will change such that a later >>>> probe attempt will succeed. How will that change occur and why >>>> will the deferred probe list not be processed in this case? >>>> >>>> Why are you conditioning this on the deferred_probe_pending_list >>>> being empty? >>>> >>>> -Frank >>> >>> It turns out one corner case which we worried about has already been >>> solved in the really_probe() function by comparing >>> 'deferred_trigger_count' values. >>> >>> Another use case we are investigating now: when we probe a device, >>> the main thread returns EPROBE_DEFER from the driver after we spawn a >>> child thread to do the actual init work. So we can initialize >>> multiple similar devices at the same time. After the child thread >>> finishes its task, we can call driver_deferred_probe_trigger() >>> directly from child thread to re-probe the >>> device(driver_deferred_probe_trigger() has to be exported though). Or >>> we could rely on something in this patch to re-probe the deferred >>> devices from the pending list... >>> What do you suggest? >> >> See commit 735a7ffb739b6efeaeb1e720306ba308eaaeb20e for how multi-threaded >> probes were intended to be handled. I don't know if this approach is used >> much or even usable, but that is the framework that was created. >> > That infrastructure got removed as part of below commit :-( > > commit 5adc55da4a7758021bcc374904b0f8b076508a11 > Author: Adrian Bunk <b...@stusta.de> > Date: Tue Mar 27 03:02:51 2007 +0200 > > PCI: remove the broken PCI_MULTITHREAD_PROBE option > > This patch removes the PCI_MULTITHREAD_PROBE option that had already > been marked as broken. > > Signed-off-by: Adrian Bunk <b...@stusta.de> > Signed-off-by: Greg Kroah-Hartman <gre...@suse.de>
Hmmmm. :-( indeed. The *_initcall_sync defines are still there, but yep, the wait_for_probes() part is gone. Thanks for the info about the partial removal.