Re: [PATCH v2 02/10] ASoC: dt-bindings: audio-graph-port: add definitions/ports

[Rob Herring <robh@kernel.org>]

On Wed, Jan 11, 2023 at 01:09:52AM +0000, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> Audio Graph user needs "ports" not only "port".
> This patch adds standard "ports" as definitions to use it easily.
> 
> If user needs standard "ports", it can use
> 
>    ports:
>      $ref: audio-graph-port.yaml#/definitions/ports
> 
> If user want to use custom ports, it can re-use
> audio-graph-port.yaml#/definitions/port-base"
> audio-graph-port.yaml#/definitions/endpoint-base"
> 
> https://lore.kernel.org/r/87sfhipynv.wl-kuninori.morimoto.gx@renesas.com
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  .../devicetree/bindings/sound/audio-graph-port.yaml  | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
> index fa66b73abcaf2..6fcf7f567424d 100644
> --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
> +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
> @@ -97,6 +97,18 @@ definitions:
>                minimum: 1
>                maximum: 64
>  
> +  ports:
> +    $ref: "#/definitions/port-base"

This applies to 'port' nodes, but this is the 'ports' node.

For example, this schema says you can have endpoint nodes directly under 
'ports' which is not valid.

But why do you need this? The graph.yaml schema should be sufficient 
because you aren't adding custom properties in 'ports'. BTW, the 
preference is to only add properties in 'endpoint' nodes.

> +    unevaluatedProperties: false
> +    patternProperties:
> +      "^port(@[0-9a-f]+)?$":
> +        $ref: "#/definitions/port-base"
> +        unevaluatedProperties: false

If 'ports' schema is applied to a DT, then its 'port' node(s) cannot 
have any additional properties. That defeats the point of patch 1.

You cannot have 2 schemas with child nodes and be able to extend the 
properties on the child nodes. The 2 child node schemas can't 'see' each 
other in that case. In these cases, the base child node schema has to be 
referenced directly by the extended child node schema.


> +        patternProperties:
> +          "^endpoint(@[0-9a-f]+)?":
> +            $ref: "#/definitions/endpoint-base"
> +            unevaluatedProperties: false

The same thing applies here.

Rob