Your device naming convention should be:

1) consistent with usual linux kernel practice
2) compatible with acpi-based systems (x86 and arm64)
3) compatible with device tree based systems (all others, I believe).

Here is some info from my dell 2-in-1 touch laptop:

Device(u'/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1/i2c-
DELL0742:00/0018:06CB:7E92.0009/input/input13')

According to the description in acpi programming reference, this suggests
acpi loaded the pci bus enumerator, which found the i2c-designware
host controllers, called the i2c_designwarer driver's probe function, which
did not scan the bus for slaves. But someone else has, possibly a driver
in the input system, and created the /sys node.

As you can see, '/', ':', '-' and '.' are being used as separators.

My hardware info says the laptop has two designware i2c host controllers,
thus the 'i2c-1' above refers to one of these.
I don't know what the following stuff is, but the '.0009' is probably an
i2c slave device specific value.

So you could, for example use 'accel_3d.1', etc for your naming. Where you
would create it is an open question.

Finally, I see some general problems in creating a system to monitor many
sensors:

Common sensors  don't have usb interfaces, so you couldn't use usb or hid
interface to control them.

These sensors do have either i2c or spi or both interfaces. Some have uart
interfaces

Sensors with i2c interfaces may have either one or two slave addresses. If
two, the address is selected by an input pin.
There is probably no name register you could program or use to distinguish
two devices on the same bus.
You would have to store the slave address somewhere, perhaps in a struct
with a name like 'chip_info'.

Of course in a device tree based system, you could just declare the slaves
as resources, and specify their slave addresses.

spi has the problem that 'in band' slave addressing is not supported, i.e.
there is no slave address in the data messages,
so you have to use extra gpio pins to select multiple devices.

On Fri, Mar 17, 2017 at 9:22 AM, Pandruvada, Srinivas <
srinivas.pandruvada@intel.com> wrote:

> On Fri, 2017-03-17 at 14:16 +0100, Bastien Nocera wrote:
> > On Fri, 2017-03-17 at 02:13 +0000, Pandruvada, Srinivas wrote:
> > >
> > > On Thu, 2017-03-16 at 18:20 +0800, Song Hongyan wrote:
> > > >
> > > > As accelerometer sensor becomes more and more popular, there are
> > > > more
> > > > user scenarios have been developed, "Hinge" is a very important
> > > > usecase
> > > > which needs two accelerometer sensors to calculate the included
> > > > angle
> > > > of keyboard and screen.
> > > > In this case, two accelerometer sensors will be exposed.
> > > > Currently,
> > > > IIO interface hasn't other way to distinguish two sensors with
> > > > same
> > > > sensor type, except sensor name. So a new sensor name
> > > > "accel_2nd_3d"
> > > > is added for secondary accelerometer sensor.
> > >
> > > This type of interface will not satisfy all cases. We have some
> > > hubs
> > > with  many accelerometers attached. Same case is also true even for
> > > discrete sensors. So there should be some framework way to expose
> > > location of sensors.
> >
> > So you're nacking as well?
> Yes.
>
> >
> > >
> > > ACPI has special method called _PLD (Physical Device Location),
> > > which
> > > can  be used to specify location of any device. So we need to be
> > > able
> > > to export such information to user space. We can add for each
> > > sensor
> > > the location information.
> > >
> > > I can propose some ABI for exporting location information.
> >
> > There were patches floating around to do this, but they were never
> > finished:
> > http://www.spinics.net/lists/linux-acpi/msg51540.html
> We need to add some of those element related to sensors to IIO ABI.
> I will propose an ABI as Jonathan suggested.
>
> Thanks,
> Srinivas
>