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.