From: Jonathan Cameron <jic23@kernel.org>
To: Nuno Sa <nuno.sa@analog.com>
Cc: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Olivier Moysan <olivier.moysan@foss.st.com>
Subject: Re: [PATCH v4 6/8] iio: add the IIO backend framework
Date: Thu, 21 Dec 2023 17:44:37 +0000 [thread overview]
Message-ID: <20231221174437.5935a5c3@jic23-huawei> (raw)
In-Reply-To: <20231220-iio-backend-v4-6-998e9148b692@analog.com>
On Wed, 20 Dec 2023 16:34:09 +0100
Nuno Sa <nuno.sa@analog.com> wrote:
> This is a Framework to handle complex IIO aggregate devices.
>
> The typical architecture is to have one device as the frontend device which
> can be "linked" against one or multiple backend devices. All the IIO and
> userspace interface is expected to be registers/managed by the frontend
> device which will callback into the backends when needed (to get/set
> some configuration that it does not directly control).
>
> The basic framework interface is pretty simple:
> - Backends should register themselves with @devm_iio_backend_register()
> - Frontend devices should get backends with @devm_iio_backend_get()
>
> Signed-off-by: Nuno Sa <nuno.sa@analog.com>
A few minor comments, but seems good to me otherwise.
Jonathan
> ---
> MAINTAINERS | 8 +
> drivers/iio/Kconfig | 5 +
> drivers/iio/Makefile | 1 +
> drivers/iio/industrialio-backend.c | 456 +++++++++++++++++++++++++++++++++++++
> include/linux/iio/backend.h | 75 ++++++
> 5 files changed, 545 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3029841e92a8..df5f5b988926 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10334,6 +10334,14 @@ L: linux-media@vger.kernel.org
> S: Maintained
> F: drivers/media/rc/iguanair.c
>
> +IIO BACKEND FRAMEWORK
> +M: Nuno Sa <nuno.sa@analog.com>
> +R: Olivier Moysan <olivier.moysan@foss.st.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: drivers/iio/industrialio-backend.c
> +F: include/linux/iio/backend.h
> +
> IIO DIGITAL POTENTIOMETER DAC
> M: Peter Rosin <peda@axentia.se>
> L: linux-iio@vger.kernel.org
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 52eb46ef84c1..451671112f73 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -71,6 +71,11 @@ config IIO_TRIGGERED_EVENT
> help
> Provides helper functions for setting up triggered events.
>
> +config IIO_BACKEND
> + tristate
> + help
> + Framework to handle complex IIO aggregate devices.
Add some more description here. Not sure the current text will help
anyone understand it :)
> +
> source "drivers/iio/accel/Kconfig"
> source "drivers/iio/adc/Kconfig"
> source "drivers/iio/addac/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index 9622347a1c1b..0ba0e1521ba4 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_IIO_GTS_HELPER) += industrialio-gts-helper.o
> obj-$(CONFIG_IIO_SW_DEVICE) += industrialio-sw-device.o
> obj-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
> obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
> +obj-$(CONFIG_IIO_BACKEND) += industrialio-backend.o
>
> obj-y += accel/
> obj-y += adc/
> diff --git a/drivers/iio/industrialio-backend.c b/drivers/iio/industrialio-backend.c
> new file mode 100644
> index 000000000000..75a0a66003e1
> --- /dev/null
> +++ b/drivers/iio/industrialio-backend.c
> @@ -0,0 +1,456 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Framework to handle complex IIO aggregate devices.
> + *
> + * The typical architecture is to have one device as the frontend device which
> + * can be "linked" against one or multiple backend devices. All the IIO and
> + * userspace interface is expected to be registers/managed by the frontend
> + * device which will callback into the backends when needed (to get/set some
> + * configuration that it does not directly control).
> + *
> + * The framework interface is pretty simple:
> + * - Backends should register themselves with @devm_iio_backend_register()
> + * - Frontend devices should get backends with @devm_iio_backend_get()
> + *
> + * Also to note that the primary target for this framework are converters like
> + * ADC/DACs so @iio_backend_ops will have some operations typical of converter
> + * devices. On top of that, this is "generic" for all IIO which means any kind
> + * of device can make use of the framework. That said, If the @iio_backend_ops
> + * struct begins to grow out of control, we can always refactor things so that
> + * the industrialio-backend.c is only left with the really generic stuff. Then,
> + * we can build on top of it depending on the needs.
> + *
> + * Copyright (C) 2023 Analog Devices Inc.
> + */
> +#define pr_fmt(fmt) "iio-backend: " fmt
> +
> +#include <linux/cleanup.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/list.h>
> +#include <linux/lockdep.h>
> +#include <linux/kref.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +
> +#include <linux/iio/backend.h>
> +
> +struct iio_backend {
> + struct list_head entry;
> + const struct iio_backend_ops *ops;
> + struct device *dev;
> + struct module *owner;
> + void *priv;
> + /*
> + * mutex used to synchronize backend callback access with concurrent
> + * calls to @iio_backend_unregister. The lock makes sure a device is
> + * not unregistered while a callback is being run.
> + */
> + struct mutex lock;
> + struct kref ref;
> +};
> +
...
> +
> +static void iio_backend_release(void *arg)
> +{
> + struct iio_backend *back = arg;
> +
> + module_put(back->owner);
> + kref_put(&back->ref, iio_backend_free);
> +}
> +
> +static int __devm_iio_backend_get(struct device *dev, struct iio_backend *back)
> +{
> + struct device_link *link;
> + int ret;
> +
> + kref_get(&back->ref);
> + if (!try_module_get(back->owner)) {
> + pr_err("%s: Cannot get module reference\n", dev_name(dev));
Why do you need the reference? Good to add a comment on that here.
> + return -ENODEV;
> + }
> +
> + ret = devm_add_action_or_reset(dev, iio_backend_release, back);
> + if (ret)
> + return ret;
> +
> + link = device_link_add(dev, back->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
> + if (!link)
> + pr_warn("%s: Could not link to supplier(%s)\n", dev_name(dev),
> + dev_name(back->dev));
Why is that not an error and we try to carry on?
> +
> + pr_debug("%s: Found backend(%s) device\n", dev_name(dev),
> + dev_name(back->dev));
> + return 0;
> +}
> +
> +/**
> + * devm_iio_backend_get - Get a backend device
> + * @dev: Device where to look for the backend.
> + * @name: Backend name.
> + *
> + * Get's the backend associated with @dev.
> + *
> + * RETURNS:
> + * A backend pointer, negative error pointer otherwise.
> + */
> +struct iio_backend *devm_iio_backend_get(struct device *dev, const char *name)
> +{
> + struct fwnode_handle *fwnode;
> + struct iio_backend *back;
> + int index = 0, ret;
> +
> + if (name) {
> + index = device_property_match_string(dev, "io-backends-names",
> + name);
> + if (index < 0)
> + return ERR_PTR(index);
> + }
> +
> + fwnode = fwnode_find_reference(dev_fwnode(dev), "io-backends", index);
> + if (IS_ERR(fwnode)) {
> + /* not an error if optional */
> + pr_debug("%s: Cannot get Firmware reference\n", dev_name(dev));
> + return ERR_CAST(fwnode);
> + }
> +
> + guard(mutex)(&iio_back_lock);
> + list_for_each_entry(back, &iio_back_list, entry) {
> + if (!device_match_fwnode(back->dev, fwnode))
> + continue;
> +
> + fwnode_handle_put(fwnode);
> + ret = __devm_iio_backend_get(dev, back);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + return back;
> + }
> +
> + fwnode_handle_put(fwnode);
FYI. I have a series doing auto cleanup of fwnode_handles in progress.
Should get some time over the weekend to snd that out. Aim is to avoid need
to dance around manually freeing them (similar to the DT __free(device_node)
series I posted the other day).
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +EXPORT_SYMBOL_NS_GPL(devm_iio_backend_get, IIO_BACKEND);
> +
> +/**
> + * devm_iio_backend_get_optional - Get optional backend device
> + * @dev: Device where to look for the backend.
> + * @name: Backend name.
> + *
> + * Same as @devm_iio_backend_get() but return NULL if backend not found.
> + *
> + * RETURNS:
> + * A backend pointer, negative error pointer otherwise or NULL if not found.
> + */
> +struct iio_backend *devm_iio_backend_get_optional(struct device *dev,
> + const char *name)
> +{
> + struct iio_backend *back;
> +
> + back = devm_iio_backend_get(dev, name);
> + if (IS_ERR(back) && PTR_ERR(back) == -ENOENT)
> + return NULL;
> +
> + return back;
> +}
> +EXPORT_SYMBOL_NS_GPL(devm_iio_backend_get_optional, IIO_BACKEND);
I'm not convinced the optional variant is worth while. Could just choose
a particular return value to mean that e.g. ERR_PTR(-ENOENT) and document
it for the normal get. Then have special handling in the drivers where
you need backwards compatibility with a previous approach.
I'd rather pay the complexity price in a couple of drivers than have
to explain backends aren't typically optional for years to come.
> +
> +/**
> + * devm_iio_backend_get_from_fwnode_lookup
> + * @dev: Device where to bind the backend lifetime.
> + * @fwnode: Firmware node of the backend device.
> + *
> + * It directly looks the backend device list for a device matching @fwnode.
I would word this:
Search the backend list for a device matchign &fwnode.
> + * This API should not be used and it's only present for preventing the first
> + * user of this framework to break it's DT ABI.
You could stick a __ in front of the name to hopefully scare people away :)
+ highlight something odd is going on to reviewers seeing this called in
some future driver.
Also I can we might convert other drivers that are doing similar things
(dfsdm for example) and maybe this will be useful
so __devm_iio_backend_get_from_fwnode_lookup() and
"preventing breakage of old DT bindings".
> + *
> + * RETURNS:
> + * A backend pointer, negative error pointer otherwise.
> + */
> +struct iio_backend *
> +devm_iio_backend_get_from_fwnode_lookup(struct device *dev,
> + struct fwnode_handle *fwnode)
> +{
> + struct iio_backend *back;
> + int ret;
> +
> + guard(mutex)(&iio_back_lock);
> + list_for_each_entry(back, &iio_back_list, entry) {
> + if (!device_match_fwnode(back->dev, fwnode))
> + continue;
> +
> + ret = __devm_iio_backend_get(dev, back);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + return back;
> + }
> +
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +EXPORT_SYMBOL_NS_GPL(devm_iio_backend_get_from_fwnode_lookup, IIO_BACKEND);
next prev parent reply other threads:[~2023-12-21 17:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 15:34 [PATCH v4 0/8] iio: add new backend framework Nuno Sa
2023-12-20 15:34 ` [PATCH v4 1/8] dt-bindings: adc: ad9467: add new io-backend property Nuno Sa
2023-12-20 16:56 ` Rob Herring
2023-12-21 17:21 ` Jonathan Cameron
2023-12-21 22:46 ` Rob Herring
2023-12-20 15:34 ` [PATCH v4 2/8] dt-bindings: adc: axi-adc: deprecate 'adi,adc-dev' Nuno Sa
2023-12-21 17:25 ` Jonathan Cameron
2023-12-22 9:07 ` Nuno Sá
2023-12-26 15:55 ` Jonathan Cameron
2023-12-20 15:34 ` [PATCH v4 3/8] driver: core: allow modifying device_links flags Nuno Sa
2023-12-20 15:34 ` [PATCH v4 4/8] of: property: add device link support for io-backends Nuno Sa
2023-12-21 22:47 ` Rob Herring
2024-01-03 21:39 ` David Lechner
2024-01-09 11:23 ` Nuno Sá
2023-12-20 15:34 ` [PATCH v4 5/8] iio: buffer-dmaengine: export buffer alloc and free functions Nuno Sa
2023-12-20 15:34 ` [PATCH v4 6/8] iio: add the IIO backend framework Nuno Sa
2023-12-21 17:44 ` Jonathan Cameron [this message]
2023-12-22 9:39 ` Nuno Sá
2023-12-26 15:59 ` Jonathan Cameron
2024-01-09 12:15 ` Nuno Sá
2024-01-10 9:16 ` Jonathan Cameron
2024-01-10 10:37 ` Nuno Sá
2024-01-11 15:07 ` Olivier MOYSAN
2023-12-20 15:34 ` [PATCH v4 7/8] iio: adc: ad9467: convert to " Nuno Sa
2023-12-21 17:52 ` Jonathan Cameron
2023-12-22 9:10 ` Nuno Sá
2023-12-20 15:34 ` [PATCH v4 8/8] iio: adc: adi-axi-adc: move " Nuno Sa
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=20231221174437.5935a5c3@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
/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