Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] DT Binding ABI Break (Validation Regression) due to missing legacy property names
- [Medium] DT Schema Validation Regression for Compatible Strings (Array Format)
- [Medium] Architectural Conflict with Overlapping Bindings
- [Medium] Hardware Description Constraint Violation (`interrupts` property)
--

commit 32ffb2a415040f6cd59db09f02686f031f4414c1
Author: Md Shofiqul Islam <shofiqtest@gmail.com>

dt-bindings: iio: accel: Convert lis302 binding to YAML schema

Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
tree binding from plain text format to YAML schema format.

> diff --git a/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> new file mode 100644
> index 0000000000000..befc419f7f397
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> @@ -0,0 +1,343 @@
[ ... ]
> +properties:
> +  compatible:
> +    enum:
> +      - st,lis302dl-spi
> +      - st,lis3lv02d

[Severity: Medium]
Will this strict enum definition cause a schema validation regression
by rejecting existing in-tree device trees that use a fallback list? Some
boards use an array format like compatible = "st,lis331dlh", "st,lis3lv02d";.
Could this be described using items and an enum instead so these arrays
are allowed?

[Severity: Medium]
These compatible strings are already documented and matched in
Documentation/devicetree/bindings/iio/st,st-sensors.yaml. Since
st,st-sensors.yaml uses additionalProperties: false, won't any node using
these compatibles fail dual-schema evaluation when properties like
st,click-single-x or Vdd-supply are evaluated by the other schema?

> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1

[Severity: Medium]
The hardware has two physical interrupt pins, which is reflected in the
routing properties defined below like st,irq1-click and st,irq2-click.
Does enforcing maxItems: 1 here cause validation failures on existing
valid boards that wire both interrupts?

[ ... ]
> +  st,click-double-z:
> +    type: boolean
> +    description: Enable double-click detection on Z axis.
> +
> +  st,click-threshold-x:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Click detection threshold for X axis.

[Severity: Medium]
Since unevaluatedProperties: false is set at the end of the schema, could
defining strict new property names without supporting the legacy names
(st,click-thresh-x and st,click-click-time-limit) cause a regression in
dtbs_check validation for existing in-tree device trees that still use
the older names?

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