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

[Mitch Bradley]

On 7/2/2012 7:43 AM, Stephen Warren wrote:
> On 07/02/2012 11:23 AM, Mitch Bradley wrote:
>> On 7/2/2012 5:59 AM, Stephen Warren wrote:
>>> On 07/01/2012 01:36 PM, Rob Herring wrote:
>>>> On 06/28/2012 06:05 PM, Stephen Warren wrote:
>>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>>
>>>>> 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 at 0 {
>>>>>              compatible = "regulator-fixed";
>>>>>              reg = <0>;
>>>>>          };
>>>>>
>>>>>          regulator at 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?
>>
>> One of Rob's objections was that, in this case, the reg property is not
>> a hardware description.  That's an interesting point.  If in fact
>> numerous such devices exist, there must be some mechanism for software
>> to choose which device to talk to, typically a number.  Is that the case
>> for these devices?  If so, that number is a perfectly valid "reg"
>> property value.  If not, how does software choose to talk to a specific
>> device?
>
> Yes, the reg value is purely a unique ID that exists to satisfy DT
> semantics.
>
> These regulators will eventually be referenced by phandles from the
> drivers that use them, just like interrupts/GPIOs/... I just haven't
> hooked up any clients that do so yet.

I'm still confused.  Are you saying that the regulators cannot be 
controlled by software?

Personally, I don't have a problem with "inventing" unique IDs and using 
the reg property to convey them.  I'm just wondering about how this 
system works.

>