All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 27 Jun 2012 14:57:04 -1000	[thread overview]
Message-ID: <4FEBABE0.2050503@firmworks.com> (raw)
In-Reply-To: <4FEB7A8E.1090409-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

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?

I ran into a problem like this recently.  If I recall correctly, the root cause 
was that some code that I "inherited" was using of_address_to_resource() to 
process a "reg" property in a case where the "reg" was not memory-mappable.
I changed the code to use "of_get_address()" instead.

of_address_to_resource() calls of_get_address(), and then proceeds to convert 
the bus-relative address to a CPU address.

>
> The message is issued when #size-cells==0. Is the response simply "don't
> do that", and so I should set #size-cells=1, and add a fake size cell in
> the reg property too?
>
> Given the number of hits on '#size-cells = <0>' in the kernel source
> tree, it seems like I must be missing something here; it's quite widely
> used. I guess the warning is probably only emitted when the node with
> #size-cells=0 is a bus, and so the children are enumerated to
> instantiated devices; perhaps that's why this hasn't been raised before?
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

  parent reply	other threads:[~2012-06-28  0:57 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 [this message]
     [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
     [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=4FEBABE0.2050503@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.