drivers: qcom: ipcc: add IPCC driver and enable for shikra by pradeep-kondoju · Pull Request #110 · qualcomm-linux/optee_os

pradeep-kondoju · 2026-10-09T10:16:48Z

drivers: qcom: ipcc: enable IPCC for shikra

Secure-world clients on shikra need to signal RPM and receive its
replies. Shikra's IPCC runs in direct mode only: TZ raises RPM via
RPM_TZ_IPC[2:0] in APSS_SHARED_TZ_IPC and RPM returns on dedicated
GIC lines 198-200, so wire the MPROC protocol for RPM with those
three signals.

Signed-off-by: pradeep-kondoju skondoju@qti.qualcomm.com

spalepuqual · 2026-10-09T11:51:03Z

+TEE_Result ipcc_attach(struct ipcc_handle **h __unused,
+		       enum ipcc_protocol protocol __unused)
+{
+	return TEE_ERROR_NOT_SUPPORTED;


If we really intend to use a stub, we should be returning TEE_SUCCESS and not TEE_ERROR_NOT_SUPPORTED

My understanding is that if the driver is unsupported, clients may still invoke the APIs, and we notify them by returning an error.

That's not the case for any downstream qcom stub driver. They return success so that execution can proceed seamlessly. If we really want to indicate to the client that the driver is unsupported, we avoid enabling compilation.
Have you checked any upstream stub driver for reference?

I've gone with your second suggestion and dropped the stub entirely
rather than changing its return values, so the driver simply isn't compiled on
a chipset with no IPCC.

spalepuqual · 2026-10-09T15:30:19Z

+ * ipcc_core.c compiles ipcc_apply_block_cfg() unconditionally regardless, so
+ * these two still need a value even though this target never calls it.
+ */
+#define IPCC_TOP_MODE_BLOCK_OFF		UL(0x0)


These macros are not Shikra specific. Should be shifted to ipcc_regs.h

spalepuqual · 2026-10-09T15:39:14Z

+
+/* RPM_TZ_IPC[2:0]; three outbound bits is the hardware limit on AOP */
+#define IPCC_DIRECT_AOP_SIG0_MASK	BIT32(0)
+#define IPCC_DIRECT_AOP_SIG1_MASK	BIT32(1)


Though these are specific to Shikra, do we really need to put them in a common header at top level?
They are specifically for IPCC driver consumption.

Moved to Shikra specific config.

nnunna94 · 2026-10-13T04:48:09Z

+
+/* AOP is the only client this TEE reaches on MPROC */
+static const struct ipcc_client_cfg mproc_clients[] = {
+	{ .client = IPCC_CLIENT_AOP },


I believe we have use cases were our downstream drivers TZ needs to interact with MCU and others as well in shikra if i'm not wrong apart from AOP. I remember MPROC team asking for this support on downstream. can we check if there is such requirement in OPTEE as well.

This requires further input from the client. As of now, TZ supports HW-triggered communication between TZ and RPM. In our downstream driver, we are using the HYP lines in TZ, but it is unclear whether these are actually being utilized by the clients.

nnunna94 · 2026-10-13T04:55:53Z

+	return res;
+}
+
+static TEE_Result ipcc_direct_signal(struct ipcc_handle *h __unused,


consider renaming the APIs in this file... these seem to be AI named, losing a bit context.

renamed to trigger.

nnunna94 · 2026-10-13T04:57:53Z

+#include <util.h>
+
+/*
+ * The controller runs one of two mechanisms for the whole block, selected by


Also strip down the commentary here, we have documentation repo which needs updates for our drivers, https://github.com/OP-TEE/optee_docs, pls do plan to update the required concise documentation for our drivers here.

nnunna94 · 2026-10-13T06:12:07Z

+}
+
+/* Release every line this handle still holds, across all described clients */
+static void ipcc_direct_detach(struct ipcc_handle *h)


are we expecting clients to invoke only detach but not attach in case of direct connect? are clients really invoking this ? ideally clients invoke deregister and i see we are already doing this free line call there as well for cleaning up. why do we need this explicitly again ?

Agreed, this was redundant. It was a safety net in case a client called ipcc_detach() without deregistering first: the handle would be freed while its interrupt line, and the ISR's stale callback context, stayed live. Correct cleanup is the client's job, so I've removed the logic and made direct detach a no-op.

nnunna94

Can you add proper description message explaining why is this needed as crisp as possible, we can also tag any tested by tags if tested by client teams with due credits.

pradeep-kondoju · 2026-10-14T18:34:10Z

Can you add proper description message explaining why is this needed as crisp as possible, we can also tag any tested by tags if tested by client teams with due credits.
Done.

Secure-world drivers on Qualcomm SoCs need to signal other subsystems such as AOP and be notified back. That goes through the IPCC (Inter-Processor Communication Controller), which OP-TEE has no driver for. Add one exposing attach/detach, register/deregister interrupt and trigger, with a router and a direct backend picked by the controller's mode. Each chipset describes its clients and protocols in <PLATFORM_FLAVOR>/ipcc_config.c; a chipset without an IPCC leaves CFG_QCOM_IPCC unset and the driver is not built. Signed-off-by: pradeep-kondoju <skondoju@qti.qualcomm.com>

Secure-world clients on shikra need to signal AOP and receive its replies. Shikra's IPCC runs in direct mode only: TZ raises AOP via RPM_TZ_IPC[2:0] in APSS_SHARED_TZ_IPC and AOP returns on dedicated GIC lines 198-200, so wire the MPROC protocol for AOP with those three signals. Signed-off-by: pradeep-kondoju <skondoju@qti.qualcomm.com>

nnunna94 reviewed Oct 9, 2026

View reviewed changes

Comment thread MAINTAINERS Resolved

spalepuqual reviewed Oct 9, 2026

View reviewed changes

pradeep-kondoju force-pushed the early/hwe/shikra branch from 037d812 to 6b7e353 Compare October 9, 2026 15:29

spalepuqual reviewed Oct 9, 2026

View reviewed changes

pradeep-kondoju force-pushed the early/hwe/shikra branch 2 times, most recently from 07c0cb3 to 05c3457 Compare October 12, 2026 17:23

nnunna94 reviewed Oct 13, 2026

View reviewed changes

pradeep-kondoju force-pushed the early/hwe/shikra branch 3 times, most recently from 1d2e486 to c096ad8 Compare October 15, 2026 05:51

pradeep-kondoju added 2 commits October 16, 2026 11:43

pradeep-kondoju force-pushed the early/hwe/shikra branch from c096ad8 to 7bbf9e9 Compare October 16, 2026 06:13

Conversation

pradeep-kondoju commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spalepuqual Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nnunna94 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pradeep-kondoju commented Oct 14, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pradeep-kondoju commented Oct 9, 2026 •

edited

Loading

spalepuqual Oct 9, 2026 •

edited

Loading

nnunna94 left a comment •

edited

Loading