From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752419AbcHIBQD (ORCPT ); Mon, 8 Aug 2016 21:16:03 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:32377 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764AbcHIBQC (ORCPT ); Mon, 8 Aug 2016 21:16:02 -0400 Subject: Re: [PATCH] device probe: add self triggered delayed work request To: Frank Rowand , 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> <57A92DB5.1080007@gmail.com> Cc: Greg Kroah-Hartman , Grant Likely From: Santosh Shilimkar Organization: Oracle Corporation Message-ID: <03e6a023-258b-9bbd-3c20-89b51b987ff3@oracle.com> Date: Mon, 8 Aug 2016 18:15:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57A92DB5.1080007@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 Signed-off-by: Greg Kroah-Hartman