STRUCT S5P_AES_DEV(9)

💅 struct s5p_aes_dev(9) 💅

okay bestie, this is the Kernel API Manual page for struct s5p_aes_dev(9), and she is the crypto device state container. Not me being obsessed with a kernel struct, but here we are — main character energy, no cap. 💖

✨ NAME ✨

struct s5p_aes_dev — crypto device state container. That's the whole name, and honestly it's giving exactly what it needs to give. 👑

🦋 SYNOPSIS 🦋

Here's the struct in all her glory, copied exactly so nothing gets renamed, merged, or invented:

struct s5p_aes_dev {
    struct device                   *dev;
    struct clk                      *clk;
    struct clk                      *pclk;
    void __iomem                    *ioaddr;
    void __iomem                    *aes_ioaddr;
    int irq_fc;
    struct skcipher_request         *req;
    struct s5p_aes_ctx              *ctx;
    struct scatterlist              *sg_src;
    struct scatterlist              *sg_dst;
    struct scatterlist              *sg_src_cpy;
    struct scatterlist              *sg_dst_cpy;
    struct tasklet_struct           tasklet;
    struct crypto_queue             queue;
    bool busy;
    spinlock_t lock;
    struct resource                 *res;
    void __iomem                    *io_hash_base;
    spinlock_t hash_lock;
    unsigned long                   hash_flags;
    struct crypto_queue             hash_queue;
    struct tasklet_struct           hash_tasklet;
    u8 xmit_buf[BUFLEN];
    struct ahash_request            *hash_req;
    struct scatterlist              *hash_sg_iter;
    unsigned int                    hash_sg_cnt;
    bool use_hash;
};

🎀 Members 🎀

okay so here's the member-by-member breakdown, iykyk:

• dev — associated device. The device she's tied to.
• clk — clock for accessing hardware. You need this clock to get at the hardware.
• pclk — APB bus clock necessary to access the hardware. The APB bus clock, and yes, it's necessary to access the hardware.
• ioaddr — mapped IO memory region. The mapped IO memory area.
• aes_ioaddr — per-varian offset for AES block IO memory. The per-varian offset for the AES block IO memory — keeping the original wording, bestie.
• irq_fc — feed control interrupt line. The feed control interrupt line.
• req — crypto request currently handled by the device. The crypto request the device is handling right now.
• ctx — configuration for currently handled crypto request. The config for the crypto request currently in progress.
• sg_src — scatter list with source data for currently handled block in device. This one is DMA-mapped into device.
• sg_dst — scatter list with destination data for currently handled block in device. This one is also DMA-mapped into device.
• sg_src_cpy — in case of unaligned access, copied scatter list with source data. Exactly that: the copied scatter list with source data when unaligned access happens.
• sg_dst_cpy — in case of unaligned access, copied scatter list with destination data. Same vibe, but destination data.
• tasklet — new request scheduling jib. Yep, jib. Iconic wording, we keep it.
• queue — crypto queue. The crypto queue.
• busy — indicates whether the device is currently handling some request thus it uses some of the fields from this state, like: req, ctx, sg_src/sg_dst (and copies). This essentially protects against concurrent access to these fields. Basically: she's the guard telling you whether those fields are in use.
• lock — lock for protecting both access to device hardware registers and fields related to current request (including the busy field). Both jobs, one lock. Slay.
• res — resources for hash. The resources for hash.
• io_hash_base — per-variant offset for HASH block IO memory. The per-variant offset for the HASH block IO memory.
• hash_lock — lock for protecting hash_req, hash_queue and hash_flags variable. The lock holding down those three.
• hash_flags — flags for current HASH op. Flags for the current HASH operation.
• hash_queue — async hash queue. The async hash queue.
• hash_tasklet — new HASH request scheduling job. The new HASH request scheduling job.
• xmit_buf — buffer for current HASH request transfer into SSS block. Buffer time for the current HASH request transfer into the SSS block.
• hash_req — current request sending to SSS HASH block. The current request being sent to the SSS HASH block.
• hash_sg_iter — scatterlist transferred through DMA into SSS HASH block. The scatterlist moved through DMA into the SSS HASH block.
• hash_sg_cnt — counter for hash_sg_iter. Counts the hash_sg_iter.
• use_hash — true if HASH algs enabled. Exactly that.

🌈 SEE ALSO 🌈

Kernel file ./drivers/crypto/s5p-sss.c is the home base, and here's the whole friend group:

• struct samsung_aes_variant(9)
• struct s5p_hash_reqctx(9)
• struct s5p_hash_ctx(9)
• s5p_set_dma_hashdata(9)
• s5p_hash_rx(9)
• s5p_hash_read_msg(9)
• s5p_hash_write_ctx_iv(9)
• s5p_hash_write_iv(9)
• s5p_hash_copy_result(9)
• s5p_hash_dma_flush(9)
• s5p_hash_dma_enable(9)
• s5p_hash_irq_disable(9)
• s5p_hash_irq_enable(9)
• s5p_hash_set_flow(9)
• s5p_ahash_dma_init(9)
• s5p_hash_write_ctrl(9)
• s5p_hash_xmit_dma(9)
• s5p_hash_copy_sgs(9)
• s5p_hash_copy_sg_lists(9)
• s5p_hash_prepare_sgs(9)
• s5p_hash_prepare_request(9)
• s5p_hash_update_dma_stop(9)
• s5p_hash_finish(9)
• s5p_hash_finish_req(9)
• s5p_hash_handle_queue(9)
• s5p_hash_tasklet_cb(9)
• s5p_hash_enqueue(9)
• s5p_hash_update(9)
• s5p_hash_final(9)
• s5p_hash_finup(9)
• s5p_hash_init(9)
• s5p_hash_digest(9)
• s5p_hash_cra_init_alg(9)
• s5p_hash_cra_init(9)
• s5p_hash_cra_exit(9)
• s5p_hash_export(9)
• s5p_hash_import(9)

mwah 💋 source/version: ./drivers/crypto; date: October 2026; and yes, we're still talking about struct s5p_aes_dev(9) — periodt. 🌈