linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 2/2] dt: add custom device creation to platform bus scan
Date: Wed, 1 Jun 2011 10:58:03 -0600	[thread overview]
Message-ID: <BANLkTimTdVKspjJ8GD4M90wiKCC0SzkgpA@mail.gmail.com> (raw)
In-Reply-To: <4DE66E39.2070300@gmail.com>

On Wed, Jun 1, 2011 at 10:52 AM, Rob Herring <robherring2@gmail.com> wrote:
> 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.

AMBA and platform_devices are "special" in that they don't have
requirements on their parent device.  I see absolutely zero issue with
having platform_device and amba_device as siblings.

g.

  reply	other threads:[~2011-06-01 16:58 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
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
2011-05-26 13:11   ` Arnd Bergmann
2011-05-26 18:43     ` Rob Herring
2011-05-27 12:06       ` Arnd Bergmann
2011-06-01 16:52         ` Rob Herring
2011-06-01 16:58           ` Grant Likely [this message]
2011-06-01 21:29             ` Arnd Bergmann
2011-06-08  3:12               ` Rob Herring
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=BANLkTimTdVKspjJ8GD4M90wiKCC0SzkgpA@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --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).