All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kim Seer Paller" <kimseer.paller@analog.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v4 6/6] iio: dac: ad3530r: Add support for AD3532R/AD3532
Date: Fri, 03 Jul 2026 10:30:13 +0000	[thread overview]
Message-ID: <20260703103014.8CF1B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260703-iio-ad3532r-support-v4-6-69d9a336f4e8@analog.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The max_register parameter in the regmap config is incorrectly set to the base address of the highest channel, preventing reading and writing 16-bit values for the last channel.
--

commit 977833b9e38150088aceb9bef325ef263ed54eee
Author: Kim Seer Paller <kimseer.paller@analog.com>

iio: dac: ad3530r: Add support for AD3532R/AD3532
    
This commit adds support for the AD3532 and AD3532R 16-channel 16-bit voltage
output DACs. It adds a new register map, channel specifications, and powerdown
handlers while reusing shared table-driven configuration steps.

> diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
> --- a/drivers/iio/dac/ad3530r.c
> +++ b/drivers/iio/dac/ad3530r.c
[ ... ]
> @@ -39,6 +40,25 @@
>  #define AD3531R_SW_LDAC_TRIG_A			0xDD
>  #define AD3531R_INPUT_CH			0xE3
>  
> +/* AD3532R/AD3532 bank 0 registers (channels 0-7) */
> +#define AD3532R_INTERFACE_CONFIG_A_0		0x1000
> +#define AD3532R_OUTPUT_OPERATING_MODE_0		0x1020
> +#define AD3532R_OUTPUT_OPERATING_MODE_1		0x1021
> +#define AD3532R_OUTPUT_CONTROL_0		0x102A
> +#define AD3532R_REFERENCE_CONTROL_0		0x103C
> +#define AD3532R_SW_LDAC_TRIG_0			0x10E5
> +#define AD3532R_INPUT_CH_0			0x10EB
> +
> +/* AD3532R/AD3532 bank 1 registers (channels 8-15) */
> +#define AD3532R_INTERFACE_CONFIG_A_1		0x3000
> +#define AD3532R_OUTPUT_OPERATING_MODE_2		0x3020
> +#define AD3532R_OUTPUT_OPERATING_MODE_3		0x3021
> +#define AD3532R_OUTPUT_CONTROL_1		0x302A
> +#define AD3532R_REFERENCE_CONTROL_1		0x303C
> +#define AD3532R_SW_LDAC_TRIG_1			0x30E5
> +#define AD3532R_INPUT_CH_1			0x30EB
> +#define AD3532R_MAX_REG_ADDR			0x30F9

[ ... ]

> @@ -369,12 +490,40 @@ static const unsigned int ad3531r_op_mode[] = {
>  	AD3530R_OUTPUT_OPERATING_MODE_0,
>  };
>  
> +static const unsigned int ad3532r_if_config[] = {
> +	AD3532R_INTERFACE_CONFIG_A_0,
> +	AD3532R_INTERFACE_CONFIG_A_1,
> +};
> +
[ ... ]
> +static const struct regmap_config ad3532r_regmap_config = {
> +	.reg_bits = 16,
> +	.val_bits = 8,
> +	.max_register = AD3532R_MAX_REG_ADDR,
> +};

[Severity: High]
Does this configuration prevent 16-bit reads and writes on the highest channel
(channel 15)?

Looking at ad3532r_input_ch_reg(), the input register for channel 15 resolves
to 0x30F9 (0x30EB + 2 * 7). Since ad3530r_dac_write() and ad3530r_read_raw()
both perform a 2-byte bulk regmap access starting at this address:

ad3530r_dac_write() {
    ...
    ret = regmap_bulk_write(st->regmap, st->chip_info->input_ch_reg(chan),
                            &st->buf, sizeof(st->buf));
    ...
}

Regmap will check if the start address + length - 1 <= max_register. For
channel 15, this evaluates to 0x30FA <= 0x30F9, which fails the bounds check
and returns -EINVAL.

Should AD3532R_MAX_REG_ADDR be set to 0x30FA to accommodate the second byte of
the final channel's input register?

(Note that AD3530R_MAX_REG_ADDR might also have this exact same issue for
channel 7 in the pre-existing code).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-iio-ad3532r-support-v4-0-69d9a336f4e8@analog.com?part=6

  reply	other threads:[~2026-07-03 10:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 10:10 [PATCH v4 0/6] Add support for AD3532R/AD3532 Kim Seer Paller
2026-07-03 10:10 ` [PATCH v4 1/6] iio: ABI: add DAC 10kohm_to_gnd powerdown mode Kim Seer Paller
2026-07-03 10:10 ` [PATCH v4 2/6] dt-bindings: iio: dac: add support for AD3532R/AD3532 Kim Seer Paller
2026-07-03 10:10 ` [PATCH v4 3/6] iio: dac: ad3530r: Convert sw_ldac_trig_reg to a function pointer Kim Seer Paller
2026-07-03 10:23   ` sashiko-bot
2026-07-03 12:25   ` Andy Shevchenko
2026-07-03 10:10 ` [PATCH v4 4/6] iio: dac: ad3530r: Refactor setup to table-driven register banks Kim Seer Paller
2026-07-03 12:27   ` Andy Shevchenko
2026-07-03 10:10 ` [PATCH v4 5/6] iio: dac: ad3530r: Make regmap_config selectable per chip Kim Seer Paller
2026-07-03 12:29   ` Andy Shevchenko
2026-07-03 10:10 ` [PATCH v4 6/6] iio: dac: ad3530r: Add support for AD3532R/AD3532 Kim Seer Paller
2026-07-03 10:30   ` sashiko-bot [this message]
2026-07-03 12:39   ` Andy Shevchenko
2026-07-04 23:53 ` [PATCH v4 0/6] " 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=20260703103014.8CF1B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kimseer.paller@analog.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 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.