From mboxrd@z Thu Jan 1 00:00:00 1970 From: ddaney.cavm@gmail.com (David Daney) Date: Fri, 14 Oct 2011 11:56:15 -0700 Subject: [PATCH 2/5] drivercore: Add driver probe deferral mechanism In-Reply-To: References: Message-ID: <4E9885CF.1000301@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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