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

[Stephen Warren]

On 07/03/2012 01:02 PM, Mitch Bradley wrote:
> On 7/3/2012 5:45 AM, Stephen Warren wrote:
>> On 07/03/2012 09:43 AM, Segher Boessenkool wrote:
>>>>> There is still no reason for the fake bus node to have a "compatible"
>>>>> property though.  What could it possibly mean?  "This bus does not
>>>>> exist at all but you access it in bla bla bla way"?  That just doesn't
>>>>> make sense.  It doesn't exist, you do not access it, it has no
>>>>> programming model, it has no "compatible" property.
>>>>
>>>> Well, as everyone keeps saying this seems to be a limitation of the
>>>> current device tree rather than something that's actually sensible in
>>>> and of itself.
>>>
>>> But that is my point: it is *not* a limitation of the device tree,
>>> the device tree can describe the hardware just fine without doing
>>> some weird "compatible" property.  The limitation is in the current
>>> Linux kernel code; _it_ should be fixed, don't add decorations to
>>> the device tree to work around shortcomings in a single OS.  The
>>> device tree describes the structure of the hardware, not the structure
>>> of the device model in the OS.
>>
>> No, it's definitely a DT limitation.
>>
>> DT assume that everything is addressable and hence you have to structure
>> it as buses where all the nodes have children with addresses. That's
>> what the proposed DT binding is doing.
>>
>> Note that addressability (there's some integer value, or list of integer
>> values, that identifies a device) is entirely different from usability
>> (the node exists and the driver for which can provide services to the
>> drivers for other nodes). I think that point has been lost in the last
>> few messages in this sub-thread.
> 
> 
> Whether this is a device tree limitation or a usage issue is a semantic
> quibble.
> 
> The underlying reality is that the device tree is a hierarchical
> namespace (hence the "tree").  It has a set of rules that are
> straightforward for hardware whose addressing is fundamentally
> hierarchical.
> 
> Much hardware fits nicely in such a model; some does not.  It's possible
> to coerce "problem" hardware into the hierarchy, in the same way that
> it's possible to "mount" remote filesystems into a filesystem tree.  The
> problem is not that the tree structure doesn't support such "out of
> tree" usage, but rather that there is no one obviously-best way to do
> it.  Hence the discussion/argument that is going on here.
> 
> When designing the device tree, it was never my intent that the "reg"
> property absolutely had to describe the hardware exactly.  Rather, it
> was a "best practices" policy that happens to work well in a
> surprisingly-large set of cases.  The key observation is that, since the
> hardware "always" has some physical way of distinguishing between two
> devices (which is necessary in order to use the device), you might as
> well use some representation of that token as the unique address, in
> preference to an arbitrarily-assigned number.
> 
> I think that's a good rule that should be followed in most cases, but
> there can be situations where the hardware is just too weird, in which
> case "inventing" a number space is okay by me. I would hope, however,
> that the number space is tied to some external "reality", such as a data
> sheet or other system documentation.
> 
> Now, let's consider the specific example of these "regulator" things. It
> seems that they are accessed via a motley collection of GPIOs.  So one
> way to address them "physically" is to make the regulator node a child
> of a gpio.  Pick a specific gpio, for example the one connected to the
> device's "clk" input, and make the regulator node a child of the gpio
> pin node.  Then the regulator doesn't need a "reg" property because
> there is only one regulator under a given GPIO pin node.

That won't work.

* There's no reason to believe in general that any GPIO-based regulator
must by definition only be controlled by a single GPIO. One could easily
imagine a regulator that supported 4 voltage levels using 2 GPIOs where
the 2 GPIOs were hosted by completely different GPIO controllers. Which
one of the two controllers would be the parent to host the regulator then?

* If the regulator ends up being a child of the GPIO itself, then the
regulator node will still need a gpios=<>; property pointing back at the
parent GPIO controller, so that kind of representation seems rather
redundant.

* Why should every GPIO binding and every GPIO driver be burdened with
supporting regulator nodes (and rfkill nodes and mute switch nodes and
power button nodes and ... ...) as children of themselves? It's far
simpler and a more direct representation of HW to just create a
regulator node, and stash it in some unaddressed top-level node.

Overall, I fail to see any benefit at all from requiring some form of
addressability to the regulator nodes; nothing ever needs to address
them. Acquiring services from the nodes is a completely unrelated matter
to addressing the node.