From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Jonathan Santos <Jonathan.Santos@analog.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, cosmin.tanislav@analog.com,
lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org,
dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 3/3] iio: adc: ad4130: add new supported parts
Date: Mon, 2 Mar 2026 14:51:35 +0200 [thread overview]
Message-ID: <aaWH1wL8odeCmE6w@ashevche-desk.local> (raw)
In-Reply-To: <1d5baeec27724a1c8ebf909c29c3599d583948a1.1772078999.git.Jonathan.Santos@analog.com>
On Sat, Feb 28, 2026 at 09:39:04AM -0300, Jonathan Santos wrote:
> Add support for AD4129-4/8, AD4130-4, and AD4131-4/8 variants.
>
> The AD4129 series supports the same FIFO interface as the AD4130 but with
> reduced resolution (16-bit). The AD4131 series lacks FIFO support, so
> triggered buffer functionality is introduced.
>
> The 4-channel variants feature fewer analog inputs, GPIOs, and sparse pin
> mappings for VBIAS, analog inputs, and excitation currents. The driver now
> handles these differences with chip-specific configurations, including pin
> mappings and GPIO counts.
...
> +static const unsigned int ad4129_reg_size[] = {
> + [AD4130_STATUS_REG] = 1,
> + [AD4130_ADC_CONTROL_REG] = 2,
> + [AD4130_DATA_REG] = 2,
> + [AD4130_IO_CONTROL_REG] = 2,
> + [AD4130_VBIAS_REG] = 2,
> + [AD4130_ID_REG] = 1,
> + [AD4130_ERROR_REG] = 2,
> + [AD4130_ERROR_EN_REG] = 2,
> + [AD4130_MCLK_COUNT_REG] = 1,
> + [AD4130_CHANNEL_X_REG(0) ... AD4130_CHANNEL_X_REG(AD4130_MAX_CHANNELS - 1)] = 3,
> + [AD4130_CONFIG_X_REG(0) ... AD4130_CONFIG_X_REG(AD4130_MAX_SETUPS - 1)] = 2,
> + [AD4130_FILTER_X_REG(0) ... AD4130_FILTER_X_REG(AD4130_MAX_SETUPS - 1)] = 3,
> + [AD4130_OFFSET_X_REG(0) ... AD4130_OFFSET_X_REG(AD4130_MAX_SETUPS - 1)] = 2,
> + [AD4130_GAIN_X_REG(0) ... AD4130_GAIN_X_REG(AD4130_MAX_SETUPS - 1)] = 2,
> + [AD4130_MISC_REG] = 2,
> + [AD4130_FIFO_CONTROL_REG] = 3,
> + [AD4130_FIFO_STATUS_REG] = 1,
> + [AD4130_FIFO_THRESHOLD_REG] = 3,
> + [AD4130_FIFO_DATA_REG] = 2,
> +};
I hope this passes `make W=1` builds for both clang and GCC.
...
> +static const u8 ad4130_8_pin_map[] = {
> + 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, /* AIN0/VBIAS_0-AIN7/VBIAS_7 */
> + 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, /* AIN8/VBIAS_8-AIN15/VBIAS_15 */
These comments are hard to follow. Much better is
> +};
/* Pin mapping for AIN0..AIN15, VBIAS_0..VBIAS_15 */
static const u8 ad4130_8_pin_map[] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, /* 0 - 7 */
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, /* 8 - 15 */
};
...
> struct ad4130_chip_info {
> const char *name;
> unsigned int max_analog_pins;
> + unsigned int num_gpios;
> const struct iio_info *info;
> const unsigned int *reg_size;
> const unsigned int reg_size_length;
> + const u8 *pin_map;
> + bool has_fifo;
Ah, okay, so we fill the potential 4-byte gap from the previous patch.
> };
...
> + /* Triggered buffer data structure */
> + struct {
> + u32 channels[AD4130_MAX_CHANNELS];
> + s64 timestamp;
Use aligned_s64 type...
> + } scan __aligned(8);
...instead of this.
...
> +static irqreturn_t ad4130_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct ad4130_state *st = iio_priv(indio_dev);
> + unsigned int data_reg_size = ad4130_data_reg_size(st);
> + unsigned int num_en_chn = bitmap_weight(indio_dev->active_scan_mask,
> + iio_get_masklength(indio_dev));
Split this assignment. It's harder to read in the current form.
> + struct spi_transfer xfer = {
> + .rx_buf = st->scan.channels,
> + .len = data_reg_size * num_en_chn,
> + };
> + int ret;
> +
> + ret = spi_sync_transfer(st->spi, &xfer, 1);
> + if (ret < 0)
> + goto err_unlock;
> +
> + iio_push_to_buffers_with_timestamp(indio_dev, &st->scan,
> + iio_get_time_ns(indio_dev));
> +
> +err_unlock:
> + iio_trigger_notify_done(indio_dev->trig);
>
> return IRQ_HANDLED;
> }
...
> + /*
> + * In continuous read mode, when all samples are read, the data
> + * ready signal returns high until the next conversion result is
> + * ready. To exit this mode, the command must be sent when data
> + * ready is low. In order to ensure that condition, wait for the
> + * next interrupt (when the new conversion is finished), allowing
> + * data ready to return low before sending the exit command.
> + */
> + st->buffer_wait_for_irq = true;
> + ret = wait_for_completion_timeout(&st->completion,
> + msecs_to_jiffies(1000));
> + st->buffer_wait_for_irq = false;
> + if (!ret)
> + dev_warn(&st->spi->dev, "Conversion timed out\n");
Usage of 'ret' for semantically different (and IIRC unsigned) case is
confusing, perhaps
st->buffer_wait_for_irq = true;
if (wait_for_completion_timeout(&st->completion, msecs_to_jiffies(1000))
dev_warn(&st->spi->dev, "Conversion timed out\n");
st->buffer_wait_for_irq = false;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-03-02 12:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 12:38 [PATCH 0/3] iio: adc: ad4130: Add support for AD4129-4/8, AD4130-4, and AD4131-4/8 Jonathan Santos
2026-02-28 12:38 ` [PATCH 1/3] dt-bindings: iio: adc: ad4130: Add new supported parts Jonathan Santos
2026-03-03 6:50 ` Krzysztof Kozlowski
2026-02-28 12:38 ` [PATCH 2/3] iio: adc: ad4130: introduce chip info for future multidevice support Jonathan Santos
2026-03-02 12:39 ` Andy Shevchenko
2026-02-28 12:39 ` [PATCH 3/3] iio: adc: ad4130: add new supported parts Jonathan Santos
2026-03-02 12:51 ` Andy Shevchenko [this message]
2026-03-07 16:27 ` David Lechner
2026-03-07 17:01 ` Jonathan Cameron
2026-03-07 14:20 ` 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=aaWH1wL8odeCmE6w@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=Jonathan.Santos@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cosmin.tanislav@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.