Re: [PATCH v1 1/4] dt-bindings: iio: adc: Add ltc2378

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The YAML schema incorrectly models fallback compatible strings by grouping specific and fallback strings into a single-element list, rejecting actual fallback usage in the device tree.
- [Medium] `additionalProperties: false` is used instead of `unevaluatedProperties: false` alongside a common schema reference, causing erroneous schema validation failures for valid SPI properties.
--

commit e7c5954ec798a9962f4a29e46b3240e39219ef7e
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>

dt-bindings: iio: adc: Add ltc2378

This commit documents the device tree bindings for the Analog Devices LTC2378
and similar ADCs. It introduces a new YAML schema defining the compatible
strings, power supplies, interrupts, and SPI peripheral properties.

> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
[ ... ]
> +properties:
> +  compatible:
> +    oneOf:
> +      - enum:
> +          - adi,ltc2338-18
> +          - adi,ltc2369-18
> +          - adi,ltc2370-16
> +          - adi,ltc2379-18
> +          - adi,ltc2380-16
> +      - items:
> +          - enum:
> +              - adi,ltc2364-18
> +              - adi,ltc2364-16 # fallback compatible

Does this definition restrict the compatible property to an array of exactly
one string?

Grouping a specific variant and its fallback into a single enum under a
one-element items array natively rejects the standard device tree formatting
for a specific device paired with a fallback, such as:

compatible = "adi,ltc2364-18", "adi,ltc2364-16";

Should this list declare two discrete elements positionally instead, with the
specific variant first, followed by a const for the fallback string? This
pattern repeats for the other fallback compatibles below.

[ ... ]
> +required:
> +  - compatible
> +  - reg
> +  - vdd-supply
> +  - ovdd-supply
> +  - ref-supply
> +
> +additionalProperties: false

Does this introduce a regression where valid SPI peripheral properties are
erroneously rejected?

The binding includes a $ref to /schemas/spi/spi-peripheral-props.yaml# at
the top of the file, but concludes with additionalProperties: false. Since
additionalProperties only considers properties explicitly defined in this
specific properties block, device tree nodes using standard SPI properties
that are not manually redefined here (like spi-cpha or spi-cs-high) will
fail validation.

Should this be unevaluatedProperties: false instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779117444.git.marcelo.schmitt1@gmail.com?part=1