handle_skcipher_req(9)

✨ handle_skcipher_req(9) ✨

okay so real talk — this is a page straight out of the Kernel API Manual, bestie, and it's about handle_skcipher_req 💅

---

🌸 NAME 🌸

handle_skcipher_req — submit as much of a block cipher request as fits in a single SPU request message, starting at the current position in the request data 🎀

🦋 SYNOPSIS 🦋

int handle_skcipher_req (struct iproc_reqctx_s *rctx );

💖 ARGUMENTS 💖

• rctx — the crypto request context 🫶

🔥 DESCRIPTION 🔥

so here's the vibe: this may be called on the crypto API thread, or — and this is the main character moment — when a request is so large it must be broken into multiple SPU messages, it gets called on the thread used to invoke the response callback 😭

when requests are broken into multiple SPU messages, we assume subsequent messages depend on previous results, and thus always wait for previous results before submitting the next message ⭐

and because requests are submitted in lock step like this, there is no need to synchronize access to request data structures ✨ periodt.

👑 RETURN 👑

• -EINPROGRESS — 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 the whole squad, fr fr:

• select_channel(9)
• spu_skcipher_rx_sg_create(9)
• spu_skcipher_tx_sg_create(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_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)

---

that's the whole page, no notes 💜 this one lives in ./drivers/crypto/bcm and it's dated October 2026 — mwah, go read some kernel source bestie 🧚‍♀️🍓