[PATCH v3 1/6] dt-bindings: dma: ti,cppi41: Convert to DT schema

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The `interrupts` property is not marked as required for the `ti,da830-cppi41` hardware variant, allowing incomplete nodes to pass schema validation.
- [Low] Missing property type definitions for deprecated custom properties `#dma-channels` and `#dma-requests`.
- [Low] The unit address in the example node name does not match the first `reg` address.
--

commit efe52f34688a9f85bd73ed6d80af2e1107be14ba
Author: Bhargav Joshi <j.bhargav.u at gmail.com>

dt-bindings: dma: ti,cppi41: Convert to DT schema
    
This commit converts the TI CPPI 4.1 DMA controller text bindings to DT
schema. It merges ti,am3359-cppi41 and ti,da830-cppi41 into a single schema
and adds undocumented properties like power-domains to match existing device
tree usage.

> diff --git a/Documentation/devicetree/bindings/dma/ti/ti,cppi41.yaml b/Documentation/devicetree/bindings/dma/ti/ti,cppi41.yaml
> new file mode 100644
> index 0000000000000..a8c28e8ada072
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti/ti,cppi41.yaml
> @@ -0,0 +1,109 @@
[ ... ]
> +  power-domains:
> +    maxItems: 1
> +
> +  "#dma-channels":
> +    description: Deprecated, use dma-channels instead.
> +    deprecated: true
> +
> +  "#dma-requests":
> +    description: Deprecated, use dma-requests instead.
> +    deprecated: true

[Severity: Low]
Are the #dma-channels and #dma-requests custom properties missing a type
definition?

The schema tool strictly requires all properties that do not match core
regex patterns to have an explicit type via a reference. Without a type
definition, does this regression cause schema validation to fail when
checking the bindings?

> +
> +required:
> +  - compatible
[ ... ]
> +allOf:
> +  - $ref: /schemas/dma/dma-controller.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,am3359-cppi41
[ ... ]
> +    else:
> +      properties:
> +        reg:
> +          maxItems: 3
> +        reg-names:
> +          items:
> +            - const: controller
> +            - const: scheduler
> +            - const: queuemgr

[Severity: Medium]
Should the interrupts property be marked as required in this else block for
the ti,da830-cppi41 hardware variant?

If incomplete nodes pass schema validation without an interrupts property,
won't this regression cause the driver probe to fail when it attempts to parse
and map the interrupt?

> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    dma-controller at 7402000 {
> +        compatible = "ti,am3359-cppi41";
> +        reg = <0x47400000 0x1000>,

[Severity: Low]
Is the unit address in the dma-controller at 7402000 node name mismatched with
the first reg address?

The node name uses 7402000, but the first register address is 0x47400000.
Will this formatting regression cause a compiler warning when the examples are
evaluated?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-ti-am33-usb-v3-0-5e15c617d2e9@gmail.com?part=1