Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub

[Segher Boessenkool <segher@kernel.crashing.org>]

>> For some buses, there is a "slot-names" property; some (non-core)
>> bindings seem to define a "location" property.
>> For "random" human-readable labelling, i.e. not corresponding to
>> physical markings on the hardware, I recommend you look for a
>> matching entry in /aliases.
>
> Aliases could work, but are awkward to use for the purposes I'm 
> thinking of (giving the OS a name to present to the user in 
> association with a device).

Sure; it's just one thing a platform driver could use.

> Plus, you're then restricted to valid property names for the alias, 
> whereas with a label property you could use any string, including 
> spaces and such.

Spaces in a device name are a bad idea anyway ;-)

>>  It won't ever be _exactly_ what you
>> want though, the Linux device namespace is separate from the
>> device tree.
>
> That's Linux's choice.  Nothing stops it from showing device tree 
> labels  to the user in various situations -- what got me thinking 
> about this was that apparently ALSA lets the driver pass an arbitrary 
> string to identify the device, and it seemed that such a 
> device-tree-derived label would be the most useful to the user.

Yeah.  The platform code has the final responsibility for those
names, it can use whatever mechanism is appropriate for that
platform.

> To use aliases for that, it'd have to get the full path to the audio 
> node, compare it to each alias, and hope it finds one and only one,

This would of course be split off into a nice prom.c utility
function, so it isn't much code, just a function call.

> and that that alias was intended to be a user label and not something 
> else.

Hey at least they're all printable :-)


Segher