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

[Frank Rowand <frowand.list@gmail.com>]

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.


> Thanks,
> -Qing

< snip >