handle_aead_req(9)

💖 NAME — handle_aead_req(9) 💖

okay bestie, welcome to the Kernel API Manual page for handle_aead_req(9). Its whole job is to submit a SPU request message for the next chunk of the current AEAD request. That's the assignment. That's the vibe. ✨

🦋 SYNOPSIS 🦋

int handle_aead_req (struct iproc_reqctx_s *rctx );

🎀 ARGUMENTS 🎀

• rctx — Crypto request context. That's the one and only argument, and yes she's essential. 💅

✨ DESCRIPTION ✨

okay so unlike other operation types, we assume the length of the request fits in a single SPU request message. aead_enqueue makes sure this is true. no cap. The comments for other op types regarding threads applies here as well — same energy, same rules. 🫶

Also, unlike incremental hash ops — where the spu returns the entire hash for truncated algs like sha-224 — the SPU returns just the truncated hash in response to aead requests. So digestsize is always ctx->digestsize here. That's the whole tea. 🍓

🔥 RETURN 🔥

• -EINPROGRESS: crypto request has been accepted and result will be returned asynchronously. Any other value indicates an error.

👑 SEE ALSO 👑

Kernel file ./drivers/crypto/bcm/cipher.c plus this whole iconic squad:

• select_channel(9)
• spu_skcipher_rx_sg_create(9)
• spu_skcipher_tx_sg_create(9)
• handle_skcipher_req(9)
• handle_skcipher_resp(9)
• spu_ahash_rx_sg_create(9)
• spu_ahash_tx_sg_create(9)
• handle_ahash_req(9)
• spu_hmac_outer_hash(9)
• ahash_req_done(9)
• handle_ahash_resp(9)
• spu_aead_rx_sg_create(9)
• spu_aead_tx_sg_create(9)
• handle_aead_resp(9)
• spu_chunk_cleanup(9)
• finish_req(9)
• spu_rx_callback(9)
• skcipher_enqueue(9)
• spu_no_incr_hash(9)
• aead_gcm_esp_setkey(9)
• rfc4543_gcm_esp_setkey(9)
• aead_ccm_esp_setkey(9)
• spu_functions_register(9)
• spu_mb_init(9)

— signed, sealed, slayed by ./drivers/crypto/bcm · October 2026 · handle_aead_req(9) 💅