From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752940Ab2IIH4N (ORCPT ); Sun, 9 Sep 2012 03:56:13 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57439 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752164Ab2IIH4M (ORCPT ); Sun, 9 Sep 2012 03:56:12 -0400 Date: Sun, 09 Sep 2012 09:56:09 +0200 Message-ID: From: Takashi Iwai To: Benjamin Herrenschmidt Cc: Greg Kroah-Hartman , Ming Lei , Linus Torvalds , Alan Cox , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/5] driver core: driver probe asynchronously In-Reply-To: <1347176866.2385.100.camel@pasglop> References: <1347146720-28596-1-git-send-email-ming.lei@canonical.com> <20120909025702.GB9525@kroah.com> <1347176866.2385.100.camel@pasglop> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Sun, 09 Sep 2012 17:47:46 +1000, Benjamin Herrenschmidt wrote: > > On Sat, 2012-09-08 at 19:57 -0700, Greg Kroah-Hartman wrote: > > As you state, this doesn't really solve the problem, and will cause a > > lot more (think about all the busses that aren't expecting to have > > their > > probe functions called at the same time as other probe functions are > > being called.) > > > > So while I applaud the effort, I can't accept this due to the past > > history of when it was tried before. > > Maybe a compromise would be to have ->probe() be called synchronously as > done currently, but to add support for a specific -EAGAIN return from > it, requiring a later asynchronous re-probe ? (Possibly requiring an > explicit trigger) So it's something pretty similar like -EPROBE_DEFER, but the deferred probing is rather based on the standard async probe? I find it'd make sense, as the current deferred probing is somewhat hackish. Forcing all asynchronous right now looks risky, but selective way of easy async probing would be welcome. thanks, Takashi > That would allow drivers who fail some kind of "oddball" dependency (the > firmware load is such as case, there are a few others) to basically > install some kind of notifier and try again later when the dependency > has been fulfilled. > > That way existing drivers still behave synchronously, there is no > breakage unless drivers are explicitly modified for async probing.