Re: I2C and devicetrees

On 3/1/2013 1:17 PM, Stephen Warren wrote:

On 03/01/2013 02:47 PM, Mitch Bradley wrote:

quoted

On 3/1/2013 9:56 AM, Thomas De Schampheleire wrote:

quoted

Hi,

On Tue, Feb 12, 2013 at 5:34 PM, Gerlando Falauto
[off-list ref] wrote:

quoted

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>;
};

For that case, I would put child nodes underneath the 4-channel-sensor
node, e.g. cpu-temp@1, ambient-temp@3.  Those multiple channels fit
cleanly within the device tree's "child address space" concept.

I suppose that the driver for the sensor node would enumerate its
children and export their information via /sys.

I know that it's tempting to truncate the device tree too soon, as I
have fallen prey to that temptation many times.  For me, the temptation
usually happens for "endpoints" that don't need separate drivers, or for
which the endpoint-driver code is "buried" inside the parent driver.
But in the end, it has usually worked out better to fill out the leaves
of the tree, especially for on-board devices.

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.