[PATCH 0/3] Add ADSP support for Nord SoC

[PATCH 0/3] Add ADSP support for Nord SoC

[Shawn Guo]

The series documents AOSS side channel and adds ADSP (HPASS DSP)
remoteproc support for Nord SoC.

Nord SoC actually have 3 ADSPs. This series only enables ADSP0 which
can work independently. The rest two instances have dependencies on
ADSP0 regarding start/stop and SSR. And remoteproc framework doesn't
seem to support such "slave" instances yet.

Shawn Guo (3):
  dt-bindings: soc: qcom,aoss-qmp: Document Nord AOSS side channel
  dt-bindings: remoteproc: qcom,sm8550-pas: Document Nord ADSP
  remoteproc: qcom: pas: Add Nord ADSP support

 .../bindings/remoteproc/qcom,sm8550-pas.yaml  | 19 ++++++++++++++++
 .../bindings/soc/qcom/qcom,aoss-qmp.yaml      |  1 +
 drivers/remoteproc/qcom_q6v5_pas.c            | 22 +++++++++++++++++++
 3 files changed, 42 insertions(+)

-- 
2.43.0

[PATCH 1/3] dt-bindings: soc: qcom,aoss-qmp: Document Nord AOSS side channel

[Shawn Guo]

Document Always-on Subsystem side channel on Qualcomm Nord SoC.

Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
index 8eaa04431d74..e778fa3a6c92 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
@@ -30,6 +30,7 @@ properties:
           - qcom,hawi-aoss-qmp
           - qcom,kaanapali-aoss-qmp
           - qcom,milos-aoss-qmp
+          - qcom,nord-aoss-qmp
           - qcom,qcs615-aoss-qmp
           - qcom,qcs8300-aoss-qmp
           - qcom,qdu1000-aoss-qmp
-- 
2.43.0

[PATCH 2/3] dt-bindings: remoteproc: qcom,sm8550-pas: Document Nord ADSP

[Shawn Guo]

Document ADSP (HPASS DSP) for Nord SoC.

The Nord ADSP use CX and MX power domains, so add a new conditional
block to enforce the correct power-domain-names for it.

It also uses IPCC-based GLINK signalling (shared with Glymur, Kaanapali
and SM8750), so add it to the existing IPCC interrupt-names constraint.

Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 .../bindings/remoteproc/qcom,sm8550-pas.yaml  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index faf7b2890de8..1a8539d6b788 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     oneOf:
       - enum:
+          - qcom,nord-adsp-pas
           - qcom,sdx75-mpss-pas
           - qcom,sm8550-adsp-pas
           - qcom,sm8550-cdsp-pas
@@ -138,6 +139,7 @@ allOf:
               - qcom,hawi-cdsp-pas
               - qcom,kaanapali-adsp-pas
               - qcom,kaanapali-cdsp-pas
+              - qcom,nord-adsp-pas
               - qcom,sm8750-adsp-pas
     then:
       properties:
@@ -242,6 +244,23 @@ allOf:
             - const: lcx
             - const: lmx
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,nord-adsp-pas
+    then:
+      properties:
+        power-domains:
+          items:
+            - description: CX power domain
+            - description: MX power domain
+        power-domain-names:
+          items:
+            - const: cx
+            - const: mx
+
   - if:
       properties:
         compatible:
-- 
2.43.0

[PATCH 3/3] remoteproc: qcom: pas: Add Nord ADSP support

[Shawn Guo]

The ADSP (HPASS DSP) on Nord SoC is pre-booted by XBL before Linux starts.
Add ADSP resource descriptor, and set early_boot flag for attach path
rather than a cold boot sequence.

Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 drivers/remoteproc/qcom_q6v5_pas.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index 60a4337d9e51..486d08e75cab 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -1422,6 +1422,27 @@ static const struct qcom_pas_data milos_cdsp_resource = {
 	.smem_host_id = 5,
 };
 
+static const struct qcom_pas_data nord_adsp_resource = {
+	.crash_reason_smem = 423,
+	.firmware_name = "adsp.mdt",
+	.dtb_firmware_name = "adsp_dtb.mbn",
+	.pas_id = 1,
+	.dtb_pas_id = 36,
+	.minidump_id = 5,
+	.auto_boot = true,
+	.early_boot = true,
+	.proxy_pd_names = (char*[]){
+		"cx",
+		"mx",
+		NULL
+	},
+	.load_state = "adsp",
+	.ssr_name = "lpass",
+	.sysmon_name = "adsp",
+	.ssctl_id = 0x14,
+	.smem_host_id = 2,
+};
+
 static const struct qcom_pas_data sm8450_mpss_resource = {
 	.crash_reason_smem = 421,
 	.firmware_name = "modem.mdt",
@@ -1664,6 +1685,7 @@ static const struct of_device_id qcom_pas_of_match[] = {
 	{ .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
 	{ .compatible = "qcom,milos-mpss-pas", .data = &sm8450_mpss_resource },
 	{ .compatible = "qcom,milos-wpss-pas", .data = &sc7280_wpss_resource },
+	{ .compatible = "qcom,nord-adsp-pas", .data = &nord_adsp_resource },
 	{ .compatible = "qcom,msm8226-adsp-pil", .data = &msm8996_adsp_resource },
 	{ .compatible = "qcom,msm8953-adsp-pil", .data = &msm8996_adsp_resource },
 	{ .compatible = "qcom,msm8974-adsp-pil", .data = &msm8996_adsp_resource },
-- 
2.43.0

Re: [PATCH 3/3] remoteproc: qcom: pas: Add Nord ADSP support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] The patch introduces a compilation failure by initializing a non-existent `early_boot` member, and omits the "attach path" logic promised in the commit message.
- [Low] The `qcom_pas_of_match` array is not kept in alphabetical order.

Pre-existing issues:
- [High] Missing unroll logic in `qcom_pas_assign_memory_region()` permanently leaks secure memory assignments on error.
--

--- Patch [3]: [PATCH 3/3] remoteproc: qcom: pas: Add Nord ADSP support ---
commit c4d506b746f90f7894797ce51ad96d54c9cd9077
Author: Shawn Guo <shengchao.guo@oss.qualcomm.com>

remoteproc: qcom: pas: Add Nord ADSP support

The ADSP on Nord SoC is pre-booted by XBL before Linux starts. This patch
adds the ADSP resource descriptor and sets the early_boot flag for the
attach path rather than a cold boot sequence.

> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -1354,6 +1354,27 @@ static const struct qcom_pas_data milos_cdsp_resource = {
>  	.smem_host_id = 5,
>  };
>  
> +static const struct qcom_pas_data nord_adsp_resource = {
> +	.crash_reason_smem = 423,
> +	.firmware_name = "adsp.mdt",
> +	.dtb_firmware_name = "adsp_dtb.mbn",
> +	.pas_id = 1,
> +	.dtb_pas_id = 36,
> +	.minidump_id = 5,
> +	.auto_boot = true,
> +	.early_boot = true,

[Severity: High]
Does this cause a build failure? Looking at the definition of
struct qcom_pas_data in drivers/remoteproc/qcom_q6v5_pas.c, it doesn't
appear to have an early_boot member.

Additionally, the commit message mentions setting the early_boot flag for
the attach path rather than a cold boot sequence. If the build is fixed by
simply adding early_boot to the struct, will the probe succeed but fall
back to the cold boot path since the driver appears to be missing the
attach logic?

This could cause the driver to reset and reload firmware on an
already-running DSP.

> +	.proxy_pd_names = (char*[]){
> +		"cx",
> +		"mx",
> +		NULL
> +	},

[ ... ]

> @@ -1578,6 +1599,7 @@ static const struct of_device_id qcom_pas_of_match[] = {
>  	{ .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
>  	{ .compatible = "qcom,milos-mpss-pas", .data = &sm8450_mpss_resource },
>  	{ .compatible = "qcom,milos-wpss-pas", .data = &sc7280_wpss_resource },
> +	{ .compatible = "qcom,nord-adsp-pas", .data = &nord_adsp_resource },
>  	{ .compatible = "qcom,msm8226-adsp-pil", .data = &msm8996_adsp_resource },

[Severity: Low]
This isn't a bug, but does this break the alphabetical ordering of the
qcom_pas_of_match array? The compatible qcom,nord-adsp-pas is inserted
between qcom,milos-wpss-pas and qcom,msm8226-adsp-pil. Since nord starts
with n, it should likely be placed further down after the msm entries.


[Severity: High]
This is a pre-existing issue, but I noticed a potential leak of secure
memory assignments on error paths:

drivers/remoteproc/qcom_q6v5_pas.c:qcom_pas_assign_memory_region() {
    ...
    if (ret < 0) {
        dev_err(pas->dev, "assign memory %d failed\n", offset);
        return ret;
    }
    ...
}

If an assignment fails at an offset greater than 0, the function returns
an error code without reverting the permissions of regions that were
successfully mapped in prior iterations.

Additionally, in qcom_pas_probe():

drivers/remoteproc/qcom_q6v5_pas.c:qcom_pas_probe() {
    ...
    ret = qcom_pas_assign_memory_region(pas);
    if (ret)
        goto free_rproc;
    ...
}

The probe failure path jumps to free_rproc, bypassing the unassign_mem
label and failing to call qcom_pas_unassign_memory_region().

Does this permanently leak system memory to the secure environment,
rendering it inaccessible to the host OS?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709085149.4072181-1-shengchao.guo@oss.qualcomm.com?part=3