IIO device indexing issue

IIO device indexing issue

[Vesa Jääskeläinen]

Hi,

When we were using kernel 3.2 and with that board files we just got IIO 
devices with static order so that we knew exactly what iio:device0 is.

Now with device tree that order is not so static anymore especially when 
using device overlays (have not yet tried that thou). If there would be 
deferred probe for the device then if we have multiple iio:device's then 
those could in theory be in any order.

In example libiio uses iio device index to open the IIO device. So the 
problem is to know what iio:device is what.

If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what 
device this is (especially if there are multiple device of same type). 
There does not seem to be a way to give custom name for the iio device 
from device tree that could have been used as a cue.

Device tree aliases kinda sounded a good idea to try. Eg. define adc0 
alias and then link it to actual device node in tree.

Aliases could be found under /proc/device-tree/aliases. Looking at it 
shows what device tree node it is. However there does not seem to be 
actual link from any /proc/device-tree entries to kernel drivers exposed 
under sysfs. And even the path components in device tree are not in same 
format as in sysfs. So there is no 1:1 mapping possible here.

IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual 
devices under /sys/devices and from there is physical path to the device 
and under that the IIO device with the same name as is under /sys/bus/iio.

So in theory we could make a mapping configuration file that specifies 
logical name for iio device and then physical parent path for the device 
and then find under it iio:device* files to determine what is the iio 
device index for this physical device. Then open IIO device with that 
index in example with libiio. Sounds a bit complex?

So did we miss something on how this should be defined/accessed or is 
there a slight issue here on how to identify iio devices?

Don't know how device tree overlays affect this if we first load device 
tree overlay with some configuration and then unload it and load another 
one with different configuration.

Thanks,
Vesa Jääskeläinen

Re: IIO device indexing issue

[Lars-Peter Clausen]

On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
> Hi,
> 
> When we were using kernel 3.2 and with that board files we just got IIO
> devices with static order so that we knew exactly what iio:device0 is.
> 
> Now with device tree that order is not so static anymore especially when
> using device overlays (have not yet tried that thou). If there would be
> deferred probe for the device then if we have multiple iio:device's then
> those could in theory be in any order.
> 
> In example libiio uses iio device index to open the IIO device. So the
> problem is to know what iio:device is what.
> 
> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what
> device this is (especially if there are multiple device of same type). There
> does not seem to be a way to give custom name for the iio device from device
> tree that could have been used as a cue.
> 
> Device tree aliases kinda sounded a good idea to try. Eg. define adc0 alias
> and then link it to actual device node in tree.
> 
> Aliases could be found under /proc/device-tree/aliases. Looking at it shows
> what device tree node it is. However there does not seem to be actual link
> from any /proc/device-tree entries to kernel drivers exposed under sysfs.
> And even the path components in device tree are not in same format as in
> sysfs. So there is no 1:1 mapping possible here.
> 
> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
> devices under /sys/devices and from there is physical path to the device and
> under that the IIO device with the same name as is under /sys/bus/iio.
> 
> So in theory we could make a mapping configuration file that specifies
> logical name for iio device and then physical parent path for the device and
> then find under it iio:device* files to determine what is the iio device
> index for this physical device. Then open IIO device with that index in
> example with libiio. Sounds a bit complex?
> 
> So did we miss something on how this should be defined/accessed or is there
> a slight issue here on how to identify iio devices?
> 
> Don't know how device tree overlays affect this if we first load device tree
> overlay with some configuration and then unload it and load another one with
> different configuration.

Hi,

Yes, excellent analysis. This is a real issue. As you said there is no
guarantee that the IIO device numbers are stable, they are assigned in the
order the devices are registered. If the device are registered in a
different order for whatever reason the numbers will change. You can use
readlink on the IIO device in /sys/bus/iio/devices to get its position in
the global device topology and be able to tell what the parent device is,
but this path might not be completely stable either though. E.g. if your
device is on a I2C bus and the number of the I2C bus is dynamically assigned
it might change when the probe order changes.

Alias seem to be one way to solve this issue. The big question remains is
how to communicate the alias to userspace. For other device classes the
alias index is used as the device index e.g. a device with alias i2c0 ends
up being the i2c adapter with index 0. But with IIO where we support a wide
range of different devices that does not really work. E.g. what to do if you
have adc0 and dac0 as aliases for different devices. So you'd need a
different way to expose the alias.

Some bindings also use the "label" property to assign a unique name to node.
But again the same issue how to expose that information to applications.

- Lars

Re: IIO device indexing issue

[Vesa Jääskeläinen]

On 04/11/15 11:38, Lars-Peter Clausen wrote:
> On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
>> Hi,
>>
>> When we were using kernel 3.2 and with that board files we just got IIO
>> devices with static order so that we knew exactly what iio:device0 is.
>>
>> Now with device tree that order is not so static anymore especially when
>> using device overlays (have not yet tried that thou). If there would be
>> deferred probe for the device then if we have multiple iio:device's then
>> those could in theory be in any order.
>>
>> In example libiio uses iio device index to open the IIO device. So the
>> problem is to know what iio:device is what.
>>
>> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what
>> device this is (especially if there are multiple device of same type). There
>> does not seem to be a way to give custom name for the iio device from device
>> tree that could have been used as a cue.
>>
>> Device tree aliases kinda sounded a good idea to try. Eg. define adc0 alias
>> and then link it to actual device node in tree.
>>
>> Aliases could be found under /proc/device-tree/aliases. Looking at it shows
>> what device tree node it is. However there does not seem to be actual link
>> from any /proc/device-tree entries to kernel drivers exposed under sysfs.
>> And even the path components in device tree are not in same format as in
>> sysfs. So there is no 1:1 mapping possible here.
>>
>> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
>> devices under /sys/devices and from there is physical path to the device and
>> under that the IIO device with the same name as is under /sys/bus/iio.
>>
>> So in theory we could make a mapping configuration file that specifies
>> logical name for iio device and then physical parent path for the device and
>> then find under it iio:device* files to determine what is the iio device
>> index for this physical device. Then open IIO device with that index in
>> example with libiio. Sounds a bit complex?
>>
>> So did we miss something on how this should be defined/accessed or is there
>> a slight issue here on how to identify iio devices?
>>
>> Don't know how device tree overlays affect this if we first load device tree
>> overlay with some configuration and then unload it and load another one with
>> different configuration.
> Hi,
>
> Yes, excellent analysis. This is a real issue. As you said there is no
> guarantee that the IIO device numbers are stable, they are assigned in the
> order the devices are registered. If the device are registered in a
> different order for whatever reason the numbers will change. You can use
> readlink on the IIO device in /sys/bus/iio/devices to get its position in
> the global device topology and be able to tell what the parent device is,
> but this path might not be completely stable either though. E.g. if your
> device is on a I2C bus and the number of the I2C bus is dynamically assigned
> it might change when the probe order changes.
>
> Alias seem to be one way to solve this issue. The big question remains is
> how to communicate the alias to userspace. For other device classes the
> alias index is used as the device index e.g. a device with alias i2c0 ends
> up being the i2c adapter with index 0. But with IIO where we support a wide
> range of different devices that does not really work. E.g. what to do if you
> have adc0 and dac0 as aliases for different devices. So you'd need a
> different way to expose the alias.
>
> Some bindings also use the "label" property to assign a unique name to node.
> But again the same issue how to expose that information to applications.
>
To continue from this "label" property idea I was wondering if we would 
add it as new optional(?) file node for IIO devices.

One could then specify it like:

tscadc: tscadc@44e0d000 {
     compatible = "ti,am3359-tscadc";
...
     am335x_adc: adc {
         compatible = "ti,am3359-adc";
...
         label = "Port A";
     };
};

And this would generate file /sys/bus/iio/iio:deviceX/label with 
contents of "Port A".

Then during the application startup it would just need to scan all 
devices under /sys/bus/iio and determine what labelled device it wants 
to use.

It would be up to device's developer to determine what labels to use in 
their designs. This would not break ABI and would be just an extension 
for it.

One could also auto-assign label "am335x_adc" in this case too. But if 
you include existing arch device tree then changing label in top level 
is kinda a bit annoying as you would then need to duplicate all 
properties with another label and disable arch device tree's settings. 
Could cause also conflict if there are references elsewhere to existing 
arch nodes.

Having following in device's device tree file would allow one to 
override label or just only specify that.

#include "am33xx.dtsi"

&tscadc {
     status = "okay";

     adc {
         ti,adc-channels = <4 5 6 7>;

         label = "Port A";
     };
};

I think this "label" model would be simple to understand.

Whether this needs to be implemented as per device driver feature or 
could be implemented as generic IIO functionality I do not know.

Thanks,
Vesa Jääskeläinen

Re: IIO device indexing issue

[Phil Reid]

On 5/11/2015 2:53 AM, Vesa Jääskeläinen wrote:
> On 04/11/15 11:38, Lars-Peter Clausen wrote:
>> On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
>>> Hi,
>>>
>>> When we were using kernel 3.2 and with that board files we just got IIO
>>> devices with static order so that we knew exactly what iio:device0 is.
>>>
>>> Now with device tree that order is not so static anymore especially 
>>> when
>>> using device overlays (have not yet tried that thou). If there would be
>>> deferred probe for the device then if we have multiple iio:device's 
>>> then
>>> those could in theory be in any order.
>>>
>>> In example libiio uses iio device index to open the IIO device. So the
>>> problem is to know what iio:device is what.
>>>
>>> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal 
>>> what
>>> device this is (especially if there are multiple device of same 
>>> type). There
>>> does not seem to be a way to give custom name for the iio device 
>>> from device
>>> tree that could have been used as a cue.
>>>
>>> Device tree aliases kinda sounded a good idea to try. Eg. define 
>>> adc0 alias
>>> and then link it to actual device node in tree.
>>>
>>> Aliases could be found under /proc/device-tree/aliases. Looking at 
>>> it shows
>>> what device tree node it is. However there does not seem to be 
>>> actual link
>>> from any /proc/device-tree entries to kernel drivers exposed under 
>>> sysfs.
>>> And even the path components in device tree are not in same format 
>>> as in
>>> sysfs. So there is no 1:1 mapping possible here.
>>>
>>> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
>>> devices under /sys/devices and from there is physical path to the 
>>> device and
>>> under that the IIO device with the same name as is under /sys/bus/iio.
>>>
>>> So in theory we could make a mapping configuration file that specifies
>>> logical name for iio device and then physical parent path for the 
>>> device and
>>> then find under it iio:device* files to determine what is the iio 
>>> device
>>> index for this physical device. Then open IIO device with that index in
>>> example with libiio. Sounds a bit complex?
>>>
>>> So did we miss something on how this should be defined/accessed or 
>>> is there
>>> a slight issue here on how to identify iio devices?
>>>
>>> Don't know how device tree overlays affect this if we first load 
>>> device tree
>>> overlay with some configuration and then unload it and load another 
>>> one with
>>> different configuration.
>> Hi,
>>
>> Yes, excellent analysis. This is a real issue. As you said there is no
>> guarantee that the IIO device numbers are stable, they are assigned 
>> in the
>> order the devices are registered. If the device are registered in a
>> different order for whatever reason the numbers will change. You can use
>> readlink on the IIO device in /sys/bus/iio/devices to get its 
>> position in
>> the global device topology and be able to tell what the parent device 
>> is,
>> but this path might not be completely stable either though. E.g. if your
>> device is on a I2C bus and the number of the I2C bus is dynamically 
>> assigned
>> it might change when the probe order changes.
>>
>> Alias seem to be one way to solve this issue. The big question 
>> remains is
>> how to communicate the alias to userspace. For other device classes the
>> alias index is used as the device index e.g. a device with alias i2c0 
>> ends
>> up being the i2c adapter with index 0. But with IIO where we support 
>> a wide
>> range of different devices that does not really work. E.g. what to do 
>> if you
>> have adc0 and dac0 as aliases for different devices. So you'd need a
>> different way to expose the alias.
>>
>> Some bindings also use the "label" property to assign a unique name 
>> to node.
>> But again the same issue how to expose that information to applications.
>>
> To continue from this "label" property idea I was wondering if we 
> would add it as new optional(?) file node for IIO devices.
>
> One could then specify it like:
>
> tscadc: tscadc@44e0d000 {
>     compatible = "ti,am3359-tscadc";
> ...
>     am335x_adc: adc {
>         compatible = "ti,am3359-adc";
> ...
>         label = "Port A";
>     };
> };
>
> And this would generate file /sys/bus/iio/iio:deviceX/label with 
> contents of "Port A".
>
> Then during the application startup it would just need to scan all 
> devices under /sys/bus/iio and determine what labelled device it wants 
> to use.
>
> It would be up to device's developer to determine what labels to use 
> in their designs. This would not break ABI and would be just an 
> extension for it.
>
> One could also auto-assign label "am335x_adc" in this case too. But if 
> you include existing arch device tree then changing label in top level 
> is kinda a bit annoying as you would then need to duplicate all 
> properties with another label and disable arch device tree's settings. 
> Could cause also conflict if there are references elsewhere to 
> existing arch nodes.
>
> Having following in device's device tree file would allow one to 
> override label or just only specify that.
>
> #include "am33xx.dtsi"
>
> &tscadc {
>     status = "okay";
>
>     adc {
>         ti,adc-channels = <4 5 6 7>;
>
>         label = "Port A";
>     };
> };
>
> I think this "label" model would be simple to understand.
>
> Whether this needs to be implemented as per device driver feature or 
> could be implemented as generic IIO functionality I do not know.
>
> Thanks,
> Vesa Jääskeläinen
This would be a very useful feature as I'm encountering this problem at 
the moment.
The label concept is simple and easy to use.

Regards
Phil.

Re: IIO device indexing issue

[Phil Reid]

On 5/11/2015 9:25 AM, Phil Reid wrote:
> On 5/11/2015 2:53 AM, Vesa Jääskeläinen wrote:
>> On 04/11/15 11:38, Lars-Peter Clausen wrote:
>>> On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
>>>> Hi,
>>>>
>>>> When we were using kernel 3.2 and with that board files we just got 
>>>> IIO
>>>> devices with static order so that we knew exactly what iio:device0 is.
>>>>
>>>> Now with device tree that order is not so static anymore especially 
>>>> when
>>>> using device overlays (have not yet tried that thou). If there 
>>>> would be
>>>> deferred probe for the device then if we have multiple iio:device's 
>>>> then
>>>> those could in theory be in any order.
>>>>
>>>> In example libiio uses iio device index to open the IIO device. So the
>>>> problem is to know what iio:device is what.
>>>>
>>>> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal 
>>>> what
>>>> device this is (especially if there are multiple device of same 
>>>> type). There
>>>> does not seem to be a way to give custom name for the iio device 
>>>> from device
>>>> tree that could have been used as a cue.
>>>>
>>>> Device tree aliases kinda sounded a good idea to try. Eg. define 
>>>> adc0 alias
>>>> and then link it to actual device node in tree.
>>>>
>>>> Aliases could be found under /proc/device-tree/aliases. Looking at 
>>>> it shows
>>>> what device tree node it is. However there does not seem to be 
>>>> actual link
>>>> from any /proc/device-tree entries to kernel drivers exposed under 
>>>> sysfs.
>>>> And even the path components in device tree are not in same format 
>>>> as in
>>>> sysfs. So there is no 1:1 mapping possible here.
>>>>
>>>> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
>>>> devices under /sys/devices and from there is physical path to the 
>>>> device and
>>>> under that the IIO device with the same name as is under /sys/bus/iio.
>>>>
>>>> So in theory we could make a mapping configuration file that specifies
>>>> logical name for iio device and then physical parent path for the 
>>>> device and
>>>> then find under it iio:device* files to determine what is the iio 
>>>> device
>>>> index for this physical device. Then open IIO device with that 
>>>> index in
>>>> example with libiio. Sounds a bit complex?
>>>>
>>>> So did we miss something on how this should be defined/accessed or 
>>>> is there
>>>> a slight issue here on how to identify iio devices?
>>>>
>>>> Don't know how device tree overlays affect this if we first load 
>>>> device tree
>>>> overlay with some configuration and then unload it and load another 
>>>> one with
>>>> different configuration.
>>> Hi,
>>>
>>> Yes, excellent analysis. This is a real issue. As you said there is no
>>> guarantee that the IIO device numbers are stable, they are assigned 
>>> in the
>>> order the devices are registered. If the device are registered in a
>>> different order for whatever reason the numbers will change. You can 
>>> use
>>> readlink on the IIO device in /sys/bus/iio/devices to get its 
>>> position in
>>> the global device topology and be able to tell what the parent 
>>> device is,
>>> but this path might not be completely stable either though. E.g. if 
>>> your
>>> device is on a I2C bus and the number of the I2C bus is dynamically 
>>> assigned
>>> it might change when the probe order changes.
>>>
>>> Alias seem to be one way to solve this issue. The big question 
>>> remains is
>>> how to communicate the alias to userspace. For other device classes the
>>> alias index is used as the device index e.g. a device with alias 
>>> i2c0 ends
>>> up being the i2c adapter with index 0. But with IIO where we support 
>>> a wide
>>> range of different devices that does not really work. E.g. what to 
>>> do if you
>>> have adc0 and dac0 as aliases for different devices. So you'd need a
>>> different way to expose the alias.
>>>
>>> Some bindings also use the "label" property to assign a unique name 
>>> to node.
>>> But again the same issue how to expose that information to 
>>> applications.
>>>
>> To continue from this "label" property idea I was wondering if we 
>> would add it as new optional(?) file node for IIO devices.
>>
>> One could then specify it like:
>>
>> tscadc: tscadc@44e0d000 {
>>     compatible = "ti,am3359-tscadc";
>> ...
>>     am335x_adc: adc {
>>         compatible = "ti,am3359-adc";
>> ...
>>         label = "Port A";
>>     };
>> };
>>
>> And this would generate file /sys/bus/iio/iio:deviceX/label with 
>> contents of "Port A".
>>
>> Then during the application startup it would just need to scan all 
>> devices under /sys/bus/iio and determine what labelled device it 
>> wants to use.
>>
>> It would be up to device's developer to determine what labels to use 
>> in their designs. This would not break ABI and would be just an 
>> extension for it.
>>
>> One could also auto-assign label "am335x_adc" in this case too. But 
>> if you include existing arch device tree then changing label in top 
>> level is kinda a bit annoying as you would then need to duplicate all 
>> properties with another label and disable arch device tree's 
>> settings. Could cause also conflict if there are references elsewhere 
>> to existing arch nodes.
>>
>> Having following in device's device tree file would allow one to 
>> override label or just only specify that.
>>
>> #include "am33xx.dtsi"
>>
>> &tscadc {
>>     status = "okay";
>>
>>     adc {
>>         ti,adc-channels = <4 5 6 7>;
>>
>>         label = "Port A";
>>     };
>> };
>>
>> I think this "label" model would be simple to understand.
>>
>> Whether this needs to be implemented as per device driver feature or 
>> could be implemented as generic IIO functionality I do not know.
>>
>> Thanks,
>> Vesa Jääskeläinen
> This would be a very useful feature as I'm encountering this problem 
> at the moment.
> The label concept is simple and easy to use.
Thinking a bit more how would this work if accessing the device via the 
network interface.
Currently it show the device (chip) name (eg max5541) but there can be 
multiple devices like that.
Needs to be published thru libiio as well?

Regards
Phil

Re: IIO device indexing issue

[Jonathan Cameron]

On 04/11/15 18:53, Vesa Jääskeläinen wrote:
> On 04/11/15 11:38, Lars-Peter Clausen wrote:
>> On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
>>> Hi,
>>>
>>> When we were using kernel 3.2 and with that board files we just got IIO
>>> devices with static order so that we knew exactly what iio:device0 is.
>>>
>>> Now with device tree that order is not so static anymore especially when
>>> using device overlays (have not yet tried that thou). If there would be
>>> deferred probe for the device then if we have multiple iio:device's then
>>> those could in theory be in any order.
>>>
>>> In example libiio uses iio device index to open the IIO device. So the
>>> problem is to know what iio:device is what.
>>>
>>> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what
>>> device this is (especially if there are multiple device of same type). There
>>> does not seem to be a way to give custom name for the iio device from device
>>> tree that could have been used as a cue.
>>>
>>> Device tree aliases kinda sounded a good idea to try. Eg. define adc0 alias
>>> and then link it to actual device node in tree.
>>>
>>> Aliases could be found under /proc/device-tree/aliases. Looking at it shows
>>> what device tree node it is. However there does not seem to be actual link
>>> from any /proc/device-tree entries to kernel drivers exposed under sysfs.
>>> And even the path components in device tree are not in same format as in
>>> sysfs. So there is no 1:1 mapping possible here.
>>>
>>> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
>>> devices under /sys/devices and from there is physical path to the device and
>>> under that the IIO device with the same name as is under /sys/bus/iio.
>>>
>>> So in theory we could make a mapping configuration file that specifies
>>> logical name for iio device and then physical parent path for the device and
>>> then find under it iio:device* files to determine what is the iio device
>>> index for this physical device. Then open IIO device with that index in
>>> example with libiio. Sounds a bit complex?
>>>
>>> So did we miss something on how this should be defined/accessed or is there
>>> a slight issue here on how to identify iio devices?
>>>
>>> Don't know how device tree overlays affect this if we first load device tree
>>> overlay with some configuration and then unload it and load another one with
>>> different configuration.
>> Hi,
>>
>> Yes, excellent analysis. This is a real issue. As you said there is no
>> guarantee that the IIO device numbers are stable, they are assigned in the
>> order the devices are registered. If the device are registered in a
>> different order for whatever reason the numbers will change. You can use
>> readlink on the IIO device in /sys/bus/iio/devices to get its position in
>> the global device topology and be able to tell what the parent device is,
>> but this path might not be completely stable either though. E.g. if your
>> device is on a I2C bus and the number of the I2C bus is dynamically assigned
>> it might change when the probe order changes.
>>
>> Alias seem to be one way to solve this issue. The big question remains is
>> how to communicate the alias to userspace. For other device classes the
>> alias index is used as the device index e.g. a device with alias i2c0 ends
>> up being the i2c adapter with index 0. But with IIO where we support a wide
>> range of different devices that does not really work. E.g. what to do if you
>> have adc0 and dac0 as aliases for different devices. So you'd need a
>> different way to expose the alias.
>>
>> Some bindings also use the "label" property to assign a unique name to node.
>> But again the same issue how to expose that information to applications.
>>
> To continue from this "label" property idea I was wondering if we
> would add it as new optional(?) file node for IIO devices.> 
> One could then specify it like:
> 
> tscadc: tscadc@44e0d000 {
>     compatible = "ti,am3359-tscadc";
> ...
>     am335x_adc: adc {
>         compatible = "ti,am3359-adc";
> ...
>         label = "Port A";
>     };
> };
> 
> And this would generate file /sys/bus/iio/iio:deviceX/label with
> contents of "Port A".
> 
> Then during the application startup it would just need to scan all
> devices under /sys/bus/iio and determine what labelled device it
> wants to use.
> 
> It would be up to device's developer to determine what labels to use
> in their designs. This would not break ABI and would be just an
> extension for it.
> 
> One could also auto-assign label "am335x_adc" in this case too. But
> if you include existing arch device tree then changing label in top
> level is kinda a bit annoying as you would then need to duplicate all
> properties with another label and disable arch device tree's
> settings. Could cause also conflict if there are references elsewhere
> to existing arch nodes.
> 
> Having following in device's device tree file would allow one to
> override label or just only specify that.
> 
> #include "am33xx.dtsi"
> 
> &tscadc {
>     status = "okay";
> 
>     adc {
>         ti,adc-channels = <4 5 6 7>;
> 
>         label = "Port A";
>     };
> };
> 
> I think this "label" model would be simple to understand.
> 
> Whether this needs to be implemented as per device driver feature or
> could be implemented as generic IIO functionality I do not know.
The principal looks good to me.  It's not however only an IIO issue
so perhaps we should expand the discussion to include other subsystems
likely to have similar issues (though perhaps to a lesser degree) such as
hwmon and input?  Any others?

We could also autobuild the label from other sources such as ACPI
to uniquely describe the instance of the device (afterall all we really
care about is that it always has the same name on the same hardware, 
being able to assign meaningful simple names would just be the icing
on the cake!)

Jonathan
> Thanks,
> Vesa Jääskeläinen
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IIO device indexing issue

[Markus Pargmann]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

Hi,

On Thursday, November 05, 2015 07:13:41 PM Jonathan Cameron wrote:
> On 04/11/15 18:53, Vesa Jääskeläinen wrote:
> > To continue from this "label" property idea I was wondering if we
> > would add it as new optional(?) file node for IIO devices.> 
> > One could then specify it like:
> > 
> > tscadc: tscadc@44e0d000 {
> >     compatible = "ti,am3359-tscadc";
> > ...
> >     am335x_adc: adc {
> >         compatible = "ti,am3359-adc";
> > ...
> >         label = "Port A";
> >     };
> > };
> > 
> > And this would generate file /sys/bus/iio/iio:deviceX/label with
> > contents of "Port A".
> > 
> > Then during the application startup it would just need to scan all
> > devices under /sys/bus/iio and determine what labelled device it
> > wants to use.
> > 
> > It would be up to device's developer to determine what labels to use
> > in their designs. This would not break ABI and would be just an
> > extension for it.
> > 
> > One could also auto-assign label "am335x_adc" in this case too. But
> > if you include existing arch device tree then changing label in top
> > level is kinda a bit annoying as you would then need to duplicate all
> > properties with another label and disable arch device tree's
> > settings. Could cause also conflict if there are references elsewhere
> > to existing arch nodes.
> > 
> > Having following in device's device tree file would allow one to
> > override label or just only specify that.
> > 
> > #include "am33xx.dtsi"
> > 
> > &tscadc {
> >     status = "okay";
> > 
> >     adc {
> >         ti,adc-channels = <4 5 6 7>;
> > 
> >         label = "Port A";
> >     };
> > };
> > 
> > I think this "label" model would be simple to understand.
> > 
> > Whether this needs to be implemented as per device driver feature or
> > could be implemented as generic IIO functionality I do not know.
> The principal looks good to me.  It's not however only an IIO issue
> so perhaps we should expand the discussion to include other subsystems
> likely to have similar issues (though perhaps to a lesser degree) such as
> hwmon and input?  Any others?
> 
> We could also autobuild the label from other sources such as ACPI
> to uniquely describe the instance of the device (afterall all we really
> care about is that it always has the same name on the same hardware, 
> being able to assign meaningful simple names would just be the icing
> on the cake!)

There is a similar discussion for the new character device GPIO interface.[1]

Simple labels have the problem that they could be the same for two devicetree
overlays or chips that are connected via SPI.

Best Regards,

Markus


[1] http://thread.gmane.org/gmane.linux.kernel.gpio/11475

> 
> Jonathan
> > Thanks,
> > Vesa Jääskeläinen
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: IIO device indexing issue

[Vesa Jääskeläinen]

On 06/11/15 11:49, Markus Pargmann wrote:
> Hi,
>
> On Thursday, November 05, 2015 07:13:41 PM Jonathan Cameron wrote:
>> On 04/11/15 18:53, Vesa Jääskeläinen wrote:
>>> To continue from this "label" property idea I was wondering if we
>>> would add it as new optional(?) file node for IIO devices.>
>>> One could then specify it like:
>>>
>>> tscadc: tscadc@44e0d000 {
>>>      compatible = "ti,am3359-tscadc";
>>> ...
>>>      am335x_adc: adc {
>>>          compatible = "ti,am3359-adc";
>>> ...
>>>          label = "Port A";
>>>      };
>>> };
>>>
>>> And this would generate file /sys/bus/iio/iio:deviceX/label with
>>> contents of "Port A".
>>>
>>> Then during the application startup it would just need to scan all
>>> devices under /sys/bus/iio and determine what labelled device it
>>> wants to use.
>>>
>>> It would be up to device's developer to determine what labels to use
>>> in their designs. This would not break ABI and would be just an
>>> extension for it.
>>>
>>> One could also auto-assign label "am335x_adc" in this case too. But
>>> if you include existing arch device tree then changing label in top
>>> level is kinda a bit annoying as you would then need to duplicate all
>>> properties with another label and disable arch device tree's
>>> settings. Could cause also conflict if there are references elsewhere
>>> to existing arch nodes.
>>>
>>> Having following in device's device tree file would allow one to
>>> override label or just only specify that.
>>>
>>> #include "am33xx.dtsi"
>>>
>>> &tscadc {
>>>      status = "okay";
>>>
>>>      adc {
>>>          ti,adc-channels = <4 5 6 7>;
>>>
>>>          label = "Port A";
>>>      };
>>> };
>>>
>>> I think this "label" model would be simple to understand.
>>>
>>> Whether this needs to be implemented as per device driver feature or
>>> could be implemented as generic IIO functionality I do not know.
>> The principal looks good to me.  It's not however only an IIO issue
>> so perhaps we should expand the discussion to include other subsystems
>> likely to have similar issues (though perhaps to a lesser degree) such as
>> hwmon and input?  Any others?
>>
>> We could also autobuild the label from other sources such as ACPI
>> to uniquely describe the instance of the device (afterall all we really
>> care about is that it always has the same name on the same hardware,
>> being able to assign meaningful simple names would just be the icing
>> on the cake!)
> There is a similar discussion for the new character device GPIO interface.[1]
>
> Simple labels have the problem that they could be the same for two devicetree
> overlays or chips that are connected via SPI.
>
As far as I understand the overlays, you always specify a hardware 
hierarchy where you want to add additional information to device tree. 
This means that while adding device with overlays you have full control 
what device it is and then can configure what label property device 
should have.

If you would add two SPI devices those would be unique items in the 
device tree this means that overlay adding those would be unique and 
then you can assign unique label for the devices.

When you have full control for device tree and device tree overlays 
added to your device then this should not be problem?

Problem not addressed by device tree would be dynamically configured 
buses like USB which could have user connected devices. But then again 
you probably do not configure this with device tree either? In this case 
if "label" would be read&write property then udev or such could then 
fill it with details based on your configuration.

As commented on the thread you pointed out was question should the label 
property have physical path components in there. There was comment that 
symlink (in IIO case this would be symlinks under /sys/bus/iio/) should 
have the details available if this is needed for decision.

Basically application developer could have following tools to perform 
his decision:

Scan /sys/bus/iio/ for iio:deviceN's.

- Get "name" property (driver identification).
- Do realpath for symlink to get physical address
- Get "label" property to have cue what this device is for

On other thread one idea was to have UUID for devices as a label (fstab 
+ partition UUID's was the idea behind it). How to make it stick for 
every boot is the problem here however. You could use UUID in hash mode 
(eg. version 5) and then just determine what details affect it. For USB 
devices which could be moved to other slots this is still an issue as on 
some cases it would be irrelevant on what slot it is and in some cases 
it could be relevant. There are also other properties that are device 
specific like should the UUID hash include serial number of the device 
or not? This same problem matches to other automatic label cases. So I 
suppose there is no one solution that fits for all cases.

To setup label automatically you seem to need to have local configuration.

If the process would be something like:

- Setup device tree with optional label property.
- If label is not defined in device tree leave it as empty
- When user space starts up it can have local configuration that adjusts 
labels
- If there is a daemon in system like udev and new device is inserted 
then it could have rules for configuring labels.

I think this would allow one to setup whatever identification one wants 
to use for label.

Rest would be application configuration that uses available information 
to do its magic.

Thanks,
Vesa Jääskeläinen

Re: IIO device indexing issue

[Markus Pargmann]

[-- Attachment #1: Type: text/plain, Size: 7211 bytes --]

On Saturday 07 November 2015 11:03:26 Vesa Jääskeläinen wrote:
> On 06/11/15 11:49, Markus Pargmann wrote:
> > Hi,
> >
> > On Thursday, November 05, 2015 07:13:41 PM Jonathan Cameron wrote:
> >> On 04/11/15 18:53, Vesa Jääskeläinen wrote:
> >>> To continue from this "label" property idea I was wondering if we
> >>> would add it as new optional(?) file node for IIO devices.>
> >>> One could then specify it like:
> >>>
> >>> tscadc: tscadc@44e0d000 {
> >>>      compatible = "ti,am3359-tscadc";
> >>> ...
> >>>      am335x_adc: adc {
> >>>          compatible = "ti,am3359-adc";
> >>> ...
> >>>          label = "Port A";
> >>>      };
> >>> };
> >>>
> >>> And this would generate file /sys/bus/iio/iio:deviceX/label with
> >>> contents of "Port A".
> >>>
> >>> Then during the application startup it would just need to scan all
> >>> devices under /sys/bus/iio and determine what labelled device it
> >>> wants to use.
> >>>
> >>> It would be up to device's developer to determine what labels to use
> >>> in their designs. This would not break ABI and would be just an
> >>> extension for it.
> >>>
> >>> One could also auto-assign label "am335x_adc" in this case too. But
> >>> if you include existing arch device tree then changing label in top
> >>> level is kinda a bit annoying as you would then need to duplicate all
> >>> properties with another label and disable arch device tree's
> >>> settings. Could cause also conflict if there are references elsewhere
> >>> to existing arch nodes.
> >>>
> >>> Having following in device's device tree file would allow one to
> >>> override label or just only specify that.
> >>>
> >>> #include "am33xx.dtsi"
> >>>
> >>> &tscadc {
> >>>      status = "okay";
> >>>
> >>>      adc {
> >>>          ti,adc-channels = <4 5 6 7>;
> >>>
> >>>          label = "Port A";
> >>>      };
> >>> };
> >>>
> >>> I think this "label" model would be simple to understand.
> >>>
> >>> Whether this needs to be implemented as per device driver feature or
> >>> could be implemented as generic IIO functionality I do not know.
> >> The principal looks good to me.  It's not however only an IIO issue
> >> so perhaps we should expand the discussion to include other subsystems
> >> likely to have similar issues (though perhaps to a lesser degree) such as
> >> hwmon and input?  Any others?
> >>
> >> We could also autobuild the label from other sources such as ACPI
> >> to uniquely describe the instance of the device (afterall all we really
> >> care about is that it always has the same name on the same hardware,
> >> being able to assign meaningful simple names would just be the icing
> >> on the cake!)
> > There is a similar discussion for the new character device GPIO interface.[1]
> >
> > Simple labels have the problem that they could be the same for two devicetree
> > overlays or chips that are connected via SPI.
> >
> As far as I understand the overlays, you always specify a hardware 
> hierarchy where you want to add additional information to device tree. 
> This means that while adding device with overlays you have full control 
> what device it is and then can configure what label property device 
> should have.

I would expect at some point in the future that there is enough
tooling/hotplug/something else that you have some generic devicetrees that can
be 'hotplugged' to any bus. For example If you connect two identical spi
sensors to two different spi busses I would really expect that we have only one
devicetree to describe this chip and some tooling to do the rest. However this
is probably not right for the moment but perhaps in the future.

> 
> If you would add two SPI devices those would be unique items in the 
> device tree this means that overlay adding those would be unique and 
> then you can assign unique label for the devices.

Yes these would be unique items but only if you consider the whole path of the
device. If you limit it to the simple approach that was mentioned with only a
simple label property this wouldn't work. Generating/Assigning labels would
probably solve that but I just meant the mentioned 'simple' solution of fixed
labels that are fixed in the devicetree.

> 
> When you have full control for device tree and device tree overlays 
> added to your device then this should not be problem?
> 
> Problem not addressed by device tree would be dynamically configured 
> buses like USB which could have user connected devices. But then again 
> you probably do not configure this with device tree either? In this case 
> if "label" would be read&write property then udev or such could then 
> fill it with details based on your configuration.
> 
> As commented on the thread you pointed out was question should the label 
> property have physical path components in there. There was comment that 
> symlink (in IIO case this would be symlinks under /sys/bus/iio/) should 
> have the details available if this is needed for decision.
> 
> Basically application developer could have following tools to perform 
> his decision:
> 
> Scan /sys/bus/iio/ for iio:deviceN's.
> 
> - Get "name" property (driver identification).
> - Do realpath for symlink to get physical address
> - Get "label" property to have cue what this device is for
> 
> On other thread one idea was to have UUID for devices as a label (fstab 
> + partition UUID's was the idea behind it). How to make it stick for 
> every boot is the problem here however. You could use UUID in hash mode 
> (eg. version 5) and then just determine what details affect it. For USB 
> devices which could be moved to other slots this is still an issue as on 
> some cases it would be irrelevant on what slot it is and in some cases 
> it could be relevant. There are also other properties that are device 
> specific like should the UUID hash include serial number of the device 
> or not? This same problem matches to other automatic label cases. So I 
> suppose there is no one solution that fits for all cases.
> 
> To setup label automatically you seem to need to have local configuration.
> 
> If the process would be something like:
> 
> - Setup device tree with optional label property.
> - If label is not defined in device tree leave it as empty
> - When user space starts up it can have local configuration that adjusts 
> labels
> - If there is a daemon in system like udev and new device is inserted 
> then it could have rules for configuring labels.
> 
> I think this would allow one to setup whatever identification one wants 
> to use for label.

I personally would prefer a generic way so that it is identical on each system
by default. Every user can always write udev rules to fulfill their needs.

But I think it would be good to merge both discussions.

Best Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]