Messages in this thread | | | Date | Fri, 14 Oct 2011 11:56:15 -0700 | From | David Daney <> | Subject | Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism |
| |
On 10/14/2011 10:20 AM, Grant Likely wrote: > On Fri, Oct 14, 2011 at 10:33 AM, Alan Stern<stern@rowland.harvard.edu> 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
| |