handle_ahash_req(9)

💅 handle_ahash_req — like, the whole manual, but make it make sense

okay bestie, so this is handle_ahash_req(9) from the Kernel API Manual, and honestly? she's doing a lot. let's get into it 🫶

---

✨ NAME ✨

handle_ahash_req — it processes an asynchronous hash request coming in from the crypto API. that's the whole vibe. no cap.

---

🦋 SYNOPSIS 🦋

int handle_ahash_req (struct iproc_reqctx_s *rctx );

like, that's it. that's the signature. iconic.

---

🎀 ARGUMENTS 🎀

• rctx — the crypto request context. she's the main character here, the whole context of the request, literally carrying everything 💜

---

🌸 DESCRIPTION 🌸

so what actually happens? this function builds a SPU request message that's embedded inside a mailbox message, and then submits that mailbox message on a selected mailbox channel. yes, a message inside a message. it's giving nesting dolls, it's giving iykyk ✨

the SPU request message gets constructed as a scatterlist, and here's the slay part: it includes entries from the crypto API's src scatterlist so we avoid copying the data that needs to be hashed. no unnecessary copying, we're efficient in this house 💅

now, when does this get called? two situations, bestie:

• either it's called on the thread from the crypto API
• or — and this is the case where the crypto API request is too large to fit in a single SPU request message — it's called on the thread that invokes the receive callback with a response message

and because some operations need the response from one chunk before the next chunk can even be submitted, we always wait for the response for the previous chunk before submitting the next chunk. like, we're not gonna rush her. one thing at a time. 🧚

and since requests are submitted in lock step like this, there's no need to synchronize access to request data structures. periodt. no mutex drama, we don't need it 🔥

---

⭐ RETURN ⭐

• -EINPROGRESS — the request has been submitted to the SPU and the response will come back asynchronously. she's out there, she's working, you'll hear from her 🦋
• -EAGAIN — a non-final request included a small amount of data, and for efficiency we did not submit it to the SPU, but instead stored it to be submitted to the SPU with the next part of the request. tiny data, saved for later, lowkey smart 🙈
• other — an error code. yeah. something went wrong. 😭

---

👑 SEE ALSO 👑

• Kernel file ./drivers/crypto/bcm/cipher.c
• 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)
• 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_req(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)

---

okay that's the whole page, nothing skipped, nothing invented — go read the source, bestie, it's right there in the kernel file 💖

and that's a wrap! 🎀 this little page lives in ./drivers/crypto/bcm, dated October 2026, and it went out as handle_ahash_req(9) in the Kernel API Manual. mwah. 💋