From: ddaney.cavm@gmail.com (David Daney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
Date: Fri, 14 Oct 2011 12:09:00 -0700 [thread overview]
Message-ID: <4E9888CC.4060104@gmail.com> (raw)
In-Reply-To: <CACxGe6v=NuxX3b=7wG6hMZjO22_zEg3Q4LtjT3UPtv2bKFtjWQ@mail.gmail.com>
On 10/14/2011 12:03 PM, Grant Likely wrote:
> On Fri, Oct 14, 2011 at 12:56 PM, David Daney<ddaney.cavm@gmail.com> wrote:
>> 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'
>
> 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
next prev parent reply other threads:[~2011-10-14 19:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1317963790-29426-1-git-send-email-manjugk@ti.com>
[not found] ` <1317963790-29426-2-git-send-email-manjugk@ti.com>
2011-10-07 6:43 ` [PATCH 1/5] drivercore: add new error value for deferred probe Greg KH
2011-10-07 10:00 ` Mark Brown
2011-10-07 22:12 ` Grant Likely
2011-10-07 23:28 ` Valdis.Kletnieks at vt.edu
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
[not found] ` <1317963790-29426-3-git-send-email-manjugk@ti.com>
2011-10-07 6:49 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism 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
2011-10-14 19:03 ` Grant Likely
2011-10-14 19:09 ` David Daney [this message]
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 6:50 ` [PATCH 0/5] Driver Probe Deferral Mechanism Greg KH
2011-10-07 7:37 ` G, Manjunath Kondaiah
[not found] ` <1317963790-29426-5-git-send-email-manjugk@ti.com>
2011-10-07 10:06 ` [PATCH 4/5] gpiolib: handle deferral probe error Alan Cox
2011-10-07 22:09 ` Grant Likely
2011-10-12 6:14 ` G, Manjunath Kondaiah
2011-10-13 4:12 ` Grant Likely
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=4E9888CC.4060104@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).