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

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Low] The `default: 0` value for `spi-device-addr` is a scalar integer, which violates the underlying `uint32-array` type.
- [Low] The `spi-cpol` and `spi-cpha` properties are referenced in dependencies but are omitted from the properties block.
- [Low] The use of `additionalProperties: false` in the channel node incorrectly restricts inherited properties from `dac.yaml`.
- [Low] The `default` annotations inside the `items` array for `output-range-microvolt` are ineffective.
--

--- Patch [2]: [PATCH v8 2/3] dt-bindings: iio: dac: Add AD5529R ---
commit c7fd92093d1e8febbb573957a72221de0c72a60c
Author: Janani Sunil <[email protected]>

dt-bindings: iio: dac: Add AD5529R

Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
buffered voltage output digital-to-analog converter (DAC) with an
integrated precision reference.

> 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]
Does this default value need to be an array (e.g., [0]) to conform to the
uint32-array type defined in spi-peripheral-props.yaml? A scalar value might
cause schema validation to fail for bindings relying on this default.

[ ... ]

> +      output-range-microvolt:
> +        description:
> +          Output voltage range for this channel as [min, max] in
> +          microvolts.
> +        oneOf:
> +          - items:
> +              - const: 0
> +                default: 0
> +              - enum: [5000000, 10000000, 20000000, 40000000]
> +                default: 5000000

[Severity: Low]
Should the default keyword be declared at the property level
(e.g., default: [0, 5000000]) rather than inside the items elements? 

It seems the schema tooling will not provide a default value when the
property is omitted if it is structured this way.

[ ... ]

> +    required:
> +      - reg
> +
> +    additionalProperties: false

[Severity: Low]
Should this be unevaluatedProperties: false instead?

In JSON schema, additionalProperties: false does not see through the $ref to
dac.yaml. This would cause common DAC channel properties inherited from
dac.yaml to be erroneously rejected by validation.

[ ... ]

> +dependencies:
> +  spi-cpha: [ spi-cpol ]
> +  spi-cpol: [ spi-cpha ]
> +
> +allOf:
> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +unevaluatedProperties: false

[Severity: Low]
Are spi-cpol and spi-cpha missing from the local properties block?

Since they are referenced in dependencies but not explicitly declared, device
trees configuring SPI Mode 3 might fail static validation due to
unevaluatedProperties: false not seeing them.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2