From: Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org>
To: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-iio@vger.kernel.org
Cc: Olivier MOYSAN <olivier.moysan@foss.st.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Nuno Sa <nuno.sa@analog.com>
Subject: [PATCH 00/12] iio: add new backend framework
Date: Tue, 21 Nov 2023 11:20:13 +0100 [thread overview]
Message-ID: <20231121-dev-iio-backend-v1-0-6a3d542eba35@analog.com> (raw)
Hi all,
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()
(typical provider - consumer stuff)
This is the result of the discussions in [1] and [2]. In short, both ADI
and STM wanted some way to control/get configurations from a kind of
IIO aggregate device. So discussions were made to have something that
serves and can be used by everyone.
The main differences with the converter framework RFC [1]:
1) Dropped the component framework. One can get more overview about
the concerns on the references but the main reasons were:
* Relying on providing .remove() callbacks to be allowed to use device
managed functions. I was not even totally sure about the correctness
of it and in times where everyone tries to avoid that driver
callback, it could lead to some maintenance burden.
* Scalability issues. As mentioned in [2], to support backends defined
in FW child nodes was not so straightforward with the component
framework.
* Device links can already do some of the things that made me
try the component framework (eg: removing consumers on suppliers
unbind).
2) Only support the minimal set of functionality to have the devices in
the same state as before using the backend framework. New features
will be added afterwards.
3) Moved the API docs into the .c files.
4) Moved the framework to the IIO top dir and renamed it to
industrialio-backend.c.
Also, as compared with the RFC in [2], I don't think there are that many
similarities other than the filename. However, it should now be pretty
straight for Olivier to build on top of it. Also to mention that I did
grabbed patch 1 ("of: property: add device link support for
io-backends") from that series and just did some minor changes:
1) Renamed the property from "io-backend" to "io-backends".
2) No '#io-backend-cells' as it's not supported/needed by the framework
(at least for now) .
Regarding the driver core patch
("driver: core: allow modifying device_links flags"), it is more like a
RFC one. I'm not really sure if the current behavior isn't just
expected/wanted. Since I could not really understand if it is or not
(or why the different handling DL_FLAG_AUTOREMOVE_CONSUMER vs
DL_FLAG_AUTOREMOVE_SUPPLIER), I'm sending out the patch.
Jonathan,
I also have some fixes and cleanups for the ad9467 driver. I added
Fixes tags but I'm not sure if it's really worth it to backport them (given
what we already discussed about these drivers). I'll leave that to you
:).
I'm also not sure if I'm missing some tags (even though the series
is frankly different from [2]).
Olivier,
If you want to be included as a Reviewer let me know and I'll happily do
so in the next version.
Also regarding the new IIO fw schemas. Should I send patches/PR to:
https://github.com/devicetree-org/dt-schema/
? Or is there any other workflow for it?
[1]: https://lore.kernel.org/linux-iio/20230727150324.1157933-1-olivier.moysan@foss.st.com/
[2]: https://lore.kernel.org/linux-iio/20230727150324.1157933-1-olivier.moysan@foss.st.com/
---
Nuno Sa (11):
driver: core: allow modifying device_links flags
iio: add the IIO backend framework
iio: adc: ad9467: fix reset gpio handling
iio: adc: ad9467: don't ignore error codes
iio: adc: ad9467: add mutex to struct ad9467_state
iio: adc: ad9467: fix scale setting
iio: adc: ad9467: use spi_get_device_match_data()
iio: adc: ad9467: use chip_info variables instead of array
iio: adc: ad9467: convert to backend framework
iio: adc: adi-axi-adc: convert to regmap
iio: adc: adi-axi-adc: move to backend framework
Olivier Moysan (1):
of: property: add device link support for io-backends
MAINTAINERS | 7 +
drivers/base/core.c | 14 +-
drivers/iio/Kconfig | 5 +
drivers/iio/Makefile | 1 +
drivers/iio/adc/Kconfig | 3 +-
drivers/iio/adc/ad9467.c | 382 +++++++++++++++++++++-----------
drivers/iio/adc/adi-axi-adc.c | 429 +++++++-----------------------------
drivers/iio/industrialio-backend.c | 302 +++++++++++++++++++++++++
drivers/of/property.c | 2 +
include/linux/iio/adc/adi-axi-adc.h | 4 +
include/linux/iio/backend.h | 58 +++++
11 files changed, 723 insertions(+), 484 deletions(-)
Thanks!
- Nuno Sá
next reply other threads:[~2023-11-21 10:17 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 10:20 Nuno Sa via B4 Relay [this message]
2023-11-21 10:20 ` [PATCH 01/12] driver: core: allow modifying device_links flags Nuno Sa via B4 Relay
2023-11-21 10:20 ` [PATCH 02/12] of: property: add device link support for io-backends Nuno Sa via B4 Relay
2023-11-21 10:20 ` [PATCH 03/12] iio: add the IIO backend framework Nuno Sa via B4 Relay
2023-12-04 15:38 ` Jonathan Cameron
2023-12-06 12:05 ` Nuno Sá
2023-12-06 17:15 ` Jonathan Cameron
2023-11-21 10:20 ` [PATCH 04/12] iio: adc: ad9467: fix reset gpio handling Nuno Sa via B4 Relay
2023-11-30 21:41 ` David Lechner
2023-12-01 8:47 ` Nuno Sá
2023-12-01 17:01 ` David Lechner
2023-12-02 8:36 ` Nuno Sá
2023-12-04 15:15 ` Jonathan Cameron
2023-12-04 16:41 ` Nuno Sá
2023-11-21 10:20 ` [PATCH 05/12] iio: adc: ad9467: don't ignore error codes Nuno Sa via B4 Relay
2023-11-30 21:44 ` David Lechner
2023-12-01 8:47 ` Nuno Sá
2023-12-04 15:19 ` Jonathan Cameron
2023-11-21 10:20 ` [PATCH 06/12] iio: adc: ad9467: add mutex to struct ad9467_state Nuno Sa via B4 Relay
2023-11-30 21:50 ` David Lechner
2023-12-01 8:49 ` Nuno Sá
2023-12-04 15:21 ` Jonathan Cameron
2023-12-04 15:23 ` Jonathan Cameron
2023-12-04 16:10 ` Nuno Sá
2023-12-04 16:51 ` Jonathan Cameron
2023-11-21 10:20 ` [PATCH 07/12] iio: adc: ad9467: fix scale setting Nuno Sa via B4 Relay
2023-11-21 10:20 ` [PATCH 08/12] iio: adc: ad9467: use spi_get_device_match_data() Nuno Sa via B4 Relay
2023-11-21 10:20 ` [PATCH 09/12] iio: adc: ad9467: use chip_info variables instead of array Nuno Sa via B4 Relay
2023-12-04 15:25 ` Jonathan Cameron
2023-12-04 16:24 ` Nuno Sá
2023-11-21 10:20 ` [PATCH 10/12] iio: adc: ad9467: convert to backend framework Nuno Sa via B4 Relay
2023-11-22 0:54 ` kernel test robot
2023-11-30 23:30 ` David Lechner
2023-12-01 0:12 ` David Lechner
2023-12-01 9:08 ` Nuno Sá
2023-12-01 17:44 ` David Lechner
2023-12-02 8:46 ` Nuno Sá
2023-12-04 8:56 ` Nuno Sá
2023-12-04 15:48 ` Jonathan Cameron
2023-12-04 16:23 ` Nuno Sá
2023-12-04 16:57 ` Jonathan Cameron
2023-12-01 9:17 ` Nuno Sá
2023-11-21 10:20 ` [PATCH 11/12] iio: adc: adi-axi-adc: convert to regmap Nuno Sa via B4 Relay
2023-12-04 15:51 ` Jonathan Cameron
2023-12-04 16:15 ` Nuno Sá
2023-11-21 10:20 ` [PATCH 12/12] iio: adc: adi-axi-adc: move to backend framework Nuno Sa via B4 Relay
2023-11-21 23:27 ` kernel test robot
2023-11-25 7:42 ` kernel test robot
2023-11-30 23:33 ` David Lechner
2023-12-01 8:50 ` Nuno Sá
2023-11-23 17:36 ` [PATCH 00/12] iio: add new " Olivier MOYSAN
2023-11-24 9:15 ` Nuno Sá
2023-11-30 23:54 ` David Lechner
2023-12-01 8:41 ` Nuno Sá
2023-12-01 9:14 ` Nuno Sá
2023-12-02 3:53 ` David Lechner
2023-12-02 9:37 ` Nuno Sá
2023-12-02 16:16 ` David Lechner
2023-12-04 14:49 ` Jonathan Cameron
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=20231121-dev-iio-backend-v1-0-6a3d542eba35@analog.com \
--to=devnull+nuno.sa.analog.com@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).