On 6/28/2012 12:02 PM, Stephen Warren wrote:

On 06/28/2012 02:58 PM, Mitch Bradley wrote:

quoted

On 6/28/2012 10:51 AM, Stephen Warren wrote:

quoted

On 06/28/2012 02:28 PM, Mitch Bradley wrote:

...

quoted

quoted

quoted

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.

...

quoted

quoted

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.