Re: [PATCH v2 5/8] dt-bindings: iio: adc: add ti,ads122c14

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] The pattern property regex for channel nodes `^channel@[0-7a-f]$` omits digits 8 and 9, rejecting valid node addresses.
- [High] The `burn-out-current-nanoamp` property applies an `enum` constraint directly to an array, which will fail DT validation.
- [Medium] The commit message explicitly claims to reuse the custom 'ti,vref-source' property, but the code actually implements the standard 'reference-sources' property instead.
- [Medium] The JSON schema reference `$ref: adc.yaml` is missing the `#` fragment or the absolute path.
- [Medium] The `reference-sources` property lacks a `maxItems` constraint and leaves subsequent elements unvalidated.
- [Low] Strict index ordering in `interrupts` clashes with unordered `interrupt-names`, causing invalid semantics if only one interrupt is used.
--

commit de052c7080b8c89f1a3c4b730b190d119eacb414
Author: David Lechner (TI) <dlechner@baylibre.com>

dt-bindings: iio: adc: add ti,ads122c14

Add new bindings for ti,ads122c14 and similar devices primarily intended for
use with temperature sensors. These bindings introduce channel-specific
properties to handle per-measurement reference voltage and current output
requirements.

> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> have preferred an enum of strings).

[Severity: Medium]
The commit message explicitly states it reuses the 'ti,vref-source' property,
but the schema actually implements the standard 'reference-sources' property
instead. Should the commit message be updated to match the implementation?

> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> new file mode 100644
> index 0000000000000..59ee4d652a087
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml

[ ... ]

> +  interrupts:
> +    minItems: 1
> +    items:
> +      - description: FAULT interrupt (GPIO2 pin)
> +      - description: DRDY interrupt (GPIO3 pin)
> +
> +  interrupt-names:
> +    minItems: 1
> +    maxItems: 2
> +    items:
> +      enum: [fault, drdy]

[Severity: Low]
If a device tree specifies only the DRDY interrupt at index 0, does the strict
ordering in the interrupts list (which expects FAULT at index 0) clash with
the unordered interrupt-names definition?

[ ... ]

> +patternProperties:
> +  ^channel@[0-7a-f]$:
> +    $ref: adc.yaml

[Severity: Medium]
Does the JSON schema reference here need a '#' fragment or an absolute path
to ensure it resolves properly across all tooling versions during validation?

[Severity: High]
Does the regex pattern ^channel@[0-7a-f]$ omit digits 8 and 9? The reg
property below has a maximum of 15, so a device tree legitimately using
channel@8 or channel@9 would fail schema validation.

> +
> +    unevaluatedProperties: false
> +
> +    properties:
> +      reg:
> +        items:
> +          - maximum: 15 # arbitrary limit, channel@ can be any combination of AIN0-AIN7

[ ... ]

> +      burn-out-current-nanoamp:
> +        enum: [200, 1000, 10000]

[Severity: High]
Because device tree properties are parsed as arrays, will applying an enum
constraint directly to the property without using the 'items' keyword cause
dt_binding_check to always fail?

> +
> +      reference-sources:
> +        items:
> +          - enum: [internal-2.5v, internal-1.25v, external, avdd]
> +            default: internal-2.5v

[Severity: Medium]
Is a maxItems constraint needed for this array? Without it, JSON Schema only
applies the list validation to the first element, meaning additional items
in the array might silently pass without being checked.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-iio-adc-ti-ads122c14-v2-0-ceb9b0b561cb@baylibre.com?part=5