From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism Date: Fri, 14 Oct 2011 11:56:15 -0700 Message-ID: <4E9885CF.1000301@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org To: Grant Likely Cc: Alan Stern , Ming Lei , Andrei Warkentin , Greg KH , Dilan Lee , "G, Manjunath Kondaiah" , Mark Brown , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Triplett , Manjunath@jasper.es, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linux PM List , "Rafael J. Wysocki" List-Id: linux-omap@vger.kernel.org On 10/14/2011 10:20 AM, Grant Likely wrote: > On Fri, Oct 14, 2011 at 10:33 AM, Alan Stern wrote: >> On Fri, 14 Oct 2011, Grant Likely wrote: >> >>>> How can a device acquire children before it has a driver? >>> >>> There are a few potential situations in embedded systems (or at least >>> nothing currently prevents it) where platform setup code constructs a >>> device hierarchy without the aid of device drivers, and it is still >>> possible for a parent device to be attached to a driver. IIUC, SPARC >>> creates an entire hierarchy of platform_devices from all the nodes in >>> the OpenFirmware device tree, and any of those devices can be bound to >>> a driver. I don't like that approach, but at the very least it needs >>> to be guarded against. >> >> Do these devices ever require deferred probes? > > Yes, they very well might. However, I'm happy with the limitation > that only leaf devices can take advantage of probe deferral. > I have: I2C-Bus-A +--Mux-I2C (controlled by parent I2C-Bus-A) +---I2C-Bus-1 | +--GPIO-Expander-A | +---I2C-Bus-2 +--GPIO-Expander-B These all have a parent/child relationship so no deferral is needed, so far so good. Then this: MDIO-Bus-A +---Mux-MDIO (controlled by GPIO-Expander-A) +---MDIO-Bus-1 | +---MDIO-Bus-2 +---PHY-1 | +---PHY-2 In this case the driver for Mux-MDIO needs to be deferred until *both* MDIO-Bus-A's driver *and* GPIO-Expander-B's driver are loaded. A perfect use case for the patch. Would you consider Mux-MDIO to be a 'leaf device'? If not, then I have real problems with 'the limitation that only leaf devices can take advantage of probe deferral' David Daney