From: David Daney <ddaney.cavm@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Ming Lei <tom.leiming@gmail.com>,
Andrei Warkentin <awarkentin@vmware.com>,
Greg KH <greg@kroah.com>, Dilan Lee <dilee@nvidia.com>,
"G, Manjunath Kondaiah" <manjugk@ti.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
Manjunath@jasper.es, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Linux PM List <linux-pm@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
Date: Fri, 14 Oct 2011 11:56:15 -0700 [thread overview]
Message-ID: <4E9885CF.1000301@gmail.com> (raw)
In-Reply-To: <CACxGe6t2Xu5B0AKZJe-6HEpxK6GfuNm0Y2Kb_bs8ZwaTz5XnRg@mail.gmail.com>
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
next prev parent reply other threads:[~2011-10-14 18:56 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 5:33 [PATCH 0/5] Driver Probe Deferral Mechanism G, Manjunath Kondaiah
2011-10-07 5:33 ` [PATCH 1/5] drivercore: add new error value for deferred probe G, Manjunath Kondaiah
2011-10-07 6:43 ` Greg KH
2011-10-07 10:00 ` Mark Brown
2011-10-07 22:12 ` Grant Likely
2011-10-07 23:28 ` Valdis.Kletnieks
2011-10-08 0:12 ` Greg KH
2011-10-09 22:59 ` Grant Likely
2011-10-10 1:06 ` Greg KH
2011-10-12 6:18 ` G, Manjunath Kondaiah
2011-10-13 4:10 ` Grant Likely
2011-10-07 5:33 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism G, Manjunath Kondaiah
2011-10-07 6:49 ` Greg KH
2011-10-07 20:57 ` Josh Triplett
2011-10-07 21:23 ` Greg KH
2011-10-08 4:03 ` Josh Triplett
2011-10-08 15:55 ` Greg KH
2011-10-08 18:18 ` Josh Triplett
2011-10-10 17:37 ` Andrei Warkentin
2011-10-11 12:29 ` Ming Lei
2011-10-13 4:09 ` Grant Likely
2011-10-13 14:18 ` Ming Lei
2011-10-13 14:31 ` Alan Stern
2011-10-13 15:21 ` Ming Lei
2011-10-13 16:04 ` Alan Stern
2011-10-14 0:13 ` Ming Lei
2011-10-13 17:15 ` Grant Likely
2011-10-13 18:16 ` Alan Stern
2011-10-13 18:28 ` Grant Likely
2011-10-14 15:39 ` Alan Stern
2011-10-14 16:17 ` Grant Likely
2011-10-14 16:33 ` Alan Stern
2011-10-14 17:20 ` Grant Likely
2011-10-14 17:33 ` Alan Stern
2011-10-14 18:25 ` Grant Likely
2011-10-14 18:39 ` Alan Stern
2011-10-14 19:07 ` Grant Likely
2011-10-14 18:56 ` David Daney [this message]
2011-10-14 19:03 ` Grant Likely
2011-10-14 19:09 ` David Daney
2011-10-14 15:37 ` Alan Stern
2011-10-12 7:04 ` G, Manjunath Kondaiah
2011-10-07 21:28 ` Grant Likely
2011-10-07 5:33 ` [PATCH 3/5] regulator: Support driver probe deferral G, Manjunath Kondaiah
2011-10-07 5:33 ` [PATCH 4/5] gpiolib: handle deferral probe error G, Manjunath Kondaiah
2011-10-07 10:06 ` Alan Cox
2011-10-07 22:09 ` Grant Likely
2011-10-12 6:14 ` G, Manjunath Kondaiah
2011-10-13 4:12 ` Grant Likely
2011-10-07 5:33 ` [PATCH 5/5] omap: hsmmc: use platform_driver_register G, Manjunath Kondaiah
2011-10-07 6:50 ` [PATCH 0/5] Driver Probe Deferral Mechanism Greg KH
2011-10-07 7:37 ` G, Manjunath Kondaiah
-- strict thread matches above, loose matches on Subject: below --
2011-10-07 5:05 G, Manjunath Kondaiah
2011-10-07 5:05 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism G, Manjunath Kondaiah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E9885CF.1000301@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=Manjunath@jasper.es \
--cc=awarkentin@vmware.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dilee@nvidia.com \
--cc=grant.likely@secretlab.ca \
--cc=greg@kroah.com \
--cc=josh@joshtriplett.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=manjugk@ti.com \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--cc=tom.leiming@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).