#size-cells = <0> in a bus node, and kernel messages complaining about this

[Mitch Bradley]

On 6/28/2012 12:02 PM, Stephen Warren wrote:
> On 06/28/2012 02:58 PM, Mitch Bradley wrote:
>> On 6/28/2012 10:51 AM, Stephen Warren wrote:
>>> On 06/28/2012 02:28 PM, Mitch Bradley wrote:
> ...
>>>> Hmmm....

>
> Ah yes.
>
> I'd somewhat prefer to avoid calling of_translate_address() when we
> know it's going to fail though, by passing a parameter to
> of_device_make_bus_id() indicating whether to use that or
> of_get_address(). The parameter would be set based on enumerated-bus vs.
> any other bus type. I coded that locally and it seems to work OK. That
> way, the diagnostic in of_translate_address() can be left unchanged; it
> seems like it really is an error.

Win.

> ...

>>> Do we need to include the full DT path to an enumerated device, or some
>>> other unique data for the node's bus, in the device name of a child of
>>> an enumerated bus?
>>
>> I don't know.  Is the device name space flat?
>
> Hmmm. It depends on where you look.
>
> I end up with /sys/devices/regulators.3/[01].regulator/ this way, the
> path structure of which is defined by the parent/child device
> relationship, and implies that device names are relative to their parent.
>
> However, device names are treated as a flat namespace in many other
> places. For example, clocks, regulators, pinctrl settings, etc. are
> looked up by device name, and the names in the lookup tables are just
> the device name itself, with no reference to the device's parent.

The world in general seems to manage just fine with namespaces that are 
sometimes fully-qualified but more often at least partially ambiguous. 
Personally, I find that scrupulous avoidance of ambiguity - with dotted 
namespaces or hashes - ends up being hard for humans (or at least this 
human) to deal with.  So maybe it's okay if we don't fully address this 
problem.