Re: IIO device indexing issue

["Vesa Jääskeläinen" <dachaac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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