From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@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 11:50:02 -0600 [thread overview]
Message-ID: <4FEC994A.4030507@wwwdotorg.org> (raw)
In-Reply-To: <4FEBABE0.2050503-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
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?
next prev parent reply other threads:[~2012-06-28 17:50 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 [this message]
[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
[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=4FEC994A.4030507@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=wmb-D5eQfiDGL7eakBO8gow8eQ@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).