Re: [PATCH v3 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] The binding defines GPIO provider capabilities (`gpio-controller`, `#gpio-cells`) but fails to include them in the `required` list and examples.
- [Medium] The `interrupt-names` property uses an object schema for `items` (`enum`), which fails to enforce positional ordering and contradicts the strict positional definition of the `interrupts` property.
- [Medium] The commit message claims that the `ti,vref-source` property is reused, but the code actually implements the standard `reference-sources` property instead.
--

--- Patch [5]: [PATCH v3 5/8] dt-bindings: iio: adc: add ti,ads122c14 ---
commit f62252330aecb9a95c850b342f0d43957821ef3a
Author: David Lechner (TI) <dlechner@baylibre.com>

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

Adds bindings for Texas Instruments' ADS112C14 and ADS122C14 ADC chips
primarily designed for use with temperature sensors.

>     The REFP/REFN reference voltage is usually just connected to a resistor
>     that is being driven by the ADC's current outputs, so there is special
>     property for this case rather than requiring a regulator to be defined
>     to represent that.
>     
>     ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>     have preferred an enum of strings).

[Severity: Medium]
The commit message mentions reusing ti,vref-source, but the schema actually
implements the standard reference-sources property instead. Could the commit
message be updated to match the code?

> 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..a2ee473c8e61e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
[ ... ]
> +  interrupt-names:
> +    minItems: 1
> +    maxItems: 2
> +    items:
> +      enum: [fault, drdy]

[Severity: Medium]
Does this items definition for interrupt-names allow invalid orderings?

By using an object schema instead of an array of constraints, this fails
to enforce positional ordering. It appears the schema could pass device trees
where interrupt-names are reversed (["drdy", "fault"]) or duplicated
(["fault", "fault"]).

It also allows ["drdy"] when only one interrupt is provided, contradicting
the interrupts definition which requires the first item to be the fault
interrupt.

[ ... ]
> +required:
> +  - compatible
> +  - reg
> +  - avdd-supply
> +  - dvdd-supply

[Severity: Medium]
Since the binding defines GPIO provider capabilities (gpio-controller and
#gpio-cells), should they be included in this required list?

Omitting them allows incomplete device tree nodes that advertise GPIO
capabilities without the corresponding required properties to pass schema
validation.

[ ... ]
> +examples:
> +  - |
> +    i2c {

[Severity: Medium]
Are the GPIO provider properties missing from the examples section?

If gpio-controller and #gpio-cells become required properties, the examples
will need to include them to pass schema validation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-iio-adc-ti-ads122c14-v3-0-746d52cbf1d0@baylibre.com?part=5