From: Jonathan Cameron <jic23@kernel.org>
To: Marcelo Schmitt <marcelo.schmitt@analog.com>
Cc: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <nuno.sa@analog.com>,
<Michael.Hennerich@analog.com>, <dlechner@baylibre.com>,
<andy@kernel.org>, <robh@kernel.org>, <krzk+dt@kernel.org>,
<conor+dt@kernel.org>, <julianbraha@gmail.com>,
<marcelo.schmitt1@gmail.com>
Subject: Re: [PATCH v6 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
Date: Sun, 12 Jul 2026 02:53:03 +0100 [thread overview]
Message-ID: <20260712025303.014c02ed@jic23-huawei> (raw)
In-Reply-To: <965e5a31bf10cb49b53f7351266eeed55e8f6bd5.1783629101.git.marcelo.schmitt@analog.com>
On Thu, 9 Jul 2026 17:49:53 -0300
Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> Support for LTC2378-20 and similar analog-to-digital converters.
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> Change log v5 -> v6:
> - Added comment to clarify CPU endianness is used when device native BE is not.
> - Protected single sample read procedure with a mutex.
> - Dropped mod_devicetable.h, include device-id/spi.h device-id/of.h instead.
> - Used iwyu to add missing #includes and dropped superfluous ones.
> - Used pahole to minimize memory holes in LTC2378 data structures.
A small comment about maybe splitting the channel macro into offload and
non offload variants. That would also let you only bring the offload
version in as part of the next patch.
Jonathan
> diff --git a/drivers/iio/adc/ltc2378.c b/drivers/iio/adc/ltc2378.c
> new file mode 100644
> index 000000000000..c9f8b19e0298
> --- /dev/null
> +++ b/drivers/iio/adc/ltc2378.c
> +#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits, _offload) \
> +{ \
> + .type = IIO_VOLTAGE, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + (_offload ? BIT(IIO_CHAN_INFO_SAMP_FREQ) : 0), \
> + .info_mask_separate_available = _offload ? BIT(IIO_CHAN_INFO_SAMP_FREQ) : 0,\
> + .scan_index = 0, \
> + .scan_type = { \
> + .format = _sign ? IIO_SCAN_FORMAT_SIGNED_INT : \
> + IIO_SCAN_FORMAT_UNSIGNED_INT, \
> + .realbits = _real_bits, \
> + .storagebits = _storage_bits, \
> + .shift = (_offload ? 0 : _storage_bits - _real_bits), \
> + .endianness = _offload ? IIO_CPU : IIO_BE \
As below. I think, in my ideal world the offload parts of this would have
been in patch 3.
Given how much changes in here to me it's a bit marginal on whether having
LTC2378_DIFF_CHANNEL() and LTC2378_DIFF_CHANNEL_OFFLOAD() would have been simpler.
> + }, \
> +}
> +
> +struct ltc2378_state {
> + const struct ltc2378_chip_info *info;
> + struct gpio_desc *cnv_gpio;
> + struct spi_device *spi;
> + struct mutex lock; /* Protect data acquisition cycle */
> + int ref_uV;
> + struct spi_transfer xfer;
> +
> + /*
> + * DMA (thus cache coherency maintenance) requires the
> + * transfer buffers to live in their own cache lines.
Trivial but I'd wrap nearer 80 chars.
> + */
> + struct {
> + union {
> + __be16 sample_buf16_be;
> + __be32 sample_buf32_be;
> + u16 sample_buf16;
> + u32 sample_buf32;
I guess for churn reduction it is fine to introduce some stuff for
offload before the patch that does the majority of it..
> + } data;
> + aligned_s64 timestamp;
> + } scan __aligned(IIO_DMA_MINALIGN);
> +};
> +static int ltc2378_refin_setup(struct device *dev, struct ltc2378_state *st)
> +{
> + int ret;
> +
> + /*
> + * The internal reference buffer amplifies both the internal reference
> + * and REFIN by a factor of 2.
> + */
> + ret = devm_regulator_get_enable_read_voltage(dev, "refin");
> + if (ret == -ENODEV) /* refin is optional */
> + st->ref_uV = st->info->internal_ref_uV * 2;
Maybe
return 0;
as done
> + else if (ret < 0)
if (ret < 0)
return
> + return dev_err_probe(dev, ret, "failed to read refin regulator\n");
> + else
and then no else needed? It's a marginal improvement so I don't mind
if you ignore this suggestion.
> + st->ref_uV = ret * 2;
> +
> + return 0;
> +}
next prev parent reply other threads:[~2026-07-12 1:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 20:49 [PATCH v6 0/4] iio: adc: Add support for LTC2378 and similar ADCs Marcelo Schmitt
2026-07-09 20:49 ` [PATCH v6 1/4] dt-bindings: iio: adc: Add ltc2378 Marcelo Schmitt
2026-07-09 20:58 ` sashiko-bot
2026-07-10 21:06 ` Marcelo Schmitt
2026-07-09 20:49 ` [PATCH v6 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs Marcelo Schmitt
2026-07-09 21:04 ` sashiko-bot
2026-07-10 2:22 ` Jonathan Cameron
2026-07-11 15:45 ` David Lechner
2026-07-12 1:53 ` Jonathan Cameron [this message]
2026-07-09 20:50 ` [PATCH v6 3/4] iio: adc: ltc2378: Enable high-speed data capture Marcelo Schmitt
2026-07-09 23:24 ` sashiko-bot
2026-07-10 21:15 ` Marcelo Schmitt
2026-07-11 15:44 ` David Lechner
2026-07-09 20:50 ` [PATCH v6 4/4] iio: adc: ltc2378: Enable triggered buffer " Marcelo Schmitt
2026-07-11 15:49 ` [PATCH v6 0/4] iio: adc: Add support for LTC2378 and similar ADCs David Lechner
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=20260712025303.014c02ed@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=dlechner@baylibre.com \
--cc=julianbraha@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=marcelo.schmitt@analog.com \
--cc=nuno.sa@analog.com \
--cc=robh@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