All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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 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.