linux-kernel - Re: [PATCH v1 1/2] arm64: dts: qcom: sm6150: Add gpr node

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: <e19e3ff4-bee0-4c40-bb6d-76d25e324024@oss.qualcomm.com>
Date: Mon, 27 Oct 2025 11:17:38 +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 1/2] arm64: dts: qcom: sm6150: Add gpr node

On 10/24/2025 4:13 PM, Konrad Dybcio wrote:
> On 10/24/25 4:37 AM, Le Qi wrote:
>> Add GPR(Generic Pack router) node along with
>> APM(Audio Process Manager) and PRM(Proxy resource
>> Manager) audio services.
> 
> This is a really weird
> way of breaking your message that makes
> it difficult to read
> 
> (stick to something more like 72 characters, please)

Thanks, will modify this in next patch.

> 
>>
>> Signed-off-by: Le Qi <le.qi@....qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/sm6150.dtsi | 36 ++++++++++++++++++++++++++++
>>   1 file changed, 36 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm6150.dtsi b/arch/arm64/boot/dts/qcom/sm6150.dtsi
>> index 3d2a1cb02b62..ec244c47983e 100644
>> --- a/arch/arm64/boot/dts/qcom/sm6150.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm6150.dtsi
>> @@ -16,6 +16,7 @@
>>   #include <dt-bindings/power/qcom-rpmpd.h>
>>   #include <dt-bindings/power/qcom,rpmhpd.h>
>>   #include <dt-bindings/soc/qcom,rpmh-rsc.h>
>> +#include <dt-bindings/soc/qcom,gpr.h>
>>   
>>   / {
>>   	interrupt-parent = <&intc>;
>> @@ -4246,6 +4247,41 @@ compute-cb@6 {
>>   						dma-coherent;
>>   					};
>>   				};
>> +
>> +				gpr: gpr {
>> +					compatible = "qcom,gpr";
>> +					qcom,glink-channels = "adsp_apps";
>> +					qcom,domain = <GPR_DOMAIN_ID_ADSP>;
>> +					qcom,intents = <512 20>;
>> +					#address-cells = <1>;
>> +					#size-cells = <0>;
>> +
>> +					q6apm: service@1 {
>> +						compatible = "qcom,q6apm";
>> +						reg = <GPR_APM_MODULE_IID>;
>> +						#sound-dai-cells = <0>;
>> +
>> +						q6apmbedai: bedais {
>> +							compatible = "qcom,q6apm-lpass-dais";
>> +							#sound-dai-cells = <1>;
>> +						};
>> +
>> +						q6apmdai: dais {
>> +							compatible = "qcom,q6apm-dais";
>> +							iommus = <&apps_smmu 0x1721 0x0>;
> 
> I see that the documentation mentions a mask of 0x0 (like you did
> here), but downstream does something funny here:
> 
> iommus = <&apps_smmu 0x1721 0x0>;
> qcom,smmu-sid-mask = /bits/ 64 <0xf>;
> 
> with the latter value being consumed by the driver manually and when
> it binds some sort of DMA_BUFs, the effective SID (ID & mask -- notice
> there's no bitflipping of the mask part here unlike in the SMMU driver)
> is prepended to the address:
> 
> smmu->pa |= ((sid & mask) << 32);
> 
> We can then check that the SMMU driver reads the SMR mask as a 16b field,
> meaning the result is (sid & 0xffff) and not (sid & 0xf)..
> 
> If we take the hardcoded-downstream mask and compare it with the HSR,
> we can notice that all the streams in the 0x172X range correspond to
> LPASS_ADSP, so perhaps it's a design choice that the DSP end only cares
> about the least significant digit
> 
> TLDR this seems to be all OK
> 
> Konrad

Thank you so much for the detailed explanation.

-- 
Thx and BRs,
Le Qi