Re: [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot@kernel.org
Date: 2026-06-25 10:34:37
Also in:
linux-devicetree, linux-leds
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 [off-list ref] dt-bindings: mfd: motorola-cpcap: convert to DT schema Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
quoted hunk ↗ jump to hunk
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