All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [PATCH] of: support an enumerated-bus compatible value
Date: Mon, 02 Jul 2012 09:59:35 -0600	[thread overview]
Message-ID: <4FF1C567.4060809@wwwdotorg.org> (raw)
In-Reply-To: <4FF0A6B6.8040902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 07/01/2012 01:36 PM, Rob Herring wrote:
> On 06/28/2012 06:05 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> An "enumerated" bus is one that is not memory-mapped, hence hence
>> typically has #address-cells=1, and #size-cells=0. Such buses would be
>> used to group related non-memory-mapped nodes together, often just under
>> the top-level of the device tree. The ability to group nodes into a non-
>> memory-mapped subnode of the root is important, since if nodes exist to
>> describe multiple entities of the same type, the nodes will have the
>> same name, and hence require a unit address to differentiate them. It
>> doesn't make sense to assign bogus unit addresses from the CPU's own
>> address space for this purpose. An example:
>>
>> 	regulators {
>> 		compatible = "enumerated-bus";
>> 		#address-cells = <1>;
>> 		#size-cells = <0>;
>>
>> 		regulator@0 {
>> 			compatible = "regulator-fixed";
>> 			reg = <0>;
>> 		};
>>
>> 		regulator@1 {
>> 			compatible = "regulator-fixed";
>> 			reg = <1>;
>> 		};
>> 	};
>>
>> Finally, because such buses are not memory-mapped, we avoid creating
>> any IO/memory resources for the device.
> 
> This seems like a work-around to use reg instead of using cell-index
> (which is discouraged). reg in this case is really not a hardware
> description. Do you have an intended use or just trying to fix the error
> messages?

I'm not familiar with cell-index; can you please describe it some more.
Looking at some existing files in arch/powerpc/boot/dts, it looks like
something that exists alongside reg rather than replacing it, so I don't
see how it'd solve the problem.

The portion of .dts file quoted above is the use-case. In more general
terms, I need to add a bunch of non-memory-mapped devices to DT. There
are multiple devices of a given type. The DT node names should be named
after the class of device not the instance, and hence all get named the
same. Hence, I need a unit address to differentiate the node names.
Hence I need to use the reg property in order that the unit address
matches the reg property. Is there some other way of solving these
requirements other than using a unit address to make the node names unique?

On 07/01/2012 04:03 PM, Grant Likely wrote:
...
> Besides; if they are enumerated, non-memory mapped devices, then is it
> really appropriate to use platform_{device,driver}? I don't think it
> is.

Hmm, well /everything/ that gets instantiated from DT is a platform
device at present, at least for the platforms and bus types we're using
on Tegra and I believe all/most ARM platforms, except some small amounts
of AMBA. Changing that would hugely impact a ton of working code and
just be churn in my opinion. Do we really want to invent another device
type internal to Linux for this? Besides, doing that would be orthogonal
to this patch; such a change would have no impact on the DT
representation of the devices.

  parent reply	other threads:[~2012-07-02 15:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 23:05 [PATCH] of: support an enumerated-bus compatible value Stephen Warren
     [not found] ` <1340924755-31447-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-01 19:36   ` Rob Herring
     [not found]     ` <4FF0A6B6.8040902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-01 22:03       ` Grant Likely
2012-07-02 15:59       ` Stephen Warren [this message]
     [not found]         ` <4FF1C567.4060809-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-02 17:23           ` Mitch Bradley
     [not found]             ` <4FF1D8F9.9040005-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-02 17:43               ` Stephen Warren
     [not found]                 ` <4FF1DDBD.9050106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-02 18:36                   ` Mitch Bradley
     [not found]                     ` <4FF1EA1A.9030307-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-02 19:41                       ` Stephen Warren
     [not found]                         ` <4FF1F955.6030204-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-02 21:44                           ` Segher Boessenkool
     [not found]                             ` <6BC22F77-77D7-45DF-821A-6CA2DBADEA59-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2012-07-02 22:26                               ` Stephen Warren
     [not found]                                 ` <4FF22031.3060206-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-03  0:27                                   ` Segher Boessenkool
     [not found]                                     ` <FE3C6687-727E-4191-9D37-9E71EBFEF0AE-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2012-07-03 10:47                                       ` Mark Brown
     [not found]                                         ` <20120703104720.GB25995-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2012-07-03 14:00                                           ` Segher Boessenkool
     [not found]                                             ` <F928AF0B-65CF-48D1-8DB5-4C27FD6AB82F-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2012-07-03 14:42                                               ` Mark Brown
     [not found]                                                 ` <20120703144242.GE25995-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2012-07-03 15:43                                                   ` Segher Boessenkool
     [not found]                                                     ` <DF4AD962-D8A8-43AA-AF14-5DBF65505EDF-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2012-07-03 15:45                                                       ` Stephen Warren
     [not found]                                                         ` <4FF3138F.9090800-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-03 19:02                                                           ` Mitch Bradley
     [not found]                                                             ` <4FF341B0.9090901-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-07-03 19:57                                                               ` Stephen Warren
     [not found]                                                                 ` <4FF34EC2.6040908-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-24 17:38                                                                   ` Stephen Warren
     [not found]                                                                     ` <500EDD8A.2010701-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-24 18:48                                                                       ` Arnd Bergmann
     [not found]                                                                         ` <201207241848.53308.arnd-r2nGTMty4D4@public.gmane.org>
2012-07-24 19:30                                                                           ` Stephen Warren
     [not found]                                                                             ` <500EF7C5.6060406-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-24 20:05                                                                               ` Arnd Bergmann
2012-07-03 15:43                                               ` Stephen Warren
2012-07-02 21:45                           ` Grant Likely
2012-07-02 21:43           ` Grant Likely
     [not found]             ` <CACxGe6ty5wU6Y+fuFYfBsM4HRLZaTff9EnzCP2FzmcQGOyJ=xQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-02 22:28               ` Stephen Warren
     [not found]                 ` <4FF22095.4030106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-02 22:37                   ` Grant Likely
     [not found]                     ` <CACxGe6sexKHa65=EsLpTa9-JrSK-Ubbhz6MAmfGeSen9cHJhow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-02 23:17                       ` Stephen Warren

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=4FF1C567.4060809@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@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.