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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Flawed conditional validation for `clocks` and `/DRDY` mutual exclusivity
- [Medium] Missing Required Properties for Provider Capabilities
- [Low] Inconsistent Validation Constraints for `interrupt-names`
--

--- Patch [5]: [PATCH v4 5/8] dt-bindings: iio: adc: add ti,ads122c14 ---
commit 8ec99dd88682486b85d4fece20ce3719cbf6082e
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 resistive sensors. The bindings include special properties for
reference voltage sources and current outputs for each measurement channel.

> 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..b11359c9955e6
> --- /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]
The interrupts property defines a strict positional ordering where the first
item is /FAULT and the second is /DRDY. Does using an unordered enum for
interrupt-names allow the names to be supplied out of order, which would
conflict with the strict ordering of the actual interrupts?

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - avdd-supply
> +  - dvdd-supply

[Severity: Medium]
Since this hardware acts as a GPIO controller (defining gpio-controller and
#gpio-cells), should these properties be included in the required list to
ensure incomplete device tree nodes do not pass validation?

[ ... ]

> +# /DRDY out and CLK in use the same AIN7/GPIO3 pin.
> +if:
> +  properties:
> +    interrupt-names:
> +      contains:
> +        const: drdy
> +then:
> +  properties:
> +    clocks: false

[Severity: Medium]
Will this conditional incorrectly evaluate to true when the interrupt-names
property is completely omitted?

Due to JSON Schema semantics, missing properties trivially pass the check.
This might incorrectly forbid clocks for valid configurations that only use
the /FAULT interrupt but omit interrupt-names entirely.

Also, is it possible to bypass this check by supplying two items in the
interrupts array while only defining interrupt-names as ["fault"]?

Would checking the length of the interrupts array be a more robust way to
enforce this exclusivity?

[ ... ]

> +examples:
> +  - |
> +    i2c {

[Severity: Medium]
If the GPIO controller properties are required for this device to function
as a provider, do they also need to be demonstrated in these examples to
successfully pass dt_binding_check?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-iio-adc-ti-ads122c14-v4-0-25f8e3084485@baylibre.com?part=5