From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755798Ab1GERa2 (ORCPT ); Tue, 5 Jul 2011 13:30:28 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52908 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751794Ab1GERa1 (ORCPT ); Tue, 5 Jul 2011 13:30:27 -0400 Date: Tue, 5 Jul 2011 10:29:03 -0700 From: Greg KH To: Grant Likely Cc: Kay Sievers , Arnd Bergmann , Mark Brown , linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , "David S. Miller" Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism Message-ID: <20110705172903.GB1155@suse.de> References: <20110704170949.11059.92774.stgit@ponder> <20110704180159.GA11278@ponder.secretlab.ca> <20110705142149.GA3498@suse.de> <201107051721.02079.arnd@arndb.de> <20110705155040.GB16682@suse.de> <20110705163628.GB31984@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 05, 2011 at 11:17:46AM -0600, Grant Likely wrote: > On Tue, Jul 5, 2011 at 10:36 AM, Greg KH wrote: > > On Tue, Jul 05, 2011 at 10:28:37AM -0600, Grant Likely wrote: > >> On Tue, Jul 5, 2011 at 10:11 AM, Kay Sievers wrote: > >> > On Tue, Jul 5, 2011 at 17:50, Greg KH wrote: > >> > > >> >> I wonder if doing this all from a workqueue in the first place is going > >> >> to cause problems as probe isn't normally done this way at all. > >> > > >> > Yeah, I would expect unforeseen problems with the async thread too. > >> > It's probably all solvable, but it sounds troublesome to find out if > >> > things go wrong. > >> > > >> > We have sync hooks (BUS_NOTIFY_*) where any kind of code can subscribe > >> > to when devices get added or get bound to a driver. Can't the code > >> > that relies on later hookups to already existing devices/bindings not > >> > just plug into that? > >> > >> I tried that.  It resulted in a lot of complexity that each driver > >> needs to implement correctly which is why I started looking for a > >> different way to go about it. > > > > No, the bus that wants this just has to do it, not the drivers > > themselves, right? > > It's not about the bus_type, and there is nothing that the bus can do > to solve this problem because it the dependencies are completely > orthogonal to the bus. ie. what does an i2c bus know about the audio > path to a codec? The problem must be solved at the driver scope. Ok, let's look at your next implementation and see how it goes.