Messages in this thread | | | Subject | Re: [PATCH] device probe: add self triggered delayed work request | From | Santosh Shilimkar <> | Date | Mon, 8 Aug 2016 18:15:49 -0700 |
| |
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 <bunk@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 <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| |