Re: [PATCH V9 3/3] arm64: dts: qcom: glymur-crd: add Audio sound card node

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The WSA8845 speaker nodes incorrectly use the `reset-gpios` property and directly share GPIO lines, which will result in ignored resets and probe failures.
- [High] The `&lpass_vamacro` node is missing the `vdd-micb-supply` property, which is required by the defined audio routing and will cause DMIC recording to fail silently.
--

commit 2f0fde1acdca88bc05fbbb5ed700dfb37ffa6d5c
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>

arm64: dts: qcom: glymur-crd: add Audio sound card node

Add the sound card of Glymur-crd board with the routing for speakers,
including playback via WSA884x smart speakers and recording via DMIC
microphones.

> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> index e784b538f42e1..6c272fb6081a8 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi

[ ... ]

> @@ -444,6 +492,12 @@ vreg_l4h_e0_1p2: ldo4 {
>  	};
>  };
>  
> +&lpass_vamacro {
> +	pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
> +	pinctrl-names = "default";
> +	qcom,dmic-sample-rate = <4800000>;
> +};

[Severity: High]
The audio routing explicitly maps the Digital Microphones to the vdd-micb
widget, but is this lpass_vamacro node missing the vdd-micb-supply property?

The lpass-va-macro driver uses DAPM to manage the power state for this widget.
Without the vdd-micb-supply property here, the regulator framework will silently
substitute a dummy regulator.

This will cause DAPM to report success while the hardware won't receive the
required microphone bias voltage, resulting in silent audio recordings on the
DMIC capture path.

[ ... ]

> +&swr0 {
> +	status = "okay";
> +
> +	/* WSA8845, Left Woofer */
> +	left_woofer: speaker@0,0 {
> +		compatible = "sdw20217020400";
> +		reg = <0 0>;
> +		reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;

[Severity: High]
Is reset-gpios the correct property name for this codec?

The wsa884x codec driver expects either a reset controller via the resets
property or powerdown-gpios. Using reset-gpios will result in the driver
finding neither, leaving the speakers in hardware reset and failing to
enumerate on the SoundWire bus.

Additionally, if this were renamed to powerdown-gpios, would the shared GPIO
line cause a probe failure? 

The left_tweeter node below also uses GPIO 12, which would cause the second
speaker's probe to fail with -EBUSY because devm_gpiod_get_optional requests
exclusive access.

Should this use a gpio-reset controller defined and referenced via the resets
property instead to properly share the line?

> +		#sound-dai-cells = <0>;
> +		sound-name-prefix = "WooferLeft";
> +		vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
> +		vdd-io-supply = <&vreg_l18b_e0_1p2>;
> +		qcom,port-mapping = <1 2 3 7 12 14>;
> +	};
> +
> +	/* WSA8845, Left Tweeter */
> +	left_tweeter: speaker@0,1 {
> +		compatible = "sdw20217020400";
> +		reg = <0 1>;
> +		reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com?part=3