drivers: crypto: qcom: CRYPTO0 CE cipher and AEAD support

[Amirreza Zarrabi (qc-azarrabi)]

This series adds AES-ECB, AES-CBC, and AES-GCM hardware acceleration for the Qualcomm CRYPTO0 crypto engine on Lemans SoCs, and prepares the existing HWKM driver to support the CRYPTO0 key manager slave.

Hardware overview

The CRYPTO0 crypto engine (CE) is a general-purpose AES accelerator present on Qualcomm SoCs. It exposes two data path interfaces:

• Register mode: the host writes plaintext and reads ciphertext through 32-bit MMIO DATA_IN/DATA_OUT FIFO registers, polling STATUS for completion. This is what the driver uses.
• BAM mode: a Bus Access Manager (DMA engine) feeds descriptors to the CE, allowing zero-copy transfers. BAM support is not implemented in this series. The hardware is capable of it, but BAM requires a separate descriptor protocol and interrupt infrastructure that is out of scope here. The register-mode path is sufficient for the OP-TEE use cases (tadb, TA cryptographic operations).

The CE supports AES-128 and AES-256. AES-192 is not implemented in hardware; the GCM driver falls back transparently to the software implementation for 24-byte keys.

For GCM, 96-bit nonces follow the standard J0 = nonce || 0x00000001 construction. For non-96-bit nonces (up to 128 bits), J0 is derived by feeding the nonce through the CE GHASH auth engine directly, avoiding any software GF(2^128) multiply.

The FIFO loop is byte-stream oriented: each 32-bit FIFO word is scattered/gathered byte-by-byte so payloads of any length are handled without alignment constraints on the caller. All polling loops are bounded by a 1-second timeout to avoid hanging the core on a wedged engine.

Series structure

Patches 1-2 prepare the existing HWKM driver. The register map is made group-relative and reusable across instances, and the CRYPTO0 KM slave is enabled so that keys can be provisioned into CRYPTO0 hardware key slots.

Patches 3-4 add the shared CE helper layer (register accessors, FIFO polling, config builders) and register the AES-ECB and AES-CBC drvcrypt cipher providers.

Patches 5-6 add the AES-GCM drvcrypt authenc provider and enable it on Lemans.

Testing

xtest 4003 (AES cipher operations) and xtest 4005 (AES-GCM) pass on Lemans hardware. The GCM provider is also exercised by the REE filesystem (tadb) which uses AES-GCM as its default authenticated encryption algorithm for TA storage.

[Jorge A. Ramirez-Ortiz (ldts)]

Functional bug: enc_final finalizes the operation before the SHORT_BUFFER check.

res = gcm_do_final(c, src, len, dst, tag_buf);   /* writes dst, consumes HW GCM state */
if (res)
        return res;
if (*tag_len < c->tag_len)
        return TEE_ERROR_SHORT_BUFFER;

The GP contract lets a caller retry an op that returns TEE_ERROR_SHORT_BUFFER with the same inputs, and the syscall layer (tee_svc_cryp.c) propagates the required tag_len back for exactly that. But here the hardware context is already finalised and dst already mutated, so a retry cannot succeed. The SW reference does the check first (core/crypto/aes-gcm.c:310, before operation_final()). Move the *tag_len < c->tag_len check ahead of gcm_do_final().

[Sumit Garg (b49020)]

Please rebase this PR to tip of qcom-next.