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] [day] [month] [year] [list]

Message-ID: <cc7399ed-db57-42cf-a944-6213a8df8491@oss.qualcomm.com>
Date: Fri, 24 Oct 2025 10:13:56 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Le Qi <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 1/2] arm64: dts: qcom: sm6150: Add gpr node

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)

> 
> 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