core: qcom: add GPCE BAM crypto driver support by rehman688 · Pull Request #71 · qualcomm-linux/optee_os

rehman688 · 2026-09-15T07:12:07Z

This series adds support for the Qualcomm General Purpose Crypto
Engine (GPCE) using the BAM transport interface.

The series introduces:

HWIO adaptation layer
OP-TEE environment layer
BAM transport support
Crypto Engine HAL integration
drvcrypt cipher/hash/MAC wrappers

Supported algorithms:

AES ECB/CBC/CTR/CTS/XTS
DES/3DES ECB/CBC
SHA1/SHA2 family
HMAC-SHA1/224/256/384/512
AES-CMAC

Crypto payload transfers use BAM while register programming is
currently performed through HWIO.

…files Nord was the only Wildcat chip in the tree, so its GIC base addresses and DARE-TZ TZDRAM region settings were placed in the shared Wildcat architecture layer. Adding a second Wildcat chip with different addresses makes the architecture layer the wrong home for them. Move GICD_BASE and GICR_BASE from arch_config.h to nord/target_config.h, and move the DARE-TZ TZDRAM region configuration from qcom-arch.mk to nord/target.mk, so the shared Wildcat layer stays chip-agnostic. Add SPDX licence identifier to qcom-arch.mk while there. Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

Cacao is a Qualcomm XR chipset in the Wildcat architecture family, featuring an octa-core Oryon CPU, a GICv4 interrupt controller, and DARE-TZ in-line memory encryption managed by the TME root-of-trust. OP-TEE runs in a DARE-TZ protected DRAM region and does not need a separate DARE driver. Testing: Tested on Rumi. Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

Add PLATFORM=qcom-cacao build to the CI. Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com>

Shikra is a Qualcomm IoT chipset in the Bruin architecture family, featuring a quad-core Cortex-A55 CPU and a GICv3 interrupt controller. Tested optee boot-up on Shikra board. Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Harshal Dev <harshal.dev@oss.qualcomm.com>

Add PLATFORM=qcom-shikra build to the CI. Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

Fix the address mappings for DRAM on Nord IQ-10. DRAM0 has a size of 0x8000 0000 while DRAM1 starts at 0x8 8000 0000 with a size of 0x7 8000 0000. Also, there exists a DRAM2 region which the Linux kernel maps as HIGHMEM for allocating memory for userspace applications. Since this region starting at 0x88 0000 0000 is not mapped by OP-TEE, TEE_IOC_SHM_REGISTER ioctl fails because OP-TEE doesn't recognize it as Non-secure memory. Validated by running xtest 1002 after building OP-TEE with CFG_TEE_CORE_EMBED_INTERNAL_TESTS=y which was failing otherwise. Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>

Add a pseudo-TA for the Qualcomm Inline Crypto Engine (ICE) that lets the kernel dm-crypt/inline-crypt path program raw software keys into ICE key slots for inline storage encryption. Two commands are exposed: - PTA_CMD_ICE_INVALIDATE_KEY: wipe a key slot with random data. - PTA_CMD_ICE_SET_CONFIG_KEY: program key/salt, cipher mode and data-unit size for AES-XTS-128/256 and AES-CBC-128/256. Only the REE kernel may open a session on this PTA. The PTA is gated by CFG_ICE_FS_ENC_PTA and is not built unless a platform enables it. Signed-off-by: Harikrishna <hart@qti.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>

Turn on CFG_ICE_FS_ENC_PTA for ipq52xx and ipq96xx, which carry the SDCC ICE block used for eMMC inline encryption, and point the generic ICE_LUT_KEYS at the SDCC LUT-keys register region. Testing: Booted to the kernel, dispatched an ICE software-key config from the kernel to this PTA, then wrote and read back a file on the encrypted filesystem and confirmed matching md5sums. Tested-on: IPQ52xx, IPQ96xx Signed-off-by: Harikrishna <hart@qti.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>

This file already lives under drivers/clk/qcom/, so repeating qcom in its own name is redundant, and inconsistent with how other vendor subdirectories (sam/, stm32) name their own files. Signed-off-by: Naresh Nunna <nnunna@qti.qualcomm.com> Assisted-by: Claude:opus-5 Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Reviewed-by: Vinod Kumar Amanaganti <vinoda@qti.qualcomm.com>

The QUP SE clock driver's CX/MX voltage vote needs a rail's supported corner ordinals, which for ARC resources live in the auxiliary data blob RPMh commands index into rather than a raw voltage. Add cmd_db_get_aux() to fetch it by resource ID. Signed-off-by: Naresh Nunna <nnunna@qti.qualcomm.com> Assisted-by: Claude:opus-5 Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Reviewed-by: Vinod Kumar Amanaganti <vinoda@qti.qualcomm.com>

Some clock rates need a higher CX/MX voltage corner than others, and a corner may be shared by multiple RCGs; rail_vote() refcounts per corner over RPMh so each rail is only raised for as long as some caller actually needs it, and CX/MX are resolved independently since they don't necessarily share the same hlvl encoding. Signed-off-by: Naresh Nunna <nnunna@qti.qualcomm.com> Assisted-by: Claude:opus-5 Assisted-by: Claude:sonnet-5 Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Reviewed-by: Vinod Kumar Amanaganti <vinoda@qti.qualcomm.com>

Lemans has no secure DT, so register each QUPv3 SE clock as a plain struct clk, modeling the PLL/RCG/branch as separate objects so the generic framework's own refcounting governs each PLL vote. Signed-off-by: Naresh Nunna <nnunna@qti.qualcomm.com> Assisted-by: Claude:opus-5 Assisted-by: Claude:sonnet-5 Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Reviewed-by: Vinod Kumar Amanaganti <vinoda@qti.qualcomm.com>

The RPMh command MSGID encodes a MSG_LENGTH field describing the payload length, in bytes, of the command. This field was hardcoded to 1 which is leading to unpredictable behavior on the AOP side (including the command never being acknowledged, causing timeouts). Changing it to 8 (the correct length for the single 32-bit data word every RPMh command carries). Using MSGID_WRITE since it's a write command. Fixes: b6ff325 (drivers: qcom: rpmh: add RPMH client driver) Signed-off-by: Shivam Sanjay <shivsanj@qti.qualcomm.com> Reviewed-by: Dinesh Choudhary <idinesh@qti.qualcomm.com> Reviewed-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>

Add PAS support for the ipq96xx CDSP (Turing/NSP) remote processor: load the firmware and its DTB, program the QDSP6 boot registers, run the two-stage boot FSM, and handle shutdown/reset via GCC. Also adds the Turing clock bring-up. ipq96xx gates these windows to secure-only accesses via XPU, so a new qcom_pas_data::secure flag maps them MEM_AREA_IO_SEC instead of MEM_AREA_IO_NSEC; other platforms are unaffected. Testing: Built for PLATFORM_FLAVOR=ipq96xx and kodiak with aarch64-linux-gnu-. CDSP boot verified on ipq96xx hardware. Signed-off-by: Harikrishna <hart@qti.qualcomm.com>

Enable the PAS PTA and Qualcomm clock driver on ipq96xx, add the CDSP (Turing/NSP) register window bases (Turing, GCC, MPM2, TCSR), and register the PAS pseudo TA as an in-tree early TA. Testing: Built for PLATFORM_FLAVOR=ipq96xx with aarch64-linux-gnu-; the CDSP PAS and clock objects link into the image and the PAS early TA is signed. Signed-off-by: Harikrishna <hart@qti.qualcomm.com>

Add support for the Qualcomm General Purpose Crypto Engine (GPCE) using the BAM transport interface. This change integrates GPCE with the OP-TEE drvcrypt framework and provides hardware accelerated cipher, hash and MAC services. Supported cipher algorithms: - AES-128 ECB/CBC/CTR/CTS/XTS - AES-256 ECB/CBC/CTR/CTS/XTS - DES ECB/CBC - 3DES ECB/CBC Supported hash algorithms: - SHA1 - SHA224 - SHA256 - SHA384 - SHA512 Supported MAC algorithms: - HMAC-SHA1 - HMAC-SHA224 - HMAC-SHA256 - HMAC-SHA384 - HMAC-SHA512 - AES-CMAC-128 - AES-CMAC-256 The implementation reuses the mature Crypto Engine HAL and BAM transport layers while providing OP-TEE specific HWIO, environment and drvcrypt integration layers. Note: Programming Crypto Engine registers using BAM command elements is currently not functional on the target platform. As a result: - Crypto Engine register programming is performed through HWIO. - Crypto payload transfers between software and GPCE continue to use BAM. Register programming path: HWIO Payload data path: BAM Signed-off-by: mrehman <mrehman@qti.qualcomm.com>

Harshal Dev (harshaldev27) · 2026-09-16T06:24:31Z

Hi rehman688 ,

This is impossible to review in the present format unfortunately. Can you please reduce the size of the cover-letter to make it more concise? Also, please break this patch series into small bi-sectable patches each introducing one logical change. Also, at a high level I can see this isn't following the coding standards of the project. Please feed the coding standards to your AI agent and check against that. Also run check-patch script for help you with the format of patches.

Tony J Hamilton (TonyJH1) · 2026-09-16T15:20:09Z

Please ensure that all code has been tested, and remove all redundant/dead code. As Harshal say, split into multiple smaller patch sets that can be reviewed by the maintainers.

Tony J Hamilton (TonyJH1)

Split this patch set into manageable patches

Jorge A. Ramirez-Ortiz (ldts) · 2026-09-17T07:32:31Z

another thing we should discuss - at least internally - is the implicit decision made by placing the driver in core/drivers/ which means dropping the openssl/pkcs11 support. Are we sure we want to do this?
I havent looked at the code yet but crypto drivers (under the crypto API) sit on core/drivers/crypto/qcom/

Sumit Garg (b49020) · 2026-09-17T09:06:38Z

One more high level comment: since GPCE is a shared resource among Linux kernel and OP-TEE at runtime, have we run crypto tests in parallel on both sides?

I remember discussing with Bartosz Gołaszewski (@brgl) (Kernel GPCE maintainer) about BAM locking and stuff implemented in kernel driver. Are we taking care of any GPCE synchronization in OP-TEE?

Bartosz Gołaszewski (brgl) · 2026-09-17T09:48:07Z

One more high level comment: since GPCE is a shared resource among Linux kernel and OP-TEE at runtime, have we run crypto tests in parallel on both sides?

Thanks Sumit Garg (@b49020). I'd be interested in being able to run this kind of tests on sm8650 or lemans as it would potentially push the kernel changes forward.

Sumit Garg (b49020) · 2026-09-17T09:58:37Z

One more high level comment: since GPCE is a shared resource among Linux kernel and OP-TEE at runtime, have we run crypto tests in parallel on both sides?

Thanks Sumit Garg (Sumit Garg (@b49020)). I'd be interested in being able to run this kind of tests on sm8650 or lemans as it would potentially push the kernel changes forward.

Although this BAM based GPCE driver looks pretty much target agnostic, rehman688 can you confirm if it would work on Lemans as well with configs enabled?

For Lemans, steps to replicate open boot stack are here: https://ldts.github.io/qcom-buildroot/index.html

Note there was a register based GPCE driver port done earlier for Lemans here: OP-TEE/optee_os#7938, not sure if there can be any synchronization possible with direct register based approach.

Paulo Martins (paulosmartins) · 2026-09-17T15:24:28Z

Note there was a register based GPCE driver port done earlier for Lemans here: OP-TEE/optee_os#7938, not sure if there can be any synchronization possible with direct register based approach.

We should try to understand why this was ported like that and which use-cases it's targeting. The driver that Habeeb is porting also allows for a direct register approach, so it can also potentially replace the driver you're referring to

Split this patch set into manageable patches

Actually, one idea to reduce the size of the changes would be to first configure cryptolib using HWIO, and after that, add BAM support. What do you think rehman688 ?

rehman688 · 2026-09-18T11:05:52Z

Note there was a register based GPCE driver port done earlier for Lemans here: OP-TEE/optee_os#7938, not sure if there can be any synchronization possible with direct register based approach.

We should try to understand why this was ported like that and which use-cases it's targeting. The driver that Habeeb is porting also allows for a direct register approach, so it can also potentially replace the driver you're referring to

Split this patch set into manageable patches

Actually, one idea to reduce the size of the changes would be to first configure cryptolib using HWIO, and after that, add BAM support. What do you think rehman688 ?

I think it's better to split the series algorithm-wise. I'll start with hash support over the BAM path, then follow up with cipher and MAC support in separate series.

rehman688 · 2026-09-18T11:15:11Z

One more high level comment: since GPCE is a shared resource among Linux kernel and OP-TEE at runtime, have we run crypto tests in parallel on both sides?

Thanks Sumit Garg (Sumit Garg (Sumit Garg (@b49020))). I'd be interested in being able to run this kind of tests on sm8650 or lemans as it would potentially push the kernel changes forward.

Although this BAM based GPCE driver looks pretty much target agnostic, rehman688 can you confirm if it would work on Lemans as well with configs enabled?

For Lemans, steps to replicate open boot stack are here: https://ldts.github.io/qcom-buildroot/index.html

Note there was a register based GPCE driver port done earlier for Lemans here: OP-TEE/optee_os#7938, not sure if there can be any synchronization possible with direct register based approach.

Sumit Garg (@b49020) Yes, the driver is chipset-agnostic. For Lemans, we mainly need the Lemans-specific HWIO definitions generated from IPCAT and placed under the Lemans platform directory.

Sumit Garg (b49020) · 2026-09-18T11:15:45Z

rehman688 please just strip down the HWIO header to macros which are actually used. You can refer to the other Qcom driver HWIO headers reference how they were stripped off as well as adapted to match OP-TEE coding style.

rehman688 · 2026-09-18T11:21:04Z

One more high level comment: since GPCE is a shared resource among Linux kernel and OP-TEE at runtime, have we run crypto tests in parallel on both sides?

I remember discussing with Bartosz Gołaszewski (Bartosz Gołaszewski (@brgl)) (Kernel GPCE maintainer) about BAM locking and stuff implemented in kernel driver. Are we taking care of any GPCE synchronization in OP-TEE?

In BAM mode, synchronization is handled automatically by the driver. The driver acquires the GPCE when a crypto operation starts and releases it when the operation completes, ensuring that only one operation uses the hardware at a time.

Sumit Garg (b49020) · 2026-09-18T11:24:17Z

Note there was a register based GPCE driver port done earlier for Lemans here: OP-TEE/optee_os#7938, not sure if there can be any synchronization possible with direct register based approach.

We should try to understand why this was ported like that and which use-cases it's targeting. The driver that Habeeb is porting also allows for a direct register approach, so it can also potentially replace the driver you're referring to

Paulo Martins (@paulosmartins) open source development is always incremental in nature. So it's natural for people to build on top of each other's work. However, what we would really like to understand is the difference among BAM and register based approach? How is the runtime synchronization maintained with the Linux kernel GPCE driver?

The use-case remains the same here for both implementations to offload crypto to GPCE in OP-TEE for Qualcomm platforms. One should use the extensive OP-TEE xtest suite to validate all the GPCE crypto offload. Have we tested that?

Sumit Garg (b49020) · 2026-09-18T11:28:07Z

As an example this OP-TEE/optee_os#7938 was tested on Lemans using the xtest. I would also like us to run kernel crypto tests in parallel with GPCE. Bartosz Gołaszewski (@brgl) can you provide information how to execute them?

Paulo Martins (paulosmartins) · 2026-09-17T13:01:52Z

@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: BSD-3-Clause


Let's add comments describing what the structures and functions in this file do

Paulo Martins (paulosmartins) · 2026-09-17T13:02:57Z

+typedef enum { BAM_DEVICE_MAPPING=0x0, BAM_MEMORY_MAPPING=0x1 } bam_mapping_op_type;
+typedef struct { uint64_t pa; bam_vaddr va; uint32_t size; void *handle; } bam_osal_meminfo;
+
+typedef struct _bamconfig {


Naming of the structures is not consistent (_bamconfig vs _PipeConfig vs _bam_result_type vs no name)

Paulo Martins (paulosmartins) · 2026-09-17T13:05:36Z

+bam_status_type bam_pipe_poll(bam_handle pipehandle, bam_result_type *result);
+
+#define BAM_MAX_MMAP 0x2800
+#define BAM_EE_TRUST 3


Will this collide with QTVM?

Paulo Martins (paulosmartins) · 2026-09-17T13:08:02Z

+//extract the LSB 32 bits of a 36 bit address
+#define ADDR_LPAE_LSB(x) ((uint32_t)((x) & 0xFFFFFFFF))
+
+/*


Let's move macros derived from IPCAT to a separate header:

bam.h should only include the APIs used externally (during initialization and by GPCE)
bam_hwio.h can include this hardware abstraction layer used by the BAM driver

Paulo Martins (paulosmartins) · 2026-09-17T13:12:20Z

+#include <trace.h>
+#include <malloc.h>
+
+/* OP-TEE: this driver only ever talks to one BAM instance (its PA/VA come


This comment doesn't explain what each bit in BAM_CNFG_BITS_VAL does. I'd suggest getting the macros for the fields obtained from IPCAT and to derive its value from a concatenation of what we want enabled

Paulo Martins (paulosmartins) · 2026-09-18T12:22:38Z

+
+static struct qce_hash_ctx *to_qce_ctx(struct crypto_hash_ctx *ctx)
+{
+        return container_of(ctx, struct qce_hash_ctx, base);


I don't think we need container_of, since base is the first element of the struct you can directly cast between pointers

Paulo Martins (paulosmartins) · 2026-09-21T09:45:57Z

+ */
+
+/*
+ * init — call SHA*_CE_BAM_init() directly, bypassing uclib_hash_init().


If we're not including uclib here, we can remove uclib from the comments. Also, this comment doesn't seem corrrect, this is not calling SHA*_CE_BAM_init

Paulo Martins (paulosmartins) · 2026-09-21T09:50:18Z

+                 * last=false whenever the message length is an exact
+                 * multiple of the block size, corrupting the digest. */
+                if (c->blk_len == c->blk_sz) {
+                        int ret = SHA_CMN_BAM_xfer_payload(c->bam_ctx,


This is very slow, why are we only sending one block at a time?

There's no need for a while here. We should

Fill block as much as possible
If block is full send it to GPCE
If there's still input left send the maximum number of blocks possible out of the remaining input
If there's still input left copy it to block

Paulo Martins (paulosmartins) · 2026-09-21T09:50:54Z

+	if (dupdate->dst.length < dupdate->src.length)
+		return TEE_ERROR_SHORT_BUFFER;
+
+	ret = CIPHER_BAM_cipher(&c->uctx, dupdate->src.data, dupdate->src.length,


Why aren't we taking care of splitting data into blocks here like in qce_hash.c?

Paulo Martins (paulosmartins) · 2026-09-21T09:51:27Z

+
+static void qce_cipher_final(void *ctx __unused)
+{
+	/* Nothing to do — CIPHER_BAM_cipher() already saw last=true in the


Wouldn't we have to send whatever is left of a block here?

Paulo Martins (paulosmartins)

We can try to look at ways to break this code review into smaller ones (we can do it algorithm-wise as you suggest)

We should try to integrate these changes into xtest

Paulo Martins (paulosmartins) · 2026-09-21T10:08:03Z

Note there was a register based GPCE driver port done earlier for Lemans here: OP-TEE/optee_os#7938, not sure if there can be any synchronization possible with direct register based approach.

We should try to understand why this was ported like that and which use-cases it's targeting. The driver that Habeeb is porting also allows for a direct register approach, so it can also potentially replace the driver you're referring to

Paulo Martins (Paulo Martins (@paulosmartins)) open source development is always incremental in nature. So it's natural for people to build on top of each other's work. However, what we would really like to understand is the difference among BAM and register based approach? How is the runtime synchronization maintained with the Linux kernel GPCE driver?

The use-case remains the same here for both implementations to offload crypto to GPCE in OP-TEE for Qualcomm platforms. One should use the extensive OP-TEE xtest suite to validate all the GPCE crypto offload. Have we tested that?

BAM uses a DMA to transfer data between memory and GPCE, whereas directly accessing registers doesn't (making it slower). When accessing GPCE via BAM, we can set a lock bit in the command descriptors that prevents the crypto accelerator from being used by other EEs. The changes in OP-TEE/optee_os#7938 don't make use of this and would have caused errors when accessing the crypto accelerator while HLOS was using it

Jorge A. Ramirez-Ortiz (ldts) · 2026-09-21T10:13:38Z

Sumit Garg (@b49020) a crypto driver that is being used as a generic driver is fishy to me. I wont nack it but wont review it further.

Sumit Garg (b49020) · 2026-09-21T10:38:08Z

Sumit Garg (Sumit Garg (@b49020)) a crypto driver that is being used a generic driver is fishy to me. I wont nack it but wont review it further.

Yeah for sure this GPCE driver has to sit under core/drivers/crypto/qcom plugging into OP-TEE HW crypto abstraction APIs.

Jorge A. Ramirez-Ortiz (ldts) · 2026-09-21T12:44:54Z

We can try to look at ways to break this code review into smaller ones (we can do it algorithm-wise as you suggest)

We should try to integrate these changes into xtest

Put the crypto driver under the crypto API to execute the cryptograhic suite that xtest already provides. Unless things have changed, the role of xtest is not to validate platform dependent PTAs or drivers.

pawarai123 and others added 16 commits September 7, 2026 13:09

ci: qcom: add cacao platform build

9811351

Add PLATFORM=qcom-cacao build to the CI. Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com>

ci: qcom: add shikra platform build

dab3efd

Add PLATFORM=qcom-shikra build to the CI. Signed-off-by: Pawan Rai <pawarai@qti.qualcomm.com> Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

Tony J Hamilton (TonyJH1) self-requested a review September 16, 2026 15:18

Tony J Hamilton (TonyJH1) requested changes Sep 16, 2026

View reviewed changes

rehman688 marked this pull request as draft September 17, 2026 10:58

Paulo Martins (paulosmartins) suggested changes Sep 21, 2026

View reviewed changes

Sumit Garg (b49020) force-pushed the qcom-next branch from 5fde2c5 to 9b756a1 Compare September 30, 2026 12:25

Conversation

rehman688 commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Harshal Dev (harshaldev27) commented Sep 16, 2026

Uh oh!

Tony J Hamilton (TonyJH1) commented Sep 16, 2026

Uh oh!

Tony J Hamilton (TonyJH1) left a comment

Choose a reason for hiding this comment

Uh oh!

Jorge A. Ramirez-Ortiz (ldts) commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sumit Garg (b49020) commented Sep 17, 2026

Uh oh!

Bartosz Gołaszewski (brgl) commented Sep 17, 2026

Uh oh!

Sumit Garg (b49020) commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Paulo Martins (paulosmartins) commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rehman688 commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rehman688 commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sumit Garg (b49020) commented Sep 18, 2026

Uh oh!

rehman688 commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sumit Garg (b49020) commented Sep 18, 2026

Uh oh!

Sumit Garg (b49020) commented Sep 18, 2026

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!

Paulo Martins (paulosmartins) 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!

Paulo Martins (paulosmartins) commented Sep 21, 2026

Uh oh!

Jorge A. Ramirez-Ortiz (ldts) commented Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sumit Garg (b49020) commented Sep 21, 2026

Uh oh!

Jorge A. Ramirez-Ortiz (ldts) commented Sep 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

rehman688 commented Sep 15, 2026 •

edited

Loading

Jorge A. Ramirez-Ortiz (ldts) commented Sep 17, 2026 •

edited

Loading

Sumit Garg (b49020) commented Sep 17, 2026 •

edited

Loading

Paulo Martins (paulosmartins) commented Sep 17, 2026 •

edited

Loading

rehman688 commented Sep 18, 2026 •

edited

Loading

rehman688 commented Sep 18, 2026 •

edited

Loading

rehman688 commented Sep 18, 2026 •

edited

Loading

Paulo Martins (paulosmartins) left a comment •

edited

Loading

Jorge A. Ramirez-Ortiz (ldts) commented Sep 21, 2026 •

edited

Loading