I2C and devicetrees

Hi,

I have a short question about the relations between i2c and devicetrees.

I was wondering
is the device part of the compatible string of a (trivial) i2c device instanciated via devicetree _always_ identical to name in i2c_client.name ? Or can it be somehow different?

Here's a short example:
device tree:

test {
        compatible = "vendor,device1", "vendor,device2";
        reg = <0x20>;
}

The driver has in its id table only this entry:

static const struct i2c_device_id my_i2c_table[] = {
        {"device2", 0},
        {},
};

-> "vendor,device2" matches and the driver is called. --> Is i2c_client.name guaranteed to be "device2" ?

Second question:
Where would you probably add an i2c tpm?
Would you add it to
Documentation/devicetree/bindings/i2c/trivial-devices.txt
or if it's not trivial add it to a new file under
Documentation/devicetree/bindings/i2c/

or create a new folder
Documentation/devicetree/bindings/tpm
as there probably are more i2c tpms to come in the near future.

I'd probably prefer the first one, whereas Google already uses the second option:
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=history;f=Documentation/devicetree/bindings/tpm;hb=refs/heads/chromeos-3.4

[+devicetree-discuss]

Quoted 8 lines · Peter Huewe

Hi,

I have a short question about the relations between i2c and devicetrees.

I was wondering
is the device part of the compatible string of a (trivial) i2c device instanciated via devicetree _always_ identical to name in i2c_client.name ? Or can it be somehow different?

It can be different, but the driver will then need to add a OF table that matches the probing. By default the i2c/dt core code will strip off the vendor prefix (before ",") and try probing with the rest of the device name. If that doesn't match the client name, that is when you need the additional table.

Quoted 12 lines · Olof Johansson

[+devicetree-discuss]

Quoted 8 lines · Peter Huewe

Hi,

I have a short question about the relations between i2c and devicetrees.

I was wondering
is the device part of the compatible string of a (trivial) i2c device instanciated via devicetree _always_ identical to name in i2c_client.name ? Or can it be somehow different?

Quoted 5 lines

It can be different, but the driver will then need to add a OF table that matches the probing. By default the i2c/dt core code will strip off the vendor prefix (before ",") and try probing with the rest of the device name. If that doesn't match the client name, that is when you need the additional table.

While relying on the prefix stripping works, I think I recall Grant mentioning that people shouldn't rely on it - namely that any I2C device that gets instantiated from DT should contain the OF match table explicitly. I CC'd Grant in case I'm mis-quoting him.

Quoted 19 lines · Stephen Warren

Quoted 12 lines · Olof Johansson

[+devicetree-discuss]

Quoted 8 lines · Peter Huewe

Hi,

I have a short question about the relations between i2c and devicetrees.

I was wondering
is the device part of the compatible string of a (trivial) i2c device instanciated via devicetree _always_ identical to name in i2c_client.name ? Or can it be somehow different?

Quoted 5 lines

It can be different, but the driver will then need to add a OF table that matches the probing. By default the i2c/dt core code will strip off the vendor prefix (before ",") and try probing with the rest of the device name. If that doesn't match the client name, that is when you need the additional table.

Quoted 4 lines

While relying on the prefix stripping works, I think I recall Grant mentioning that people shouldn't rely on it - namely that any I2C device that gets instantiated from DT should contain the OF match table explicitly. I CC'd Grant in case I'm mis-quoting him.

I'm not quite that strict about it. The behaviour described above is based merely on a heuristic but for a lot of drivers that don't do anything special it works just fine. The moment you need to identify a specific device it becomes better to use an of match table.

g.

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?

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?

Hi,

Quoted 21 lines · Gerlando Falauto

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.

Quoted 9 lines

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?

Thanks,
Thomas
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss

Quoted 35 lines · Thomas De Schampheleire

Hi,

Quoted 21 lines · Gerlando Falauto

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.

Quoted 9 lines

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?

Quoted 8 lines

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.

Quoted 53 lines · Mitch Bradley

Quoted 35 lines · Thomas De Schampheleire

Hi,

Quoted 21 lines · Gerlando Falauto

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.

Quoted 9 lines

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?

Quoted 8 lines

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:

Quoted 8 lines

  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.