Re: [PATCH v2 3/3] dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The `st,lis302dl` compatible string causes a dual-schema validation conflict.
- [Medium] The properties `st,click-double-{x,y,z}` were incorrectly omitted during the YAML schema conversion.
- [Medium] The schema fails to document the upstream legacy typo `st,click-click-time-limit`, causing validation failures.
- [Medium] The `compatible` property incorrectly rejects upstream fallback combinations by strictly requiring a single exact match.
--

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

dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)

Replace the plain text lis302.txt with a YAML schema for the
LIS302DL/LIS3LV02D accelerometer family.

> 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..8a19aa1085215
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> @@ -0,0 +1,320 @@
[ ... ]
> +properties:
> +  compatible:
> +    oneOf:
> +      - description: I2C variant (original part)
> +        const: st,lis302dl

[Severity: Medium]
Since this compatible string is also present in the existing
Documentation/devicetree/bindings/iio/st,st-sensors.yaml, does adding it here
cause a dual-schema validation conflict?

If device tree nodes use st,lis302dl and include the legacy properties
introduced in this new schema, they might fail dt_binding_check validation
against st,st-sensors.yaml because that schema strictly restricts properties.

> +      - description: I2C variant (larger range)
> +        const: st,lis3lv02d
> +      - description: SPI variant; including the bus type in the compatible
> +          string is a legacy naming error, do not copy for new bindings
> +        const: st,lis302dl-spi

[Severity: Medium]
Will this strict oneOf and const definition incorrectly reject valid upstream
device trees that use a multiple-string fallback array?

Numerous upstream device trees (e.g., am335x-evm.dts, omap3-gta04a3.dts)
use a fallback array like:
	compatible = "st,lis331dlh", "st,lis3lv02d";

A const rule fails against an array, which will cause these boards to fail
schema validation.

Should this be rewritten to support items lists?

[ ... ]
> +  st,click-single-x:
> +    type: boolean
> +    deprecated: true
> +    description: Enable single-click detection on X axis.
> +
> +  st,click-single-y:
> +    type: boolean
> +    deprecated: true
> +    description: Enable single-click detection on Y axis.
> +
> +  st,click-single-z:
> +    type: boolean
> +    deprecated: true
> +    description: Enable single-click detection on Z axis.

[Severity: Medium]
Were the properties st,click-double-{x,y,z} omitted from this conversion?

The original lis302.txt binding defined these properties, and the driver at
drivers/misc/lis3lv02d/lis3lv02d.c actively parses them via
of_property_read_bool().

Since the new schema specifies unevaluatedProperties: false, any device tree
correctly utilizing the double-click properties will now fail schema validation.

[ ... ]
> +  st,click-thresh-y:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    deprecated: true
> +    description: See st,click-thresh-x.
> +
> +  st,click-thresh-z:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    deprecated: true
> +    description: See st,click-thresh-x.
> +
> +  st,click-time-limit:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    deprecated: true
> +    description: Click time limit in 0.5ms steps (0-127).

[Severity: Medium]
Does the schema need to document the legacy typo st,click-click-time-limit
to prevent validation failures?

The conversion correctly maps this to st,click-time-limit, but upstream
device trees (e.g., arch/arm/boot/dts/ti/omap/omap3-gta04a3.dts) still use the
misspelled property.

Because unevaluatedProperties is set to false, dt_binding_check will now fail
for those boards.

Should this typo be accommodated similarly to how the st,click-thresh-x typo
was handled?

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