Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] Invalid scalar constraints and missing length bounds on the `reg` property inside channel nodes.
- [Low] Fixed-string property `^xlnx,channels$` is defined in `patternProperties` instead of `properties`.
- [Low] Redundant `type: boolean` declaration for the `xlnx,bipolar` property.
--

commit eb30bdd7a415cc66765c82f5a5300f2adb66fb3c
Author: Pramod Maurya <pramod.nexgen@gmail.com>

dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema

This commit converts the Xilinx XADC and UltraScale System Monitor device
tree bindings from the legacy plain-text format to a YAML schema. The new
schema covers the same hardware and compatible strings while enabling
automated validation with dt-schema.

> diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,xadc.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,xadc.yaml
> new file mode 100644
> index 0000000000000..ab6f16109aebd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/xlnx,xadc.yaml
[ ... ]
> +patternProperties:
> +  "^xlnx,channels$":

Is it intentional to place "^xlnx,channels$" in patternProperties? Since this
is a fixed string without any variable or wildcard components, defining it
under patternProperties bypasses explicit property tracking in dt-schema and
usually triggers a dt_binding_check linter warning. Should this be placed in
the properties block instead?

> +    type: object
> +    description:
> +      List of external channels connected to the ADC. If this property is
> +      absent, no external channels are assumed to be connected.
[ ... ]
> +    patternProperties:
> +      "^channel@([0-9a-f]|10)$":
> +        type: object
> +        description:
> +          Represents an external channel connected to the ADC.
> +
> +        properties:
> +          reg:
> +            description: |
> +              Pair of pins the channel is connected to.
> +                0: VP/VN
> +                1: VAUXP[0]/VAUXN[0]
> +                2: VAUXP[1]/VAUXN[1]
> +                ...
> +                16: VAUXP[15]/VAUXN[15]
> +            minimum: 0
> +            maximum: 16

Will this fail dt_binding_check validation? The reg property is intrinsically
an array type in device tree schemas. Applying scalar JSON schema validation
keywords like minimum and maximum directly to an array type is invalid.

Since the node name regex ^channel@([0-9a-f]|10)$ already enforces bounds on
the unit address, should the scalar bounds be removed and replaced with
maxItems: 1?

> +
> +          xlnx,bipolar:
> +            $ref: /schemas/types.yaml#/definitions/flag
> +            type: boolean

This isn't a bug, but the type: boolean declaration here appears redundant.
The reference to /schemas/types.yaml#/definitions/flag intrinsically defines
the node as a boolean-typed property without a value. Can the type: boolean
line be removed to align with standard dt-schema linting rules?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510120141.118057-1-pramod.nexgen@gmail.com?part=1