Re: [PATCH v1 1/2 RESEND] ASoC: dt-bindings: Document FM34NE DSP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: typo in example clock phandle fn34ne_clk
- [Low] dt-bindings: missing audio-graph-port validation on nested ports children
--

commit 7ea62b580d59721cf9be3722ba0f59686684d184
Author: Svyatoslav Ryhel <clamor95@gmail.com>

ASoC: dt-bindings: Document FM34NE DSP
    
Document the FM34NE DSP based voice processor used in the ASUS Transformer
devices.

> diff --git a/Documentation/devicetree/bindings/sound/asus,tf201-dsp.yaml b/Documentation/devicetree/bindings/sound/asus,tf201-dsp.yaml
> new file mode 100644
> index 0000000000000..6b1c478bd03cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/asus,tf201-dsp.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---

[ ... ]

> +  bypass-gpios:
> +    maxItems: 1
> +    description: Signal that switches DSP into programming mode.
> +
> +  vdd-supply: true
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports

[Severity: Low]
Does this node lack audio-graph-port validation for its nested port children?

When a device tree configuration uses the ports container node, any properties
inside its nested port@X children will only be validated against the generic
graph.yaml schema, not audio-graph-port.yaml#. As a result, invalid or
misspelled audio-specific properties will silently pass schema validation.

Should this explicitly apply patternProperties with a reference to
audio-graph-port.yaml# for the children?

> +
> +  port:
> +    $ref: audio-graph-port.yaml#
> +    unevaluatedProperties: false

[ ... ]

> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        codec@60 {
> +            compatible = "asus,tf201-dsp";
> +            reg = <0x60>;
> +
> +            clocks = <&fn34ne_clk>;

[Severity: Low]
This isn't a bug, but should this phandle name be &fm34ne_clk to match the
FM34NE chip name?

> +
> +            bypass-gpios = <&gpio 222 GPIO_ACTIVE_HIGH>;
> +            reset-gpios = <&gpio 115 GPIO_ACTIVE_LOW>;
> +
> +            vdd-supply = <&vdd_1v8_dsp>;
> +        };
> +    };
> +...

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