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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The YAML schema enforces a `ports` wrapper node for `audio-codec`, breaking validation for existing device trees.
- [Medium] The power button subnode name `key-power` conflicts with existing device trees, causing validation failures.
- [Medium] The `spi-cs-high` property was dropped from the `required` list during YAML conversion.
- [Low] The schema uses `additionalProperties: false` alongside a `$ref` in `allOf`, which is a dt-schema anti-pattern.
--

commit f0e021d94a5e3dc2af4a93b58f8cc3b052099a76
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..7f257f3a1a5a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -0,0 +1,414 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC MFD
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:

[ ... ]

> +  audio-codec:
> +    type: object
> +    additionalProperties: false
> +
> +    properties:

[ ... ]

> +      ports:
> +        $ref: /schemas/graph.yaml#/properties/ports
> +
> +        properties:
> +          port@0:
> +            $ref: /schemas/graph.yaml#/properties/port
> +            description: port connected to the Stereo HiFi DAC
> +
> +          port@1:
> +            $ref: /schemas/graph.yaml#/properties/port
> +            description: port connected to the Voice DAC

Will this cause validation failures for existing device trees?

The new YAML schema defines additionalProperties: false on the
audio-codec node and expects OF graph ports to be nested strictly
inside a ports child node. The original TXT binding example and existing
device trees place port@0 directly under the audio-codec node without
a ports wrapper.

[ ... ]

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

Is this node name conflict expected?

The schema strictly defines the power button child node as key-power,
but existing upstream device trees name this node button. Since button
is not explicitly defined in the YAML properties, will it be rejected by
dtbs_check?

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-controller
> +  - "#interrupt-cells"
> +  - spi-max-frequency
> +  - "#address-cells"
> +  - "#size-cells"

Was spi-cs-high intentionally omitted from the required list?

The original TXT binding explicitly listed it under required properties,
and the hardware requires an active-high SPI chip select to function
correctly.

> +
> +additionalProperties: false

Should this be unevaluatedProperties: false instead?

In JSON schema, additionalProperties: false ignores properties inherited
from $ref inclusions inside allOf. This rejects standard SPI properties
unless they are manually duplicated in the local properties block.

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