From: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: devicetree-discuss
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: #size-cells = <0> in a bus node, and kernel messages complaining about this
Date: Thu, 28 Jun 2012 08:49:19 -1000 [thread overview]
Message-ID: <4FECA72F.9080601@firmworks.com> (raw)
In-Reply-To: <4FECA092.60307-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
On 6/28/2012 8:21 AM, Mitch Bradley wrote:
> On 6/28/2012 7:50 AM, Stephen Warren wrote:
>> On 06/27/2012 06:57 PM, Mitch Bradley wrote:
>>> On 6/27/2012 11:26 AM, Stephen Warren wrote:
>>>> I believe I've seen the following construct bandied about as the
>>>> correct
>>>> way of representing a bunch of nodes that have the same name (since
>>>> they
>>>> represent the same type of object) within device-tree.
>>>>
>>>> regulators {
>>>> compatible = "simple-bus";
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>>
>>>> regulator@0 {
>>>> compatible = "regulator-fixed";
>>>> reg = <0>;
>>>> ...
>>>> };
>>>>
>>>> regulator@1 {
>>>> compatible = "regulator-fixed";
>>>> reg = <1>;
>>>> ...
>>>> };
>>>> };
>>>>
>>>> However, when the kernel parses that, it issues messages such as:
>>>>
>>>> prom_parse: Bad cell count for /regulators/regulator@0
>>>> prom_parse: Bad cell count for /regulators/regulator@1
>>>
>>> The message comes from __of_translate_address(), which has the comment:
>>>
>>> * Note: We consider that crossing any level with #size-cells == 0
>>> to mean
>>> * that translation is impossible (that is we are not dealing with a
>>> value
>>> * that can be mapped to a cpu physical address). This is not really
>>> specified
>>> * that way, but this is traditionally the way IBM at least do things
>>>
>>> So it seems that the problem only occurs if something tries to translate
>>> the regulator's "reg" address to a CPU address. Is that
>>> possible/meaningful
>>> in your case?
>>
>> That's quite likely.
>>
>> Note that the regulators node is compatible = "simple-bus", and I'm
>> doing that so that the child regulator nodes are automatically recursed
>> into, and a platform device created for each. Part of creating those
>> platform devices is to convert the reg and interrupts properties to
>> platform device resources, which is almost certainly what's calling
>> __of_translate_address(). This is a compatibility thing on ARM; I guess
>> pure OF-style drivers call something like of_get_address()/of_iomap()
>> themselves in their probe() function if appropriate, rather than relying
>> on calling platform_get_resource(), and hence forcing the DT parsing
>> code to convert resources beforehand in all cases, even if not used.
>>
>> Perhaps simple-bus could be enhanced to detect when size-cells==0 and
>> know that this means the bus is really just a container/grouping of
>> non-addressed objects, and hence not provide the memory resources. Or,
>> perhaps we should introduce a new compatible value that only triggers
>> child instantiation but not resource setup, or something like that?
>
> ISTM that if you want different semantics, a different compatible value
> is the best approach. My mental model is that "simple-bus" has
> memory-mapped children. Perhaps something like "enumerated-bus" for
> non-memory-mapped ?
I just looked at the code in platform.c that calls
of_translate_address() (in of_device_make_bus_id()). It appears that
the reason for translating the address is to create a unique device name
via:
dev_set_name(dev, "%llx.%s", addr, node->name);
Failure of_translate_address() is not treated as an error, rather the
code falls back to naming the device with an incrementing number:
dev_set_name(dev, "%s.%d", node->name, magic - 1);
Perhaps the solution is add an additional step to the heuristic. If
of_translate_address() fails, try to use the untranslated reg property
value to make the name unique, generating a name like:
name.N,M
where N,M is a list of #address-cells numbers from the first entry of
the reg property value.
That would be better than the existing heuristic (which includes the
phrase "(and pray ...)" in its commentary), and fully consistent with
device tree dogma.
One could still add a new compatible value to distinguish that from a
"simple-bus", as platform.c has a match table that includes simple-bus
and others. The heuristic for making the unique name is not contingent
upon a specific bus name.
>
>>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
next prev parent reply other threads:[~2012-06-28 18:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 21:26 #size-cells = <0> in a bus node, and kernel messages complaining about this Stephen Warren
[not found] ` <4FEB7A8E.1090409-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 0:57 ` Mitch Bradley
[not found] ` <4FEBABE0.2050503-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 17:50 ` Stephen Warren
[not found] ` <4FEC994A.4030507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 18:21 ` Mitch Bradley
[not found] ` <4FECA092.60307-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 18:49 ` Mitch Bradley [this message]
[not found] ` <4FECA72F.9080601-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 20:28 ` Mitch Bradley
[not found] ` <4FECBE5B.1090300-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 20:51 ` Stephen Warren
[not found] ` <4FECC3D5.2030507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 20:58 ` Mitch Bradley
[not found] ` <4FECC569.1000108-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-28 22:02 ` Stephen Warren
[not found] ` <4FECD461.9030802-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 22:22 ` Mitch Bradley
2012-06-29 2:38 ` David Gibson
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=4FECA72F.9080601@firmworks.com \
--to=wmb-d5eqfidgl7eakbo8gow8eq@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.