From: Jonathan Cameron <jic23@kernel.org>
To: Rodrigo Alencar via B4 Relay
<devnull+rodrigo.alencar.analog.com@kernel.org>
Cc: rodrigo.alencar@analog.com,
Michael Auchter <michael.auchter@ni.com>,
linux@analog.com, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org,
Michael Hennerich <Michael.Hennerich@analog.com>,
David Lechner <dlechner@baylibre.com>,
Andy Shevchenko <andy@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>
Subject: Re: [PATCH 09/12] iio: dac: ad5686: implement new sync() op for the spi bus
Date: Wed, 3 Jun 2026 13:24:09 +0100 [thread overview]
Message-ID: <20260603132409.504ee84a@jic23-huawei> (raw)
In-Reply-To: <20260602-ad5686-new-features-v1-9-691e01883d27@analog.com>
On Tue, 02 Jun 2026 17:33:56 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Use of local SPI bus data to manage a collection of SPI transfers and
> flush them to the SPI platform driver with the sync() operation. This
> allows for faster handling of multiple channel DAC writes, avoiding kernel
> overhead per spi_sync() call, which will be helpful when enabling
> triggered buffer support.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Some minor stuff inline. Maybe it does make sense to adapt for a generic
solution in the spi core, maybe not but most of these comments apply anyway!
Jonathan
> ---
> drivers/iio/dac/ad5686-spi.c | 109 +++++++++++++++++++++++++++++++------------
> drivers/iio/dac/ad5686.c | 4 +-
> drivers/iio/dac/ad5686.h | 8 +++-
> drivers/iio/dac/ad5696-i2c.c | 2 +-
> 4 files changed, 88 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
> index 6b6ef1d7071f..66a5a2164395 100644
> --- a/drivers/iio/dac/ad5686-spi.c
> +++ b/drivers/iio/dac/ad5686-spi.c
> @@ -12,59 +12,81 @@
> #include <linux/errno.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/overflow.h>
> #include <linux/spi/spi.h>
>
> #include <asm/byteorder.h>
>
> #include "ad5686.h"
>
> +struct ad5686_spi_data {
> + struct spi_message msg;
> + unsigned int size;
Not obvious to me what size is from the naming. Maybe this
structure needs some documentation.
> + unsigned int capacity;
> + struct spi_transfer xfers[] __counted_by(capacity);
> +};
> +
> static int ad5686_spi_write(struct ad5686_state *st,
> u8 cmd, u8 addr, u16 val)
> {
> - struct spi_device *spi = to_spi_device(st->dev);
> - u8 tx_len, *buf;
> + struct ad5686_spi_data *bus_data = st->bus_data;
> + struct spi_transfer *xfer;
> +
> + if (bus_data->size >= bus_data->capacity)
> + return -E2BIG;
> +
> + if (bus_data->size)
> + bus_data->xfers[bus_data->size - 1].cs_change = 1;
> + else
> + spi_message_init(&bus_data->msg);
> +
> + xfer = &bus_data->xfers[bus_data->size];
> + xfer->rx_buf = NULL;
> + xfer->cs_change = 0;
These are both 'resets' to defaults and you are heavily relying
on other fields in that rather complex structure never being set.
Maybe initializing all the fields is simpler?
>
> switch (st->chip_info->regmap_type) {
> case AD5310_REGMAP:
> - st->data[0].d16 = cpu_to_be16(AD5310_CMD(cmd) |
> - val);
> - buf = &st->data[0].d8[0];
(why not use d16 here? Obviously this is original code, but applies
below)
> - tx_len = 2;
> + st->data[bus_data->size].d16 =
> + cpu_to_be16(AD5310_CMD(cmd) | val);
> + xfer->tx_buf = &st->data[bus_data->size].d8[0];
> + xfer->len = 2;
Following on from above on resetting xfer fields.
*xfer = (struct spi_transfers) {
.tx_buf = &st->data[bus_data->size].d16,
.len = sizeof(&st->data[bus_data->size.d16),
};
> break;
> case AD5683_REGMAP:
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
> - AD5683_DATA(val));
> - buf = &st->data[0].d8[1];
> - tx_len = 3;
> + st->data[bus_data->size].d32 =
> + cpu_to_be32(AD5686_CMD(cmd) | AD5683_DATA(val));
> + xfer->tx_buf = &st->data[bus_data->size].d8[1];
> + xfer->len = 3;
Similar use of designated initializer at small cost of clearing stuff
that is clear. I doubt that matters.
> break;
> case AD5686_REGMAP:
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
> - AD5686_ADDR(addr) |
> - val);
> - buf = &st->data[0].d8[1];
> - tx_len = 3;
> + st->data[bus_data->size].d32 =
> + cpu_to_be32(AD5686_CMD(cmd) | AD5686_ADDR(addr) | val);
> + xfer->tx_buf = &st->data[bus_data->size].d8[1];
> + xfer->len = 3;
same again.
> break;
> default:
> return -EINVAL;
> }
>
> - return spi_write(spi, buf, tx_len);
> + spi_message_add_tail(xfer, &bus_data->msg);
> + bus_data->size++;
> +
> + return 0;
> +}
> +
> +static int ad5686_spi_sync(struct ad5686_state *st)
> +{
> + struct spi_device *spi = to_spi_device(st->dev);
> + struct ad5686_spi_data *bus_data = st->bus_data;
> +
> + bus_data->size = 0; /* always reset, even on sync failure */
> + return spi_sync(spi, &bus_data->msg);
> }
>
> static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
> {
> - struct spi_transfer t[] = {
> - {
> - .tx_buf = &st->data[0].d8[1],
> - .len = 3,
> - .cs_change = 1,
> - }, {
> - .tx_buf = &st->data[1].d8[1],
> - .rx_buf = &st->data[2].d8[1],
> - .len = 3,
> - },
> - };
> struct spi_device *spi = to_spi_device(st->dev);
> + struct ad5686_spi_data *bus_data = st->bus_data;
> + struct spi_transfer *xfer = &bus_data->xfers[0];
> u8 cmd = 0;
> int ret;
>
> @@ -85,8 +107,18 @@ static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
> AD5686_ADDR(addr));
> st->data[1].d32 = cpu_to_be32(AD5686_CMD(AD5686_CMD_NOOP));
>
> - ret = spi_sync_transfer(spi, t, ARRAY_SIZE(t));
> - if (ret < 0)
> + xfer[0].tx_buf = &st->data[0].d8[1];
> + xfer[0].len = 3;
> + xfer[0].cs_change = 1;
> + xfer[1].tx_buf = &st->data[1].d8[1];
> + xfer[1].rx_buf = &st->data[2].d8[1];
> + xfer[1].len = 3;
> + xfer[1].cs_change = 0;
Similar to above - I'd initialize the lot as suggested up there.
Saves on effort thinking about it. Maybe the cost matters but I doubt it.
> +
> + spi_message_init_with_transfers(&bus_data->msg, xfer, 2);
> +
> + ret = spi_sync(spi, &bus_data->msg);
> + if (ret)
> return ret;
>
> return be32_to_cpu(st->data[2].d32);
> @@ -95,12 +127,27 @@ static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
> static const struct ad5686_bus_ops ad5686_spi_ops = {
> .write = ad5686_spi_write,
> .read = ad5686_spi_read,
> + .sync = ad5686_spi_sync,
> };
>
> static int ad5686_spi_probe(struct spi_device *spi)
> {
> - return ad5686_probe(&spi->dev, spi_get_device_match_data(spi),
> - spi->modalias, &ad5686_spi_ops);
> + const struct ad5686_chip_info *info = spi_get_device_match_data(spi);
> + struct ad5686_spi_data *bus_data;
> + unsigned int capacity;
> +
> + /* read operation requires at least 2 transfers */
> + capacity = max(info->num_channels, 2);
> + bus_data = devm_kzalloc(&spi->dev,
> + struct_size(bus_data, xfers, capacity),
> + GFP_KERNEL);
> + if (!bus_data)
> + return -ENOMEM;
> +
> + bus_data->capacity = capacity;
> +
> + return ad5686_probe(&spi->dev, info, spi->modalias, &ad5686_spi_ops,
> + bus_data);
> }
>
> static const struct spi_device_id ad5686_spi_id[] = {
next prev parent reply other threads:[~2026-06-03 12:24 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 16:33 [PATCH 00/12] New features for the AD5686 IIO driver Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 01/12] dt-bindings: iio: dac: ad5696: add reset/ldac/gain gpio support Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 02/12] dt-bindings: iio: dac: ad5696: rework on power supplies Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-03 15:25 ` Conor Dooley
2026-06-02 16:33 ` [PATCH 03/12] dt-bindings: iio: dac: ad5686: add reset/ldac/gain gpio support Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 04/12] dt-bindings: iio: dac: ad5686: rework on power supplies Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-03 15:29 ` Conor Dooley
2026-06-02 16:33 ` [PATCH 05/12] iio: dac: ad5686: add support for missing " Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:02 ` Andy Shevchenko
2026-06-03 12:17 ` Rodrigo Alencar
2026-06-04 5:51 ` Andy Shevchenko
2026-06-02 16:33 ` [PATCH 06/12] iio: dac: ad5686: consume optional reset signal Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:03 ` Andy Shevchenko
2026-06-03 8:28 ` Nuno Sá
2026-06-03 12:08 ` Jonathan Cameron
2026-06-03 12:57 ` Philipp Zabel
2026-06-08 8:29 ` Nuno Sá
2026-06-02 16:33 ` [PATCH 07/12] iio: dac: ad5686: add ldac gpio Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:05 ` Andy Shevchenko
2026-06-02 16:33 ` [PATCH 08/12] iio: dac: ad5686: introduce sync operation Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 16:33 ` [PATCH 09/12] iio: dac: ad5686: implement new sync() op for the spi bus Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:14 ` Andy Shevchenko
2026-06-03 12:26 ` Rodrigo Alencar
2026-06-03 12:55 ` Jonathan Cameron
2026-06-04 19:51 ` Andy Shevchenko
2026-06-03 12:24 ` Jonathan Cameron [this message]
2026-06-02 16:33 ` [PATCH 10/12] iio: dac: ad5686: add triggered buffer support Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:18 ` Andy Shevchenko
2026-06-03 12:41 ` Jonathan Cameron
2026-06-05 11:34 ` Rodrigo Alencar
2026-06-05 14:09 ` Jonathan Cameron
2026-06-05 14:40 ` Rodrigo Alencar
2026-06-02 16:33 ` [PATCH 11/12] iio: dac: ad5686: write_raw: use guard(mutex)() Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:20 ` Andy Shevchenko
2026-06-02 16:33 ` [PATCH 12/12] iio: dac: ad5686: add gain control support Rodrigo Alencar
2026-06-02 16:33 ` Rodrigo Alencar via B4 Relay
2026-06-02 19:25 ` Andy Shevchenko
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=20260603132409.504ee84a@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=devnull+rodrigo.alencar.analog.com@kernel.org \
--cc=dlechner@baylibre.com \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@analog.com \
--cc=michael.auchter@ni.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=rodrigo.alencar@analog.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.