From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC PATCH v3 2/2] dt: add custom device creation to platform bus scan
Date: Wed, 01 Jun 2011 11:52:09 -0500 [thread overview]
Message-ID: <4DE66E39.2070300@gmail.com> (raw)
In-Reply-To: <201105271406.18841.arnd-r2nGTMty4D4@public.gmane.org>
On 05/27/2011 07:06 AM, Arnd Bergmann wrote:
> On Thursday 26 May 2011, Rob Herring wrote:
>> On 05/26/2011 08:11 AM, Arnd Bergmann wrote:
>>> On Wednesday 25 May 2011, Rob Herring wrote:
>>> This creates a confusing mix of match table entries: Normally,
>>> all entries in the match table are meant to identify child buses,
>>> but if I read your patch correctly, you now also need to match
>>> on the amba devices themselves, including the creation of
>>> platform devices for each child device node under an amba
>>> device.
>>>
>> We should only create devices for each matching bus and the immediate
>> children of each bus. A child device of an amba device would be
>> something like an i2c bus which we don't want to create devices for. Or
>> am I missing something?
>
> Exactly, that was my point.
>
>>> I don't think that was the intention. Maybe we need to pass
>>> two match tables into of_platform_bus_probe() instead:
>>> one to identify the buses, and another one that is used
>>> to create the actual devices.
>>>
>> That was my original thinking too, but some reason I had concluded 1
>> could get by with just 1 table. After more thought, I think you are
>> right. In fact, I broke platform device creation with this patch. I need
>> to be able to tell if no match means create a platform device (child of
>> bus) or not (child of a device).
>
> Ok.
>
>> @@ -234,18 +237,32 @@ static int of_platform_bus_create(struct
>> device_node *bus,
>> return 0;
>> }
>>
>> - dev = of_platform_device_create(bus, NULL, parent);
>> - if (!dev || !of_match_node(matches, bus))
>> - return 0;
>> -
>> - for_each_child_of_node(bus, child) {
>> - pr_debug(" create child: %s\n", child->full_name);
>> - rc = of_platform_bus_create(child, matches,&dev->dev, strict);
>> - if (rc) {
>> - of_node_put(child);
>> - break;
>> + id = of_match_node(bus_matches, bus);
>> + if (id) {
>> + dev = of_platform_device_create(bus, NULL, parent);
>> + if (!dev)
>> + return 0;
>> + for_each_child_of_node(bus, child) {
>> + pr_debug(" create child: %s\n", child->full_name);
>> + rc = of_platform_bus_create(child, bus_matches,
>> + dev_matches, dev, strict);
>> + if (rc) {
>> + of_node_put(child);
>> + break;
>> + }
>> }
>> + return rc;
>> }
>> +
>> + id = of_match_node(dev_matches, bus);
>> + mdata = id ? id->data : NULL;
>> + if (id&& mdata&& mdata->dev_create)
>> + dev = mdata->dev_create(bus, parent);
>> + else
>> + dev = of_platform_device_create(bus, NULL, parent);
>> + if (!dev)
>> + return 0;
>> +
>
> Yes, that looks like it should work.
>
> It still feels a bit strange, because it's not exactly how we normally
> probe devices: In all other cases, we bind a device to a driver when we
> find it, and that driver in turn scans it, and potentially creates
> child devices that it finds.
>
> What we do here is to let the platform decide how to interpret the
> data that is coming in. To make the probing more well-behaved, another
> approach would be:
>
> * Bind a platform_driver to compatible="arm,amba" (or whatever we
> had in the binding).
>
> * In that driver, do nothing except register an amba_device as a child.
>
> This would create a somewhat deeper device hierarchy, but be still
> completely logical: you have a device that cannot be probed (identified
> simply by its register space), which can be probed internally because
> the registers actually have a meaning.
Shouldn't the hierarchy in linux reflect the h/w? It seems a bit
pointless to me to create a device just to create another device.
amba_bus is already a bit strange in that it is not really a bus type,
but a certain class of peripherals.
I'd like to hear Grant's thoughts on this.
Rob
next prev parent reply other threads:[~2011-06-01 16:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 21:31 [RFC PATCH v3 0/2] amba bus device tree probing Rob Herring
[not found] ` <1306359073-16274-1-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-05-25 21:31 ` [RFC PATCH v3 1/2] drivers/amba: create devices from device tree Rob Herring
2011-05-26 7:41 ` Linus Walleij
2011-05-25 21:31 ` [RFC PATCH v3 2/2] dt: add custom device creation to platform bus scan Rob Herring
[not found] ` <1306359073-16274-3-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-05-26 13:11 ` Arnd Bergmann
[not found] ` <201105261511.23659.arnd-r2nGTMty4D4@public.gmane.org>
2011-05-26 18:43 ` Rob Herring
[not found] ` <4DDE9F4A.5050507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-05-27 12:06 ` Arnd Bergmann
[not found] ` <201105271406.18841.arnd-r2nGTMty4D4@public.gmane.org>
2011-06-01 16:52 ` Rob Herring [this message]
[not found] ` <4DE66E39.2070300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-06-01 16:58 ` Grant Likely
[not found] ` <BANLkTimTdVKspjJ8GD4M90wiKCC0SzkgpA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-01 21:29 ` Arnd Bergmann
[not found] ` <201106012329.20651.arnd-r2nGTMty4D4@public.gmane.org>
2011-06-08 3:12 ` Rob Herring
[not found] ` <4DEEE8AF.50603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-06-08 6:16 ` Arnd Bergmann
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=4DE66E39.2070300@gmail.com \
--to=robherring2-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.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).