From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752320AbcHIBLj (ORCPT ); Mon, 8 Aug 2016 21:11:39 -0400 Received: from mail-pf0-f177.google.com ([209.85.192.177]:34930 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752208AbcHIBLh (ORCPT ); Mon, 8 Aug 2016 21:11:37 -0400 Subject: Re: [PATCH] device probe: add self triggered delayed work request To: Qing Huang , linux-kernel@vger.kernel.org References: <1469857179-23863-1-git-send-email-qing.huang@oracle.com> <57A8EF35.2090903@gmail.com> <57A8FED1.7080003@oracle.com> Cc: Greg Kroah-Hartman , Grant Likely , Santosh Shilimkar From: Frank Rowand Message-ID: <57A92DB5.1080007@gmail.com> Date: Mon, 8 Aug 2016 18:11:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <57A8FED1.7080003@oracle.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >