linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Crestez Dan Leonard <leonard.crestez@intel.com>
To: Gregor Boirie <gregor.boirie@parrot.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Daniel Baluta <daniel.baluta@gmail.com>,
	Yong Li <sdliyong@gmail.com>, Hartmut Knaack <knaack.h@gmx.de>,
	Matt Ranostaj <mranostay@gmail.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [was iio: tmp006: Set correct iio name] how to support multiple instances of same device type
Date: Tue, 3 May 2016 15:00:42 +0300	[thread overview]
Message-ID: <572892EA.2060902@intel.com> (raw)
In-Reply-To: <572872B8.8060000@parrot.com>

On 05/03/2016 12:43 PM, Gregor Boirie wrote:
> Just to let you know that I'm facing a problem to support multiple
> instances of
> the ms5607 barometer onto the same board.
> 
> Referencing (i2c) id->name from indio_dev->name is not suitable in this
> case as
> libiio and kernel iio tools such as generic_buffer all rely upon a
> unique iio
> name to distinguish devices. Here is why.
> 
> generic_buffer expects a device name passed as argument to -n option
> to get a reference to a device. In this case, it is not possible to
> distinguish between devices holding the same name.
> 
> When libiio based apps use iio_context_find_device() to get a reference
> to a device (by name), names should be unique across devices as above.
> When retrieving a device reference by index through
> iio_context_get_device()
> it is not possible to uniquely identify devices in a consistent way either.
> Indeed, as indices assignment is automatically done at boot time, it is
> highly
> dependent on module / driver loading ordering, devices / daughter board
> presence,
> etc...
> As a result, apps cannot assume indices are persistent across reboots.
> 
> Hence, using dev_name(&client->dev) to name a device is most certainly
> an acceptable
> option despites inconsistencies it introduces with i2c name space.
> 
> I re-use device tree names to do the job. However, it will not work if
> not compiled
> in (and needs patching). What would be a robust and generic naming
> solution then ?
> 
Identifying iio devices by numeric ID seems to be the correct solution.
These are also the minor device numbers, right? Perhaps you can create
devices nodes with pretty names through udev rules. In particular
OF_FULLNAME seems to be available as a property. Example:

# ssh -t local2222 udevadm info /sys/bus/iio/devices/iio:device0
DEVNAME=/dev/iio:device0
DEVTYPE=iio_device
MAJOR=250
MINOR=0
OF_COMPATIBLE_0=inv,mpu6500
OF_COMPATIBLE_N=1
OF_FULLNAME=/spi/mpu6500@0
OF_NAME=mpu6500
SUBSYSTEM=iio

-- 
Regards
Leonard

  reply	other threads:[~2016-05-03 12:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-22  3:43 [PATCH] iio: tmp006: Set correct iio name Yong Li
2016-04-25 19:33 ` Jonathan Cameron
2016-04-25 20:59   ` Crestez Dan Leonard
2016-04-25 21:11     ` Jonathan Cameron
2016-04-26 10:57       ` Lars-Peter Clausen
2016-04-26 11:47         ` Yong Li
2016-04-26 12:01           ` Lars-Peter Clausen
2016-04-26 13:14             ` Yong Li
2016-04-26 15:21               ` Daniel Baluta
2016-04-27  3:42                 ` Yong Li
2016-04-27 16:58                 ` Crestez Dan Leonard
2016-04-28  8:25                   ` Lars-Peter Clausen
2016-04-28 13:24                     ` One Thousand Gnomes
2016-04-28 13:30                       ` Peter Meerwald-Stadler
2016-04-28 14:19                         ` Lars-Peter Clausen
2016-05-01 19:34                           ` Jonathan Cameron
2016-05-03  9:43                             ` [was iio: tmp006: Set correct iio name] how to support multiple instances of same device type Gregor Boirie
2016-05-03 12:00                               ` Crestez Dan Leonard [this message]
2016-04-28 14:17                       ` [PATCH] iio: tmp006: Set correct iio name Lars-Peter Clausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=572892EA.2060902@intel.com \
    --to=leonard.crestez@intel.com \
    --cc=daniel.baluta@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregor.boirie@parrot.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=mranostay@gmail.com \
    --cc=pmeerw@pmeerw.net \
    --cc=sdliyong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).