Thread (1 message) 1 message, 1 author, 2012-07-01

Re: [PATCH] of: support an enumerated-bus compatible value

From: Grant Likely <hidden>
Date: 2012-07-01 22:03:01

On Sun, Jul 1, 2012 at 1:36 PM, Rob Herring [off-list ref] wrote:
On 06/28/2012 06:05 PM, Stephen Warren wrote:
quoted
From: Stephen Warren <redacted>

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

g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help