[PATCH 2/5] drivercore: Add driver probe deferral mechanism

[David Daney]

On 10/14/2011 10:20 AM, Grant Likely wrote:
> On Fri, Oct 14, 2011 at 10:33 AM, Alan Stern<stern at 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