| Message ID | 20201203095342.73591-1-alexandru.ardelean@analog.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] iio: core: register chardev only if needed | expand |
On Thu, Dec 3, 2020 at 11:55 AM Alexandru Ardelean <alexandru.ardelean@analog.com> wrote: > > We only need a chardev if we need to support buffers and/or events. > > With this change, a chardev will be created only if an IIO buffer is > attached OR an event_interface is configured. > > Otherwise, no chardev will be created, and the IIO device will get > registered with the 'device_add()' call. > > Quite a lot of IIO devices don't really need a chardev, so this is a minor > improvement to the IIO core, as the IIO device will take up (slightly) > fewer resources. > > In order to not create a chardev, we mostly just need to not initialize the > indio_dev->dev.devt field. If that is un-initialized, cdev_device_add() un-initialized -> uninitialized > behaves like device_add(). Are you sure there is no user space application that doesn't rely on character device to be always present?
On Wed, Dec 9, 2020 at 5:37 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Thu, Dec 3, 2020 at 11:55 AM Alexandru Ardelean > <alexandru.ardelean@analog.com> wrote: > > > > We only need a chardev if we need to support buffers and/or events. > > > > With this change, a chardev will be created only if an IIO buffer is > > attached OR an event_interface is configured. > > > > Otherwise, no chardev will be created, and the IIO device will get > > registered with the 'device_add()' call. > > > > Quite a lot of IIO devices don't really need a chardev, so this is a minor > > improvement to the IIO core, as the IIO device will take up (slightly) > > fewer resources. > > > > In order to not create a chardev, we mostly just need to not initialize the > > indio_dev->dev.devt field. If that is un-initialized, cdev_device_add() > > un-initialized -> uninitialized > > > behaves like device_add(). > > Are you sure there is no user space application that doesn't rely on > character device to be always present? Nope. I'm not sure. I'm also not completely sure how Jonathan feels about this patch being added now [so late]. Though, technically if the chardev was already there, without all the control in place [to enable IIO buffers and other stuff through the chardev] then it's technically just a "marker" file. Which arguably is a lot to have (i.e. chardev that should be unusable). If it is usable with no control in place for buffers or other stuff (i.e. I missed something), then I also don't know. So, this patch on it's own can still be interpreted as an RFC. See: https://lore.kernel.org/linux-iio/20201121180246.772ad299@archlinux/ > > -- > With Best Regards, > Andy Shevchenko
On Wed, Dec 9, 2020 at 5:45 PM Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > On Wed, Dec 9, 2020 at 5:37 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > On Thu, Dec 3, 2020 at 11:55 AM Alexandru Ardelean > > <alexandru.ardelean@analog.com> wrote: ... > > Are you sure there is no user space application that doesn't rely on > > character device to be always present? > > Nope. > I'm not sure. > I'm also not completely sure how Jonathan feels about this patch being > added now [so late]. > > Though, technically if the chardev was already there, without all the > control in place [to enable IIO buffers and other stuff through the > chardev] then it's technically just a "marker" file. > Which arguably is a lot to have (i.e. chardev that should be unusable). > > If it is usable with no control in place for buffers or other stuff > (i.e. I missed something), then I also don't know. > > So, this patch on it's own can still be interpreted as an RFC. > See: > https://lore.kernel.org/linux-iio/20201121180246.772ad299@archlinux/ Don't take me wrong, I'm not against a good change (I doesn't like dangling files), but it might break some use cases.
On Wed, Dec 9, 2020 at 5:53 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Dec 9, 2020 at 5:45 PM Alexandru Ardelean > <ardeleanalex@gmail.com> wrote: > > On Wed, Dec 9, 2020 at 5:37 PM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > On Thu, Dec 3, 2020 at 11:55 AM Alexandru Ardelean > > > <alexandru.ardelean@analog.com> wrote: > > ... > > > > Are you sure there is no user space application that doesn't rely on > > > character device to be always present? > > > > Nope. > > I'm not sure. > > I'm also not completely sure how Jonathan feels about this patch being > > added now [so late]. > > > > Though, technically if the chardev was already there, without all the > > control in place [to enable IIO buffers and other stuff through the > > chardev] then it's technically just a "marker" file. > > Which arguably is a lot to have (i.e. chardev that should be unusable). > > > > If it is usable with no control in place for buffers or other stuff > > (i.e. I missed something), then I also don't know. > > > > So, this patch on it's own can still be interpreted as an RFC. > > See: > > https://lore.kernel.org/linux-iio/20201121180246.772ad299@archlinux/ > > Don't take me wrong, I'm not against a good change (I doesn't like > dangling files), but it might break some use cases. Yeah I know. But how else do you know if a dangling file might break some use cases? The worst that would happen is that we get a report and create a Fixes tag and we know. But if we don't try it, we're stuck with it, and will never know. > > -- > With Best Regards, > Andy Shevchenko
On Wed, 9 Dec 2020 17:55:22 +0200 Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > On Wed, Dec 9, 2020 at 5:53 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: > > > > On Wed, Dec 9, 2020 at 5:45 PM Alexandru Ardelean > > <ardeleanalex@gmail.com> wrote: > > > On Wed, Dec 9, 2020 at 5:37 PM Andy Shevchenko > > > <andy.shevchenko@gmail.com> wrote: > > > > On Thu, Dec 3, 2020 at 11:55 AM Alexandru Ardelean > > > > <alexandru.ardelean@analog.com> wrote: > > > > ... > > > > > > Are you sure there is no user space application that doesn't rely on > > > > character device to be always present? > > > > > > Nope. > > > I'm not sure. > > > I'm also not completely sure how Jonathan feels about this patch being > > > added now [so late]. > > > > > > Though, technically if the chardev was already there, without all the > > > control in place [to enable IIO buffers and other stuff through the > > > chardev] then it's technically just a "marker" file. > > > Which arguably is a lot to have (i.e. chardev that should be unusable). > > > > > > If it is usable with no control in place for buffers or other stuff > > > (i.e. I missed something), then I also don't know. > > > > > > So, this patch on it's own can still be interpreted as an RFC. > > > See: > > > https://lore.kernel.org/linux-iio/20201121180246.772ad299@archlinux/ > > > > Don't take me wrong, I'm not against a good change (I doesn't like > > dangling files), but it might break some use cases. > > Yeah I know. > But how else do you know if a dangling file might break some use cases? > > The worst that would happen is that we get a report and create a Fixes > tag and we know. > But if we don't try it, we're stuck with it, and will never know. > It's definitely a high risk change. I'd 'hope' it's not a problem but we should do a bit more due diligence. I hope we can assume the ADI software is all fine with dropping this. Bastien can you see any issues with dropping chrdev for IIO devices that don't actually support using it for anything (sysfs interface only). What other stacks are people aware of that we should enquire about? Thanks, Jonathan > > > > -- > > With Best Regards, > > Andy Shevchenko
On Sun, Dec 13, 2020 at 4:31 PM Jonathan Cameron <jic23@kernel.org> wrote: > > On Wed, 9 Dec 2020 17:55:22 +0200 > Alexandru Ardelean <ardeleanalex@gmail.com> wrote: > > > On Wed, Dec 9, 2020 at 5:53 PM Andy Shevchenko > > <andy.shevchenko@gmail.com> wrote: > > > > > > On Wed, Dec 9, 2020 at 5:45 PM Alexandru Ardelean > > > <ardeleanalex@gmail.com> wrote: > > > > On Wed, Dec 9, 2020 at 5:37 PM Andy Shevchenko > > > > <andy.shevchenko@gmail.com> wrote: > > > > > On Thu, Dec 3, 2020 at 11:55 AM Alexandru Ardelean > > > > > <alexandru.ardelean@analog.com> wrote: > > > > > > ... > > > > > > > > Are you sure there is no user space application that doesn't rely on > > > > > character device to be always present? > > > > > > > > Nope. > > > > I'm not sure. > > > > I'm also not completely sure how Jonathan feels about this patch being > > > > added now [so late]. > > > > > > > > Though, technically if the chardev was already there, without all the > > > > control in place [to enable IIO buffers and other stuff through the > > > > chardev] then it's technically just a "marker" file. > > > > Which arguably is a lot to have (i.e. chardev that should be unusable). > > > > > > > > If it is usable with no control in place for buffers or other stuff > > > > (i.e. I missed something), then I also don't know. > > > > > > > > So, this patch on it's own can still be interpreted as an RFC. > > > > See: > > > > https://lore.kernel.org/linux-iio/20201121180246.772ad299@archlinux/ > > > > > > Don't take me wrong, I'm not against a good change (I doesn't like > > > dangling files), but it might break some use cases. > > > > Yeah I know. > > But how else do you know if a dangling file might break some use cases? > > > > The worst that would happen is that we get a report and create a Fixes > > tag and we know. > > But if we don't try it, we're stuck with it, and will never know. > > > It's definitely a high risk change. I'd 'hope' it's not a problem > but we should do a bit more due diligence. > > I hope we can assume the ADI software is all fine with dropping this. > Bastien can you see any issues with dropping chrdev for IIO devices > that don't actually support using it for anything (sysfs interface only). > > What other stacks are people aware of that we should enquire about? Hey, Any more thoughts on this? Thanks Alex > > Thanks, > > Jonathan > > > > > > -- > > > With Best Regards, > > > Andy Shevchenko >
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index c2e4c267c36b..d4de32d878aa 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -1725,6 +1725,15 @@ static const struct file_operations iio_buffer_fileops = { .release = iio_chrdev_release, }; +static const struct file_operations iio_event_fileops = { + .owner = THIS_MODULE, + .llseek = noop_llseek, + .unlocked_ioctl = iio_ioctl, + .compat_ioctl = compat_ptr_ioctl, + .open = iio_chrdev_open, + .release = iio_chrdev_release, +}; + static int iio_check_unique_scan_index(struct iio_dev *indio_dev) { int i, j; @@ -1752,6 +1761,7 @@ static const struct iio_buffer_setup_ops noop_ring_setup_ops; int __iio_device_register(struct iio_dev *indio_dev, struct module *this_mod) { + struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev); int ret; if (!indio_dev->info) @@ -1769,9 +1779,6 @@ int __iio_device_register(struct iio_dev *indio_dev, struct module *this_mod) if (ret < 0) return ret; - /* configure elements for the chrdev */ - indio_dev->dev.devt = MKDEV(MAJOR(iio_devt), indio_dev->id); - iio_device_register_debugfs(indio_dev); ret = iio_buffer_alloc_sysfs_and_mask(indio_dev); @@ -1800,9 +1807,15 @@ int __iio_device_register(struct iio_dev *indio_dev, struct module *this_mod) indio_dev->setup_ops == NULL) indio_dev->setup_ops = &noop_ring_setup_ops; - cdev_init(&indio_dev->chrdev, &iio_buffer_fileops); + if (indio_dev->buffer) + cdev_init(&indio_dev->chrdev, &iio_buffer_fileops); + else if (iio_dev_opaque->event_interface) + cdev_init(&indio_dev->chrdev, &iio_event_fileops); - indio_dev->chrdev.owner = this_mod; + if (indio_dev->buffer || iio_dev_opaque->event_interface) { + indio_dev->dev.devt = MKDEV(MAJOR(iio_devt), indio_dev->id); + indio_dev->chrdev.owner = this_mod; + } ret = cdev_device_add(&indio_dev->chrdev, &indio_dev->dev); if (ret < 0)
We only need a chardev if we need to support buffers and/or events. With this change, a chardev will be created only if an IIO buffer is attached OR an event_interface is configured. Otherwise, no chardev will be created, and the IIO device will get registered with the 'device_add()' call. Quite a lot of IIO devices don't really need a chardev, so this is a minor improvement to the IIO core, as the IIO device will take up (slightly) fewer resources. In order to not create a chardev, we mostly just need to not initialize the indio_dev->dev.devt field. If that is un-initialized, cdev_device_add() behaves like device_add(). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> --- Changelog v1 -> v2: * https://lore.kernel.org/linux-iio/20201117162340.43924-2-alexandru.ardelean@analog.com/ * split away from series; I don't know when I will have time to re-visit the entire original series, so might as well move forward a few patches drivers/iio/industrialio-core.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)