On 03/01/2013 02:47 PM, Mitch Bradley wrote:
> On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:
>> Hi,
>>
>> On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
>> <gerlando.falauto@xxxxxxxxxxx> wrote:
>>> Hi everyone,
>>>
>>> I have a similar question.
>>> I'd like to "name" i2c devices so that a userspace application can somehow
>>> identify those devices with the same function across different boards (which
>>> may have different addresses or be connected to a different i2c bus, or be a
>>> physically different chip).
>>>
>>> For instance "hwmon" devices get instantiated within sysfs under
>>> /sys/class/hwmon/hwmonX
>>>
>>> # cat /sys/class/hwmon/hwmon0/device/name
>>> lm75
>>>
>>> which I would like to be identified by the name "switch" (as in "switch
>>> temperature"). I was thinking about instantiating it as something like
>>> "lm75:switch" within i2c_board_info.type. For device-tree-less
>>> architectures, a trivial change within i2c_match_id() so to ignore the part
>>> following ":" seems to do the trick. Don't know about devicetree but I guess
>>> a similar approach could be imagined.
>>>
>>> Another example would be given by EEPROMs: all boards are equipped with an
>>> EEPROM containing inventory management, which I would like to identify as
>>> "ivm". So something like "24c08:ivm".
>>> After all, I'd like to be able to achive something like "named MTD
>>> partitions" which you can identify by looking at "/proc/mtd".
>>>
>>> Maybe some other symbol could be used instead of ":", but anyhow, does the
>>> above make any sense at all to you?
>>>
>>
>> I have exactly the same request: I would like to put logical names in
>> the device tree for various devices (i2c, spi, ...) which are in some
>> way easily retrievable from a userspace application.
>> The purpose seems to be the same as Gerlando's: different boards have
>> different physical configuration but logically each has the same set
>> of devices.
>>
>> How can one achieve that?
>
> Unless I am misunderstanding your request, that is what the /aliases
> node is intended for. Each property name in /aliases is a logical name,
> and the value refers to the corresponding device node.
>
> I'm not sure about all the different ways that Linux exports information
> in /aliases to userspace. I do know that, in the case of some i2c,
> serial, and ethernet devices, aliases like:
>
> serial1 = &uart1;
>
> cause the assignment of small-integer unit numbers to specific device
> instances. That "serial<N>" pattern is somewhat of a Linux-specific
> special case. In general, the Open Firmware standard just says that
> /aliases maps logical names to longer strings representing fuller
> pathnames, without imposing any structure (e.g. serial<N>) on the
> logical names.
I'm not sure if aliases solve all scenarios.
If you have a DT node that's a single UART, then aliases work OK, as in
your example above.
However, what if you have a single thermal sensor ID that has 4
channels. There will be a single DT node that represents this device.
However, the 4 channels could be hooked up arbitrarily on a board, and
you really want to name the individual channels, not just the IC that
contains those channels. Can you do that; will the following work?
/aliases {
cpu-temp = <&i2cdev 1>; # 1 is the channel ID on the chip
ambient-temp = <&i2cdev 3>;
};
All the code I recall so far that handles aliases searches for alias
entries with a specific prefix for the name (e.g. "i2c*", and then finds
"i2c0", "i2c1", etc.). In order to support the syntax above, you'd have
to instead search for all aliases that include the phandle of the node
in question. I guess it's easy enough to implement that, but it's quite
a different way of thinking about aliases, I think.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
