On Mon, 2020-05-11 at 15:58 +0200, Lars-Peter Clausen wrote:
[External]Many thanks :)
On 5/11/20 3:24 PM, Ardelean, Alexandru wrote:
On Mon, 2020-05-11 at 13:03 +0000, Ardelean, Alexandru wrote:But there is one in device_type :)
[External]What I should have highlighted [before] with this, is that there is no
On Mon, 2020-05-11 at 12:37 +0200, Lars-Peter Clausen wrote:
[External]I admit I did not look closely into drivers/input/input.c before
On 5/11/20 12:33 PM, Ardelean, Alexandru wrote:
On Sun, 2020-05-10 at 11:09 +0100, Jonathan Cameron wrote:All you have to do is return "iio/..." from the devnode() callback.
[External]I was also thinking about the /dev/iio subfolder while doing this.
On Sat, 9 May 2020 10:52:14 +0200
Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
On 5/8/20 3:53 PM, Alexandru Ardelean wrote:Possibly on the folder. I can't for the life of me remember why I
[...]Looking at how the /dev/ devices are named I think we can provide
What I don't like, is that iio:device3 has iio:buffer3:0 (to 3).
This is because the 'buffer->dev.parent = &indio_dev->dev'.
But I do feel this is correct.
So, now I don't know whether to leave it like that or symlink to
shorter
versions like 'iio:buffer3:Y' -> 'iio:device3/bufferY'.
The reason for naming the IIO buffer devices to 'iio:bufferX:Y'
is
mostly to make the names unique. It would have looked weird to
do
'/dev/buffer1' if I would have named the buffer devices
'bufferX'.
So, now I'm thinking of whether all this is acceptable.
Or what is acceptable?
Should I symlink 'iio:device3/iio:buffer3:0' ->
'iio:device3/buffer0'?
What else should I consider moving forward?
What means forward?
Where did I leave my beer?
a
name
that is different from the dev_name() of the device. Have a look
at
device_get_devnode() in drivers/base/core.c. We should be able to
provide the name for the chardev through the devnode() callback.
While we are at this, do we want to move the new devices into an
iio
subfolder? So iio/buffer0:0 instead of iio:buffer0:0?
decided
not to do that the first time around - I'll leave it at the
mysterious "it may turn out to be harder than you'd think..."
Hopefully not ;)
I can copy that from /dev/input
They seem to do it already.
I don't know how difficult it would be. But it looks like a good
precedent.
mentioning
this
as as good precedent.
But, I looks like /dev/inpput is a class.
While IIO devices are a bus_type devices.
Should we start implementing an IIO class? or?
devnode()
callback for the bus_type [type].
That worked nicely.
I now have:
root@analog:~# ls /dev/iio/*
/dev/iio/iio:device0 /dev/iio/iio:device1
/dev/iio/device3:
buffer0 buffer1 buffer2 buffer3
/dev/iio/device4:
buffer0
It looks like I can shift these around as needed.
This is just an experiment.
I managed to move the iio devices under /dev/iio, though probably the IIO
devices will still be around as /dev/iio:deviceX for legacy reasons.
Two things remain unresolved.
1. The name of the IIO buffer device.
root@analog:/sys/bus/iio/devices# ls iio\:device3/
buffer in_voltage0_test_mode name
events in_voltage1_test_mode of_node
iio:buffer:3:0 in_voltage_sampling_frequency power
iio:buffer:3:1 in_voltage_scale scan_elements
iio:buffer:3:2 in_voltage_scale_available subsystem
iio:buffer:3:3 in_voltage_test_mode_available uevent
Right now, each buffer device is named 'iio:buffer:X:Y'.
One suggesttion was 'iio:deviceX:bufferY'
I'm suspecting the latter is preferred as when you sort the folders, buffers
come right after the iio:deviceX folders in /sys/bus/iio/devices.
I don't feel it matters much the device name of the IIO buffer if we symlink it
to a shorter form.
I'm guessing, we symlink these devices to short-hand 'bufferY' folders in each
'iio:deviceX'?
[...]Does not seem to be possible. Userspace will have to take care of it. This means we need to keep legacy devices in /dev/ and only new buffers in /dev/iio/.
2. I know this is [still] stupid now; but any suggestions one how to symlink
/dev/iio:device3 -> /dev/iio/device3/buffer0 ?