[PATCH v4 0/3] Add remoteproc PAS loader for SoCCP on Glymur DT

[PATCH v4 0/3] Add remoteproc PAS loader for SoCCP on Glymur DT

[Ananthu C V]

This series adds support for SoCCP on Qualcomm Glymur/Mahua platforms. It
introduces the needs_tzmem flag to force tzmem usage and subsequent SHM
bridge setup required when Linux runs at EL2 in the absence of Gunyah. We've
been currently relying on the iommu property being present for this, but for
remoteprocs that are already running like SoCCP the memory mappings are
already in place, and any attempt to recreate them would result in smmu faults
and a non-functional remoteproc. This change is required for SSR to work on
SoCCP on Glymur.

For SoCCP SSR verification we've raised two PR's in diag upstream:
https://github.com/linux-msm/diag/pull/23
https://github.com/linux-msm/diag/pull/24

SoCCP SSR on Glymur can be triggered using the following commands using diag:
  error fatal: send_data 75 37 03 152 00
  wdog bite: send_data 75 37 03 152 01
  Software exception (Null pointer): send_data 75 37 03 152 02
  software exception (div by 0): send_data 75 37 03 152 03

/ # send_data 75 37 03 152 03
75 37 3 152
/ # qcom_q6v5_pas d00000.remoteproc: fatal error received: EX:idle:0x0xa90cc050:PC=0xa8eb5d8c:LR=0xa8fe5b3a:CAUSE=0xb:REASON=0x4
 remoteproc remoteproc0: crash detected in soccp: type fatal error
 qcom_q6v5_pas d00000.remoteproc: Handover signaled, but it already happened
 remoteproc remoteproc0: handling crash #4 in soccp
 remoteproc remoteproc0: recovering soccp
 ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -104
 remoteproc remoteproc0: stopped remote processor soccp
 usb 3-1: USB disconnect, device number 3
 usb 5-1: USB disconnect, device number 2
 r8152-cfgselector 5-1.3: USB disconnect, device number 3
 qcom_q6v5_pas d00000.remoteproc: Handover signaled, but it already happened
 debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'
 remoteproc remoteproc0: remote processor soccp is now up

Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
Changes in v4:
  - dropped soccp from remoteproc node name
  - dropped status=disabled
  - added a new needs_tzmem flag in qcom_q6v5_pas platform driver, and added glymur_soccp_resource
    which uses the flag
  - dropped qcom,kaanapali-soccp-pas compatible, due to the kaanapali_soccp_resource not having the
    needs_tzmem flag enabled
  - fixed memory region mappings for glymur soccp
  - Link to v3: https://lore.kernel.org/lkml/20260403-glymur-soccp-v3-1-f0e8d57f11ba@oss.qualcomm.com

Changes in v3:
  - dropped smp2p nodes which are already merged, and adsp and cdsp nodes
  - updated interrupts-extended (dropped  <&soccp_smp2p_in 10 IRQ_TYPE_EDGE_RISING>), interrupt-names
    (dropped wake-ack), smem-states (dropped <&soccp_smp2p_out 10>, <&soccp_smp2p_out 9>), and
    smem-state-names (dropped wakeup, sleep)
  - fixed IPCC names, GLYMUR_MPROC_SOCCP -> IPCC_MPROC_SOCCP
  - Link to v2: https://lore.kernel.org/lkml/20250925-v3_glymur_introduction-v2-24-8e1533a58d2d@oss.qualcomm.com/

Changes in v2:
  - None related to soccp
  - Link to v1: https://lore.kernel.org/r/20250925-v3_glymur_introduction-v1-0-5413a85117c6@oss.qualcomm.com

---
Ananthu C V (2):
      remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation
      arm64: dts: qcom: fix SoCCP memory mappings for Glymur

Sibi Sankar (1):
      arm64: dts: qcom: add SoCCP DT node for Glymur

 arch/arm64/boot/dts/qcom/glymur-crd.dtsi |  7 +++++
 arch/arm64/boot/dts/qcom/glymur.dtsi     | 52 +++++++++++++++++++++++++++++---
 drivers/remoteproc/qcom_q6v5_pas.c       | 24 +++++++++++++--
 3 files changed, 77 insertions(+), 6 deletions(-)
---
base-commit: 6eb8711ece2ce27e52e327a5b7a628ed39b97f45
change-id: 20260702-glymur-soccp-8f50d947f601

Best regards,
--  
Ananthu C V <ananthu.cv@oss.qualcomm.com>

[PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation

[Ananthu C V]

Most Qualcomm platforms feature Gunyah hypervisor, which typically
handles Stage 2 IOMMU configuration. Additionally, SHM bridge setup
is required to enable memory protection for both remoteproc metadata
and its memory regions. When the aforementioned hypervisor is absent,
the operating system must perform these configurations instead. We've
been relying on the iommu property being present for this, but for
remoteprocs that are already running like SoCCP the mappings are already
in place, and any attempt to recreate them while active would lead to smmu
faults and a non-functional remoteproc. Fix this by adding a needs_tzmem
flag which ensures tzmem and SHM bridge setup is performed independent to
the iommu property being present.

Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
 drivers/remoteproc/qcom_q6v5_pas.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index 60a4337d9e51..cd7273fbcf98 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -61,6 +61,7 @@ struct qcom_pas_data {
 	bool region_assign_shared;
 	int region_assign_vmid;
 	bool early_boot;
+	bool needs_tzmem;
 };
 
 struct qcom_pas {
@@ -914,8 +915,8 @@ static int qcom_pas_probe(struct platform_device *pdev)
 		goto remove_ssr_sysmon;
 	}
 
-	pas->pas_ctx->use_tzmem = rproc->has_iommu;
-	pas->dtb_pas_ctx->use_tzmem = rproc->has_iommu;
+	pas->pas_ctx->use_tzmem = desc->needs_tzmem || rproc->has_iommu;
+	pas->dtb_pas_ctx->use_tzmem = desc->needs_tzmem || rproc->has_iommu;
 
 	if (desc->early_boot)
 		pas->rproc->state = RPROC_DETACHED;
@@ -1657,8 +1658,27 @@ static const struct qcom_pas_data kaanapali_soccp_resource = {
 	.early_boot = true,
 };
 
+static const struct qcom_pas_data glymur_soccp_resource = {
+	.crash_reason_smem = 656,
+	.firmware_name = "soccp.mbn",
+	.dtb_firmware_name = "soccp_dtb.mbn",
+	.pas_id = 51,
+	.dtb_pas_id = 0x41,
+	.proxy_pd_names = (char*[]){
+		"cx",
+		"mx",
+		NULL
+	},
+	.ssr_name = "soccp",
+	.sysmon_name = "soccp",
+	.auto_boot = true,
+	.early_boot = true,
+	.needs_tzmem = true,
+};
+
 static const struct of_device_id qcom_pas_of_match[] = {
 	{ .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
+	{ .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource },
 	{ .compatible = "qcom,kaanapali-soccp-pas", .data = &kaanapali_soccp_resource },
 	{ .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
 	{ .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },

-- 
2.43.0

[PATCH v4 2/3] arm64: dts: qcom: fix SoCCP memory mappings for Glymur

[Ananthu C V]

Fixup the SoCCP/SoCCP DTB memory regions to reflect the memory
region requirements of the SoCCP firmware, as described in the
Glymur v21 memory map release.

Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..5f44f68efde2 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -602,13 +602,13 @@ spss_region_mem: spss@88a00000 {
 			no-map;
 		};
 
-		soccpdtb_mem: soccpdtb@892e0000 {
-			reg = <0x0 0x892e0000 0x0 0x20000>;
+		soccpdtb_mem: soccpdtb@89200000 {
+			reg = <0x0 0x89200000 0x0 0x20000>;
 			no-map;
 		};
 
-		soccp_mem: soccp@89300000 {
-			reg = <0x0 0x89300000 0x0 0x400000>;
+		soccp_mem: soccp@88e00000 {
+			reg = <0x0 0x88e00000 0x0 0x400000>;
 			no-map;
 		};
 

-- 
2.43.0

[PATCH v4 3/3] arm64: dts: qcom: add SoCCP DT node for Glymur

[Ananthu C V]

From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>

The SoC Control Processor (SoCCP) is a small RISC-V MCU that controls
USB Type-C, battery charging and various other functions on Qualcomm SoCs.
It provides a solution for control-plane processing, reducing per-subsystem
microcontroller reinvention. Add PAS loader for SoCCP on Glymur DT.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur-crd.dtsi |  7 +++++
 arch/arm64/boot/dts/qcom/glymur.dtsi     | 44 ++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index e784b538f42e..328eb513140f 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -585,6 +585,13 @@ &remoteproc_cdsp {
 	status = "okay";
 };
 
+&remoteproc_soccp {
+	firmware-name = "qcom/glymur/soccp.mbn",
+			"qcom/glymur/soccp_dtb.mbn";
+
+	status = "okay";
+};
+
 &tlmm {
 	gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
 			       <10 2>, /* OOB UART */
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 5f44f68efde2..bc259dfbaf0e 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -2297,6 +2297,50 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
 			};
 		};
 
+		remoteproc_soccp: remoteproc@d00000 {
+			compatible = "qcom,glymur-soccp-pas";
+			reg = <0x0 0x00d00000 0x0 0x200000>;
+
+			interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
+					      <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+					      <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+					      <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+					      <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+					      <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog",
+					  "fatal",
+					  "ready",
+					  "handover",
+					  "stop-ack",
+					  "pong";
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "xo";
+
+			power-domains = <&rpmhpd RPMHPD_CX>,
+					<&rpmhpd RPMHPD_MX>;
+			power-domain-names = "cx",
+					     "mx";
+
+			memory-region = <&soccp_mem>,
+					<&soccpdtb_mem>;
+
+			qcom,smem-states = <&soccp_smp2p_out 0>,
+					   <&soccp_smp2p_out 8>;
+			qcom,smem-state-names = "stop",
+						"ping";
+
+			glink-edge {
+				interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
+							     IPCC_MPROC_SIGNAL_GLINK_QMP
+							     IRQ_TYPE_EDGE_RISING>;
+				mboxes = <&ipcc IPCC_MPROC_SOCCP
+						IPCC_MPROC_SIGNAL_GLINK_QMP>;
+				qcom,remote-pid = <19>;
+				label = "soccp";
+			};
+		};
+
 		usb_hs_phy: phy@fa0000 {
 			compatible = "qcom,glymur-m31-eusb2-phy",
 				     "qcom,sm8750-m31-eusb2-phy";

-- 
2.43.0

Re: [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation

[Krzysztof Kozlowski]

On 03/07/2026 14:31, Ananthu C V wrote:
> Most Qualcomm platforms feature Gunyah hypervisor, which typically
> handles Stage 2 IOMMU configuration. Additionally, SHM bridge setup
> is required to enable memory protection for both remoteproc metadata
> and its memory regions. When the aforementioned hypervisor is absent,
> the operating system must perform these configurations instead. We've
> been relying on the iommu property being present for this, but for
> remoteprocs that are already running like SoCCP the mappings are already
> in place, and any attempt to recreate them while active would lead to smmu
> faults and a non-functional remoteproc. Fix this by adding a needs_tzmem
> flag which ensures tzmem and SHM bridge setup is performed independent to
> the iommu property being present.

Looks awfully like LLM written and considering obvious problem, this
feels vibe coded.

According to current docs YOU SHOULD add vibe-coding tag to the commit
when doing that.

>  static const struct of_device_id qcom_pas_of_match[] = {
>  	{ .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
> +	{ .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource },

Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.

>  	{ .compatible = "qcom,kaanapali-soccp-pas", .data = &kaanapali_soccp_resource },
>  	{ .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
>  	{ .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
> 


Best regards,
Krzysztof

Re: [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation

[Ananthu C V]

Hi Krzysztof,

On Fri, Jul 03, 2026 at 02:44:41PM +0200, Krzysztof Kozlowski wrote:
> On 03/07/2026 14:31, Ananthu C V wrote:
> > Most Qualcomm platforms feature Gunyah hypervisor, which typically
> > handles Stage 2 IOMMU configuration. Additionally, SHM bridge setup
> > is required to enable memory protection for both remoteproc metadata
> > and its memory regions. When the aforementioned hypervisor is absent,
> > the operating system must perform these configurations instead. We've
> > been relying on the iommu property being present for this, but for
> > remoteprocs that are already running like SoCCP the mappings are already
> > in place, and any attempt to recreate them while active would lead to smmu
> > faults and a non-functional remoteproc. Fix this by adding a needs_tzmem
> > flag which ensures tzmem and SHM bridge setup is performed independent to
> > the iommu property being present.
> 
> Looks awfully like LLM written and considering obvious problem, this
> feels vibe coded.
> 
> According to current docs YOU SHOULD add vibe-coding tag to the commit
> when doing that.

Part of the commit message is based on 5c720260e840, and the rest is all written
and readjusted manually. Every single line of change in the code also is fully
handwritten - well, typed - by me. I don't know where the feeling came from, but
please be relieved to know that there has been no involvement of AI here.

> >  static const struct of_device_id qcom_pas_of_match[] = {
> >  	{ .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
> > +	{ .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource },
> 
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.

I ran checkpatch well over twenty times before posting the series, and I did
it a few more times after seeing your reply. I did not run into any problems,
and as such I cannot understand the problem here.

I could not paste this into an external pastebin from my work pc due to policy
reasons, so please forgive me for sharing this extended paste here:

$ git status
On branch next-20260702
nothing to commit, working tree clean
$ b4 shazam https://lore.kernel.org/all/20260703-glymur-soccp-v4-0-b706c4c9b3e2@oss.qualcomm.com/
Looking up https://lore.kernel.org/all/20260703-glymur-soccp-v4-0-b706c4c9b3e2@oss.qualcomm.com/
Grabbing thread from lore.kernel.org/all/20260703-glymur-soccp-v4-0-b706c4c9b3e2@oss.qualcomm.com/t.mbox.gz
Checking for newer revisions
Grabbing search results from lore.kernel.org
Analyzing 8 messages in the thread
Analyzing 0 code-review messages
Checking attestation on all messages, may take a moment...
---
  ✗ [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation
  ✗ [PATCH v4 2/3] arm64: dts: qcom: fix SoCCP memory mappings for Glymur
  ✗ [PATCH v4 3/3] arm64: dts: qcom: add SoCCP DT node for Glymur
  ---
  ✗ No key: ed25519/ananthu.cv@oss.qualcomm.com
  ✓ Signed: DKIM/oss.qualcomm.com
---
Total patches: 3
---
Applying: remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation
Applying: arm64: dts: qcom: fix SoCCP memory mappings for Glymur
Applying: arm64: dts: qcom: add SoCCP DT node for Glymur
$ git log -3 --oneline
3aec83c4ebd4 (HEAD -> next-20260702) arm64: dts: qcom: add SoCCP DT node for Glymur
abb3c9998fbf arm64: dts: qcom: fix SoCCP memory mappings for Glymur
7a2db13e713d remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation
$ scripts/checkpatch.pl --strict -g HEAD~3..HEAD
-----------------------------------------------------------------------------------------------
Commit 7a2db13e713d ("remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation")
-----------------------------------------------------------------------------------------------
total: 0 errors, 0 warnings, 0 checks, 44 lines checked

Commit 7a2db13e713d ("remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation")
has no obvious style problems and is ready for submission.
------------------------------------------------------------------------------
Commit abb3c9998fbf ("arm64: dts: qcom: fix SoCCP memory mappings for Glymur")
------------------------------------------------------------------------------
total: 0 errors, 0 warnings, 0 checks, 17 lines checked

Commit abb3c9998fbf ("arm64: dts: qcom: fix SoCCP memory mappings for Glymur") has no obvious
style problems and is ready for submission.
----------------------------------------------------------------------
Commit 3aec83c4ebd4 ("arm64: dts: qcom: add SoCCP DT node for Glymur")
----------------------------------------------------------------------
total: 0 errors, 0 warnings, 0 checks, 63 lines checked

Commit 3aec83c4ebd4 ("arm64: dts: qcom: add SoCCP DT node for Glymur") has no obvious style
problems and is ready for submission.

> >  	{ .compatible = "qcom,kaanapali-soccp-pas", .data = &kaanapali_soccp_resource },
> >  	{ .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
> >  	{ .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
> > 
> 
> 
> Best regards,
> Krzysztof

Thank you for the review.

Best,
Ananthu

Re: [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation

[Krzysztof Kozlowski]

On 03/07/2026 16:35, Ananthu C V wrote:
> Hi Krzysztof,
> 
> On Fri, Jul 03, 2026 at 02:44:41PM +0200, Krzysztof Kozlowski wrote:
>> On 03/07/2026 14:31, Ananthu C V wrote:
>>> Most Qualcomm platforms feature Gunyah hypervisor, which typically
>>> handles Stage 2 IOMMU configuration. Additionally, SHM bridge setup
>>> is required to enable memory protection for both remoteproc metadata
>>> and its memory regions. When the aforementioned hypervisor is absent,
>>> the operating system must perform these configurations instead. We've
>>> been relying on the iommu property being present for this, but for
>>> remoteprocs that are already running like SoCCP the mappings are already
>>> in place, and any attempt to recreate them while active would lead to smmu
>>> faults and a non-functional remoteproc. Fix this by adding a needs_tzmem
>>> flag which ensures tzmem and SHM bridge setup is performed independent to
>>> the iommu property being present.
>>
>> Looks awfully like LLM written and considering obvious problem, this
>> feels vibe coded.
>>
>> According to current docs YOU SHOULD add vibe-coding tag to the commit
>> when doing that.
> 
> Part of the commit message is based on 5c720260e840, and the rest is all written
> and readjusted manually. Every single line of change in the code also is fully
> handwritten - well, typed - by me. I don't know where the feeling came from, but
> please be relieved to know that there has been no involvement of AI here.
> 
>>>  static const struct of_device_id qcom_pas_of_match[] = {
>>>  	{ .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
>>> +	{ .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource },
>>
>> Please run scripts/checkpatch.pl on the patches and fix reported
>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>> patches and (probably) fix more warnings. Some warnings can be ignored,
>> especially from --strict run, but the code here looks like it needs a
>> fix. Feel free to get in touch if the warning is not clear.
> 
> I ran checkpatch well over twenty times before posting the series, and I did
> it a few more times after seeing your reply. I did not run into any problems,
> and as such I cannot understand the problem here.
> 
> I could not paste this into an external pastebin from my work pc due to policy
> reasons, so please forgive me for sharing this extended paste here:


There is no qcom,glymur-soccp-pas documented here. It was in separate
patchset which is already bringing confusion - the documentation goes
with the user. If you keep things separate, expect such comments and no
reviews.

Best regards,
Krzysztof