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] [day] [month] [year] [list]
Message-ID: <392c5d4b-80a9-46e8-af98-496ed8837044@oss.qualcomm.com>
Date: Thu, 9 Oct 2025 17:40:59 +0800
From: Le Qi <le.qi@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....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/2025 5:26 PM, Konrad Dybcio wrote:
> 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

Yes, will modify and test, thanks for pointing out.

-- 
Thx and BRs,
Le Qi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ