On 10/14/2011 12:03 PM, Grant Likely wrote:
On Fri, Oct 14, 2011 at 12:56 PM, David Daney<ddaney.cavm@xxxxxxxxx> wrote:
On 10/14/2011 10:20 AM, Grant Likely wrote:
On Fri, Oct 14, 2011 at 10:33 AM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx>
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'
leaf device **at the time of its driver probe**. :-) After the
device has all of its dependencies met, it can freely add child
devices. In your case, the child devices will get added by the
Mux-MDIO device driver, so all is good.
Indeed. Thanks for the confirmation.
David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
