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
next prev parent 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.