[PATCH RFC 0/2] Add binding and fix SoCCP carveout for booting Nord devices at EL2

[PATCH RFC 0/2] Add binding and fix SoCCP carveout for booting Nord devices at EL2

[Anurag Pateriya]

Nord embedded based boards currently boot Linux under a hypervisor 
that manages the IOMMU streams of the remote processor firmware. 
This series fixes the SoCCP binding to allow two iommus entries and 
maps the SoCCP carveout privileged-only to avoid a stage-1 permission 
fault on first instruction fetch.

Dependencies:

[PATCH v2 0/2] Add binding and driver for Nord SoCCP

https://lore.kernel.org/all/20261014-soccp_driver_dtbinding-v2-0-09d9c1378e9e@oss.qualcomm.com/

[PATCH v4 0/3] arm64: dts: qcom: nord: Enable SoCCP remoteproc support

https://lore.kernel.org/all/20261112-nord-soccp-dt-v4-0-af6e44e9f397@oss.qualcomm.com/

Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
---
Anurag Pateriya (1):
      dt-bindings: remoteproc: qcom,kaanapali-soccp-pas: Allow 2 IOMMUs for Nord

Bibek Kumar Patro (1):
      remoteproc: qcom_q6v5_pas: map SOCCP carveout privileged-only

 .../remoteproc/qcom,kaanapali-soccp-pas.yaml        | 21 ++++++++++++++++++++-
 drivers/remoteproc/qcom_q6v5_pas.c                  | 16 +++++++++++++++-
 2 files changed, 35 insertions(+), 2 deletions(-)
---
base-commit: cb70f5c1654381390efba76b2feba8be2331b83f
change-id: 20261112-nord_embedded_el2-073e25c7289e

Best regards,
-- 
Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>

[PATCH RFC 1/2] dt-bindings: remoteproc: qcom,kaanapali-soccp-pas: Allow 2 IOMMUs for Nord

[Anurag Pateriya]

Nord SoCCP needs two IOMMU streams when Linux boots at EL2, but the
iommus limit of one inherited from qcom,pas-common.yaml rejects that.

Drop the pas-common reference, describe the properties locally and allow
two iommus entries for Nord SoCCP and one for the other compatibles.

Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
---
 .../remoteproc/qcom,kaanapali-soccp-pas.yaml        | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml
index c1911124e073..405291c769cb 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml
@@ -55,6 +55,10 @@ properties:
       - description: Firmware name of the SoC Control Processor
       - description: Firmware name of the SoCCP Devicetree
 
+  iommus:
+    minItems: 1
+    maxItems: 2
+
   memory-region:
     minItems: 1
     items:
@@ -87,15 +91,27 @@ properties:
     minItems: 2
     description: The names of the state bits used for SMP2P output
 
+  glink-edge:
+    $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
+    description:
+      Qualcomm G-Link subnode which represents communication edge, channels
+      and devices related to the SoCCP.
+    unevaluatedProperties: false
+
 required:
   - compatible
   - reg
   - memory-region
+  - clocks
+  - clock-names
+  - interrupts
+  - interrupt-names
+  - qcom,smem-states
+  - qcom,smem-state-names
   - power-domains
   - power-domain-names
 
 allOf:
-  - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
   - if:
       properties:
         compatible:
@@ -111,6 +127,9 @@ allOf:
       properties:
         firmware-name:
           minItems: 2
+        # Only Nord SoCCP needs a second stream (see top-level iommus)
+        iommus:
+          maxItems: 1
         memory-region:
           minItems: 2
 

-- 
2.43.0

[PATCH RFC 2/2] remoteproc: qcom_q6v5_pas: map SOCCP carveout privileged-only

[Anurag Pateriya]

From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>

SOCCP is a RISC-V core whose instruction fetches go through the
SMMU in privilege mode

The memory region is mapped with IOMMU_READ | IOMMU_WRITE, which results
in permission fault when SOCCP fetches instruction, append IOMMU_PRIV to
mapping to allow it to fetch instructions.

Other PIL subsystems (e.g. Hexagon Q6) are not affected as their
instruction fetches do not go through the SMMU in privileged mode.

Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
---
 drivers/remoteproc/qcom_q6v5_pas.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index dfe67f32e537..43218039e3d5 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -84,6 +84,12 @@ struct qcom_pas_data {
 	int region_assign_vmid;
 	bool early_boot;
 	bool needs_tzmem;
+	/*
+	 * flag to map the carveout as privileged-only. Required for
+	 * subsystems such as SOCCP whose instruction fetches go through
+	 * the SMMU in privilege mode.
+	 */
+	bool iommu_priv;
 };
 
 struct qcom_pas {
@@ -112,6 +118,7 @@ struct qcom_pas {
 	int crash_reason_smem;
 	unsigned int smem_host_id;
 	bool decrypt_shutdown;
+	bool iommu_priv;
 	const char *info_name;
 
 	const struct firmware *firmware;
@@ -297,11 +304,16 @@ static void qcom_pas_unmap_carveout(struct rproc *rproc, phys_addr_t mem_phys, s
 
 static int qcom_pas_map_carveout(struct rproc *rproc, phys_addr_t mem_phys, size_t size)
 {
+	struct qcom_pas *pas = rproc->priv;
+	int prot = IOMMU_READ | IOMMU_WRITE;
 	int ret = 0;
 
+	if (pas->iommu_priv)
+		prot |= IOMMU_PRIV;
+
 	if (rproc->has_iommu)
 		ret = iommu_map(rproc->domain, mem_phys, mem_phys, size,
-				IOMMU_READ | IOMMU_WRITE, GFP_KERNEL);
+				prot, GFP_KERNEL);
 	return ret;
 }
 
@@ -961,6 +973,7 @@ static int qcom_pas_probe(struct platform_device *pdev)
 	pas->info_name = desc->sysmon_name;
 	pas->smem_host_id = desc->smem_host_id;
 	pas->decrypt_shutdown = desc->decrypt_shutdown;
+	pas->iommu_priv = desc->iommu_priv;
 	pas->proxy_pd_performance_states = desc->proxy_pd_performance_states;
 	pas->region_assign_idx = desc->region_assign_idx;
 	pas->region_assign_count = min_t(int, MAX_ASSIGN_COUNT, desc->region_assign_count);
@@ -1708,6 +1721,7 @@ static const struct qcom_pas_data nord_soccp_resource = {
 	.ssr_name = "soccp",
 	.sysmon_name = "soccp",
 	.auto_boot = true,
+	.iommu_priv = true,
 };
 
 static const struct qcom_pas_data sm8450_mpss_resource = {

-- 
2.43.0

Re: [PATCH RFC 2/2] remoteproc: qcom_q6v5_pas: map SOCCP carveout privileged-only

[Shawn Guo]

On Fri, Nov 13, 2026 at 05:54:13PM +0530, Anurag Pateriya wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> 
> SOCCP is a RISC-V core whose instruction fetches go through the
> SMMU in privilege mode
> 
> The memory region is mapped with IOMMU_READ | IOMMU_WRITE, which results
> in permission fault when SOCCP fetches instruction, append IOMMU_PRIV to
> mapping to allow it to fetch instructions.

This says what fails and what makes it go away, but not why. A reader
can't tell from this why an RW mapping is fine for a data access but
faults on an instruction fetch, or why IOMMU_PRIV fixes it.

As I understand it, the chain is:

- Without IOMMU_PRIV, io-pgtable-arm sets AP[1] in the stage-1 PTE,
  so the carveout ends up AP[2:1] = 0b01, i.e. writable at the
  unprivileged level.

- In the VMSAv8-64 stage-1 permission model, memory writable at the
  unprivileged level is implicitly privileged-execute-never,
  regardless of PXN.

- SoCCP fetches arrive as privileged instruction transactions, so
  the first fetch takes a stage-1 permission fault (FSR.PF,
  FSYNR0.IND=1).

- IOMMU_PRIV clears AP[1] (AP[2:1] = 0b00, privileged RW only),
  which removes the implicit PXN.

Something along these lines:

  On Nord, when Linux runs at EL2 it owns the SoCCP stream and the
  remoteproc core maps the firmware carveout through a stage-1 SMMU
  context bank. qcom_pas_map_carveout() uses IOMMU_READ | IOMMU_WRITE
  without IOMMU_PRIV, so io-pgtable-arm builds stage-1 PTEs with
  AP[2:1] = 0b01: read/write at both privileged and unprivileged
  level.

  SoCCP is a RISC-V core whose instruction fetches reach the SMMU as
  privileged transactions. In the VMSAv8-64 stage-1 permission model,
  memory that is writable at the unprivileged level is implicitly
  privileged-execute-never, regardless of the PXN bit in the PTE. The
  first SoCCP instruction fetch after PAS authentication therefore
  takes a stage-1 permission fault (FSR.PF, FSYNR0.IND=1).

  Map the SoCCP carveout with IOMMU_PRIV, so the stage-1 PTEs are
  privileged read/write only (AP[2:1] = 0b00). This removes the
  implicit privileged-execute-never and lets SoCCP fetch from the
  carveout.

  Other PIL subsystems (e.g. Hexagon Q6) are not affected as their
  instruction fetches do not go through the SMMU in privileged mode.

Another nit: please use SoCCP (instead of SOCCP) everywhere, e.g. patch
subject, for sake of consistency.

Shawn