Re: [PATCH 1/2] dt-bindings: dma: nuvoton,ma35d1-pdma: Document MA35D1 PDMA controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: dma: nuvoton,ma35d1-pdma: additionalProperties blocks common props
- [Low] dt-bindings: dma: nuvoton,ma35d1-pdma: missing resets property in schema
--

commit 5c880c71a9c2f4fa473d23c5e2bcf77d9794575d
Author: Shan-Chun Hung <shanchun1218@gmail.com>

dt-bindings: dma: nuvoton,ma35d1-pdma: Document MA35D1 PDMA controller

This commit adds the devicetree binding schema and request source header for
the Nuvoton MA35D1 PDMA controller.

> diff --git a/Documentation/devicetree/bindings/dma/nuvoton,ma35d1-pdma.yaml b/Documentation/devicetree/bindings/dma/nuvoton,ma35d1-pdma.yaml
> new file mode 100644
> index 0000000000000..cd752571242c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/nuvoton,ma35d1-pdma.yaml
> @@ -0,0 +1,72 @@

[ ... ]

> +allOf:
> +  - $ref: dma-controller.yaml#
> +
> +properties:
> +  compatible:
> +    const: nuvoton,ma35d1-pdma
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1

[Severity: Low]
Should this binding also document the resets property?

The MA35D1 reset binding and driver define dedicated hardware reset lines for
the four PDMA controllers:

include/dt-bindings/reset/nuvoton,ma35d1-reset.h:
    #define MA35D1_RESET_PDMA0	4
    #define MA35D1_RESET_PDMA1	5
    #define MA35D1_RESET_PDMA2	6
    #define MA35D1_RESET_PDMA3	7

drivers/reset/reset-ma35d1.c:
    static const struct ma35d1_reset_map ma35d1_resets[] = {
        ...
        [MA35D1_RESET_PDMA0] =   {0x20, 4},
        [MA35D1_RESET_PDMA1] =   {0x20, 5},
        [MA35D1_RESET_PDMA2] =   {0x20, 6},
        [MA35D1_RESET_PDMA3] =   {0x20, 7},

Without resets in the properties block, describing the controller's hardware
reset line in a devicetree node will fail dtbs_check validation.

> +
> +  "#dma-cells":
> +    const: 2
> +    description:
> +      The first cell is the channel number. The second cell is the
> +      peripheral request source (REQSRC) selection, which defines which
> +      peripheral is connected to that PDMA channel.
> +
> +  dma-channels:
> +    const: 10
> +
> +additionalProperties: false

[Severity: Low]
Since this schema references dma-controller.yaml# under allOf, shouldn't it
use unevaluatedProperties: false instead of additionalProperties: false?

Using additionalProperties: false causes dtbs_check to reject standard DMA
controller properties inherited from dma-controller.yaml# and
dma-common.yaml# (such as dma-channel-mask or dma-requests) unless they are
duplicated in the local properties block.

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