Re: [PATCH v11 2/3] dt-bindings: iio: dac: Add AD5529R

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Schema incorrectly rejects standard properties from referenced schema
- [Low] Default value type mismatch for `spi-device-addr` array property
--

commit 1e8f5824a0d1b32d0615a8c9004b4c48496e77b0
Author: Janani Sunil <janani.sunil@analog.com>
Subject: dt-bindings: iio: dac: Add AD5529R

This commit adds device tree bindings for the Analog Devices AD5529R 
16-channel 12/16-bit high voltage DAC. It includes documentation for the 
SPI interface, power supplies, and individual channel configuration.

> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
> new file mode 100644
> index 0000000000000..9c390d460e5ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
[ ... ]
> +  spi-device-addr:
> +    minItems: 1
> +    maxItems: 4
> +    items:
> +      enum: [0, 1, 2, 3]
> +    default: 0

[Severity: Low]
Will this default value cause a schema validation warning?

Since spi-device-addr is defined as an array in the standard spi
peripheral properties (/schemas/spi/spi-peripheral-props.yaml), assigning
a scalar integer (0) as the default violates the array type expectation.

Should this be expressed as an array instead, such as default: [0]?

[ ... ]
> +patternProperties:
> +  "^channel@([0-9a-f]{1,2})$":
> +    $ref: dac.yaml
> +    type: object
> +    description: Child nodes for individual channel configuration
[ ... ]
> +    required:
> +      - reg
> +
> +    additionalProperties: false

[Severity: Medium]
Will this incorrectly block standard properties defined in dac.yaml from
being used in the child nodes?

Using additionalProperties: false here only considers the explicitly listed
local properties (reg and output-range-microvolt). If a device tree
includes standard IIO DAC properties (like label) defined in dac.yaml,
they will be rejected and cause false-positive validation errors during
dtbs_check.

Should this use unevaluatedProperties: false instead to properly validate
local properties alongside the referenced properties?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902-ad5529r-driver-v11-0-301c491a0719@analog.com?part=2