Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kurt Borja" <kuurtb@gmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 10/10] iio: adc: ti-ads1262: support common mode supplies
Date: Fri, 28 Aug 2026 07:03:15 +0000	[thread overview]
Message-ID: <20260828070316.66BC61F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260828-ads126x-v4-10-1dc27e9c0260@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `rx` buffer in `struct ads1262` lacks the `__aligned(IIO_DMA_MINALIGN)` attribute, causing it to share a cacheline with `tx`.
--

commit f75cefb819b551b39349e21259c13e70e46354c3
Author: Kurt Borja <kuurtb@gmail.com>
Subject: iio: adc: ti-ads1262: support common mode supplies

This commit enables common mode regulators for the ADS1262 ADC driver. It
adds support for parsing these supplies during probe and applying the common
mode voltage offsets to raw voltage readings.

> diff --git a/drivers/iio/adc/ti-ads1262.c b/drivers/iio/adc/ti-ads1262.c
> index 4784142f35c9d..c7ad1cf1a15d5 100644
> --- a/drivers/iio/adc/ti-ads1262.c
> +++ b/drivers/iio/adc/ti-ads1262.c
> @@ -240,6 +240,7 @@ struct ads1262 {
>  	u32 rref_ohms[ADS1262_EXT_REF_COUNT][ADS1262_EXT_REF_COUNT];
>  	int refp_uV[ADS1262_EXT_REF_COUNT];
>  	int refn_uV[ADS1262_EXT_REF_COUNT];
> +	int common_mode_uV[ADS1262_INPMUX_AINCOM + 1];
>  	IIO_DECLARE_BUFFER_WITH_TS(__be32, scan_buffer,
>  				   ADS1262_FW_CHANNEL_COUNT +
>  				   ADS1262_MON_CHANNEL_COUNT);

[Severity: Medium]
Does the rx buffer at the end of this struct need an alignment attribute?

Looking at the layout of struct ads1262, the tx and rx buffers are defined
as:

    u8 tx[ADS1262_SPI_XFER_SZ] __aligned(IIO_DMA_MINALIGN);
    u8 rx[ADS1262_SPI_XFER_SZ];

Because rx lacks the __aligned(IIO_DMA_MINALIGN) attribute, it can share a
cacheline with the preceding tx buffer. C struct layout rules do not add
padding after an aligned array unless the subsequent member requires it.

Since these buffers are mapped separately by the SPI core (DMA_TO_DEVICE
and DMA_FROM_DEVICE respectively), could this violate the DMA API rule that
DMA buffers must not share cachelines with other separately mapped data? 
This seems like it would trigger a warning when CONFIG_DMA_API_DEBUG is
enabled during SPI transfers.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828-ads126x-v4-0-1dc27e9c0260@gmail.com?part=10

      reply	other threads:[~2026-08-28  7:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  6:38 [PATCH v4 00/10] iio: adc: Add TI ADS126X ADC family support Kurt Borja
2026-08-28  6:38 ` [PATCH v4 01/10] dt-bindings: adc: add excitation-current-chopping property Kurt Borja
2026-08-28 16:33   ` Conor Dooley
2026-08-28  6:38 ` [PATCH v4 02/10] dt-bindings: iio: adc: support the TI ADS126x ADC family Kurt Borja
2026-08-28  6:45   ` sashiko-bot
2026-08-28 16:39   ` Conor Dooley
2026-08-28  6:38 ` [PATCH v4 03/10] iio: adc: add the ti-ads1262 driver Kurt Borja
2026-08-28  6:52   ` sashiko-bot
2026-08-28  8:09   ` Andy Shevchenko
2026-08-28  6:38 ` [PATCH v4 04/10] iio: adc: ti-ads1262: support per-channel sampling frequency Kurt Borja
2026-08-28  7:03   ` sashiko-bot
2026-08-28  6:38 ` [PATCH v4 05/10] iio: adc: ti-ads1262: support per-channel reference and gain Kurt Borja
2026-08-28  6:38 ` [PATCH v4 06/10] iio: adc: ti-ads1262: support input chopping Kurt Borja
2026-08-28  6:38 ` [PATCH v4 07/10] iio: adc: ti-ads1262: support excitation currents Kurt Borja
2026-08-28  6:57   ` sashiko-bot
2026-08-28  6:38 ` [PATCH v4 08/10] iio: adc: ti-ads1262: support triggered buffer sampling Kurt Borja
2026-08-28  6:57   ` sashiko-bot
2026-08-28  6:38 ` [PATCH v4 09/10] iio: adc: ti-ads1262: support REFOUT and VBIAS regulators Kurt Borja
2026-08-28  6:53   ` sashiko-bot
2026-08-28  6:38 ` [PATCH v4 10/10] iio: adc: ti-ads1262: support common mode supplies Kurt Borja
2026-08-28  7:03   ` sashiko-bot [this message]

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=20260828070316.66BC61F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kuurtb@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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