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

David Daney
2011-10-14T18:56:20Z

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