Re: [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The YAML schema introduces a `ports` wrapper node for the `audio-codec`, which conflicts with the original TXT binding and existing device trees that define `port@X` directly as children.
- [Medium] The schema explicitly expects the power button subnode to be named exactly `key-power`, but the in-tree device tree uses `button`.
- [Medium] The `spi-cs-high` property, which is physically required by the hardware and was explicitly listed as required in the legacy text binding, has been omitted from the `required` list in the YAML schema.
--

commit 30a40e2d4eb937fd9bbca306ed8246e061a54ab4
Author: Svyatoslav Ryhel <clamor95@gmail.com>

dt-bindings: mfd: motorola-cpcap: convert to DT schema

Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.

> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..76705ea56805a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> +  audio-codec:
> +    type: object
> +    additionalProperties: false
> +
> +    properties:
[ ... ]
> +      ports:
> +        $ref: /schemas/graph.yaml#/properties/ports

[Severity: Medium]
Will this break validation for existing device trees?

The legacy text binding example shows port@0 and port@1 directly under the
audio-codec node, but this schema requires them to be wrapped in a ports
node. Because additionalProperties is set to false on audio-codec, direct
port@X nodes in existing device trees will be rejected.

[ ... ]
> +  charger:
> +    $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> +  key-power:
> +    $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#

[Severity: Medium]
Is it intentional to restrict the subnode name strictly to key-power?

Existing in-tree device trees use button for this node. By strictly matching
key-power, existing configurations will be rejected as an undocumented
property during schema validation.

[ ... ]
> +patternProperties:
> +  "^led(-[a-z]+)?$":
> +    $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-controller
> +  - "#interrupt-cells"
> +  - spi-max-frequency

[Severity: Medium]
Does this schema incorrectly omit spi-cs-high from the required list?

The legacy text binding explicitly listed spi-cs-high as a required property.
Without it, incomplete device trees lacking this hardware-critical property
will incorrectly pass validation.

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