Re: [PATCH] device probe: add self triggered delayed work request

[Santosh Shilimkar]

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@xxxxxxxxx>
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@xxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>