Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kim Seer Paller" <kimseer.paller@analog.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: iio: dac: add adi,ad5710r.yaml
Date: Thu, 16 Jul 2026 08:13:00 +0000	[thread overview]
Message-ID: <20260716081301.182221F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260716-iio-ad5710r-upstream-v1-2-e848a4bb701f@analog.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `minimum` and `maximum` constraints on the channel `reg` property are incorrectly wrapped in an `items` list schema, causing them to be silently ignored by the JSON Schema validator.
- [Medium] The binding introduces a custom global property `adi,range-double` to configure the voltage range, which contradicts the hardware's per-channel capability and ignores standard IIO properties.
--

--- Patch [2]: [PATCH 2/3] dt-bindings: iio: dac: add adi,ad5710r.yaml ---
commit cd748f09cddc4b7eb091c3829a62e52f260a76b0
Author: Kim Seer Paller <kimseer.paller@analog.com>

dt-bindings: iio: dac: add adi,ad5710r.yaml

This commit adds device tree bindings for the Analog Devices AD5710R/AD5711R
8-channel 12-/16-bit Configurable IDAC/VDAC.

> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5710r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5710r.yaml
> new file mode 100644
> index 0000000000000..17c1bf0092421
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5710r.yaml
> @@ -0,0 +1,143 @@

[ ... ]

> +description: |
> +  The AD5710R (16-bit) and AD5711R (12-bit) are 8-channel, low-power,
> +  configurable current/voltage output digital-to-analog converters (DACs) with
> +  an on-chip 2.5V, 3ppm/°C reference. Each channel can be independently
> +  configured as a voltage output (0V to VREF or 0V to 2xVREF) or a current

[ ... ]

> +  adi,range-double:
> +    description:
> +      Configure the output range for all channels. If the property is present,
> +      the output will range from 0V to 2Vref. If the property is not present,
> +      the output will range from 0V to Vref.
> +    type: boolean

[Severity: Medium]
The description above explicitly states that "Each channel can be independently
configured as a voltage output (0V to VREF or 0V to 2xVREF)". Does defining
this as a global property artificially limit the hardware's per-channel
capabilities?

Also, since the schema includes dac.yaml, could the standard per-channel
property output-range-microvolt be used instead of defining a custom global
boolean?

[ ... ]

> +patternProperties:
> +  "^channel@[0-7]$":
> +    $ref: /schemas/iio/dac/dac.yaml#
> +    type: object
> +    description:
> +      Represents the external channels which are connected to the DAC.
> +
> +    properties:
> +      reg:
> +        description: Channel number
> +        items:
> +          minimum: 0
> +          maximum: 7

[Severity: Medium]
Are these minimum and maximum constraints incorrectly wrapped in an items
list?

Since JSON Schema ignores numeric keywords when applied to an array type,
will these bounds be silently bypassed during dt_binding_check validation,
allowing out-of-bounds reg values? Should the minimum and maximum
constraints be placed directly under the reg property instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716-iio-ad5710r-upstream-v1-0-e848a4bb701f@analog.com?part=2

  reply	other threads:[~2026-07-16  8:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16  7:59 [PATCH 0/3] Add AD5710R/AD5711R DAC Kim Seer Paller
2026-07-16  7:59 ` [PATCH 1/3] iio: ABI: add DAC high_z powerdown mode and current output entries Kim Seer Paller
2026-07-16  7:59 ` [PATCH 2/3] dt-bindings: iio: dac: add adi,ad5710r.yaml Kim Seer Paller
2026-07-16  8:13   ` sashiko-bot [this message]
2026-07-16  7:59 ` [PATCH 3/3] iio: dac: ad5710r: Add driver for AD5710R and AD5711R Kim Seer Paller
2026-07-16  8:12   ` sashiko-bot

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=20260716081301.182221F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox