linux-kernel - Re: [PATCH v1] arm64: dts: qcom: hamoa-iot-evk: Fix 4-speaker playback support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <39ebaf4e-e91f-4568-8de6-9fc1f805a1e4@oss.qualcomm.com>
Date: Thu, 9 Oct 2025 11:26:06 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: leqi <le.qi@....qualcomm.com>, Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@....qualcomm.com
Subject: Re: [PATCH v1] arm64: dts: qcom: hamoa-iot-evk: Fix 4-speaker
 playback support

On 10/9/25 9:26 AM, leqi wrote:
> On the HAMOA-IOT-EVK board only 2 out of 4 speakers were functional.
> Unlike the CRD, which shares a single GPIO reset line for WSA1/2,
> this board provides a dedicated GPIO reset for each WSA, resulting
> in 4 separate reset lines.
> 
> Update the device tree accordingly so that all 4 speakers can
> playback audio as expected.
> 
> Signed-off-by: leqi <le.qi@....qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 30 +++++++++++++++++-----
>  1 file changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> index df8d6e5c1f45..de9af19be6e8 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> @@ -743,7 +743,7 @@ retimer_ss1_con_sbu_out: endpoint {
>  };
>  
>  &lpass_tlmm {
> -	spkr_01_sd_n_active: spkr-01-sd-n-active-state {
> +	spkr0_sd_n_active: spkr0-sd-n-active-state {
>  		pins = "gpio12";
>  		function = "gpio";
>  		drive-strength = <16>;
> @@ -751,13 +751,29 @@ spkr_01_sd_n_active: spkr-01-sd-n-active-state {
>  		output-low;
>  	};
>  
> -	spkr_23_sd_n_active: spkr-23-sd-n-active-state {
> +	spkr1_sd_n_active: spkr1-sd-n-active-state {
>  		pins = "gpio13";
>  		function = "gpio";
>  		drive-strength = <16>;
>  		bias-disable;
>  		output-low;

output- properties should be removed in favor of in-code gpiod_
function calls, otherwise the reset gets asserted by the kernel as
the OF node is being processed, unbeknownst to the then-not-yet-
bound driver

[...]

> -	pinctrl-0 = <&wsa_swr_active>, <&spkr_01_sd_n_active>;
> +	pinctrl-0 = <&wsa_swr_active>, <&spkr0_sd_n_active>, <&spkr1_sd_n_active>;

Similarly, because these pin configs relate to GPIOs connected to
the speaker amps, and not the soundwire host, these entries should
be split between each individual device

Konrad