drivers/crypto/marvell/cesa/hash.c
Source file repositories/reference/linux-study-clean/drivers/crypto/marvell/cesa/hash.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/crypto/marvell/cesa/hash.c- Extension
.c- Size
- 36640 bytes
- Lines
- 1455
- Domain
- Driver Families
- Bucket
- drivers/crypto
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
crypto/hmac.hcrypto/md5.hcrypto/sha1.hcrypto/sha2.hlinux/device.hlinux/dma-mapping.hcesa.h
Detected Declarations
struct mv_cesa_ahash_dma_iterfunction mv_cesa_ahash_req_iter_initfunction mv_cesa_ahash_req_iter_next_opfunction mv_cesa_ahash_dma_alloc_cachefunction mv_cesa_ahash_dma_free_cachefunction mv_cesa_ahash_dma_alloc_paddingfunction mv_cesa_ahash_dma_free_paddingfunction mv_cesa_ahash_dma_last_cleanupfunction mv_cesa_ahash_dma_cleanupfunction mv_cesa_ahash_cleanupfunction mv_cesa_ahash_last_cleanupfunction mv_cesa_ahash_pad_lenfunction mv_cesa_ahash_pad_reqfunction mv_cesa_ahash_std_stepfunction mv_cesa_ahash_std_processfunction mv_cesa_ahash_dma_preparefunction mv_cesa_ahash_std_preparefunction mv_cesa_ahash_dma_stepfunction mv_cesa_ahash_stepfunction mv_cesa_ahash_processfunction mv_cesa_ahash_completefunction mv_cesa_ahash_preparefunction mv_cesa_ahash_req_cleanupfunction mv_cesa_ahash_initfunction mv_cesa_ahash_cra_initfunction mv_cesa_ahash_cache_reqfunction mv_cesa_dma_add_fragfunction mv_cesa_ahash_dma_add_cachefunction mv_cesa_ahash_dma_last_reqfunction mv_cesa_ahash_dma_req_initfunction mv_cesa_ahash_req_initfunction mv_cesa_ahash_queue_reqfunction mv_cesa_ahash_updatefunction mv_cesa_ahash_finalfunction mv_cesa_ahash_finupfunction mv_cesa_ahash_exportfunction mv_cesa_ahash_importfunction mv_cesa_md5_initfunction mv_cesa_md5_exportfunction mv_cesa_md5_importfunction mv_cesa_md5_digestfunction mv_cesa_sha1_initfunction mv_cesa_sha1_exportfunction mv_cesa_sha1_importfunction mv_cesa_sha1_digestfunction mv_cesa_sha256_initfunction mv_cesa_sha256_digestfunction mv_cesa_sha256_export
Annotated Snippet
struct mv_cesa_ahash_dma_iter {
struct mv_cesa_dma_iter base;
struct mv_cesa_sg_dma_iter src;
};
static inline void
mv_cesa_ahash_req_iter_init(struct mv_cesa_ahash_dma_iter *iter,
struct ahash_request *req)
{
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
unsigned int len = req->nbytes + creq->cache_ptr;
if (!creq->last_req)
len &= ~CESA_HASH_BLOCK_SIZE_MSK;
mv_cesa_req_dma_iter_init(&iter->base, len);
mv_cesa_sg_dma_iter_init(&iter->src, req->src, DMA_TO_DEVICE);
iter->src.op_offset = creq->cache_ptr;
}
static inline bool
mv_cesa_ahash_req_iter_next_op(struct mv_cesa_ahash_dma_iter *iter)
{
iter->src.op_offset = 0;
return mv_cesa_req_dma_iter_next_op(&iter->base);
}
static inline int
mv_cesa_ahash_dma_alloc_cache(struct mv_cesa_ahash_dma_req *req, gfp_t flags)
{
req->cache = dma_pool_alloc(cesa_dev->dma->cache_pool, flags,
&req->cache_dma);
if (!req->cache)
return -ENOMEM;
return 0;
}
static inline void
mv_cesa_ahash_dma_free_cache(struct mv_cesa_ahash_dma_req *req)
{
if (!req->cache)
return;
dma_pool_free(cesa_dev->dma->cache_pool, req->cache,
req->cache_dma);
}
static int mv_cesa_ahash_dma_alloc_padding(struct mv_cesa_ahash_dma_req *req,
gfp_t flags)
{
if (req->padding)
return 0;
req->padding = dma_pool_alloc(cesa_dev->dma->padding_pool, flags,
&req->padding_dma);
if (!req->padding)
return -ENOMEM;
return 0;
}
static void mv_cesa_ahash_dma_free_padding(struct mv_cesa_ahash_dma_req *req)
{
if (!req->padding)
return;
dma_pool_free(cesa_dev->dma->padding_pool, req->padding,
req->padding_dma);
req->padding = NULL;
}
static inline void mv_cesa_ahash_dma_last_cleanup(struct ahash_request *req)
{
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
mv_cesa_ahash_dma_free_padding(&creq->req.dma);
}
static inline void mv_cesa_ahash_dma_cleanup(struct ahash_request *req)
{
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
dma_unmap_sg(cesa_dev->dev, req->src, creq->src_nents, DMA_TO_DEVICE);
mv_cesa_ahash_dma_free_cache(&creq->req.dma);
mv_cesa_dma_cleanup(&creq->base);
}
static inline void mv_cesa_ahash_cleanup(struct ahash_request *req)
Annotation
- Immediate include surface: `crypto/hmac.h`, `crypto/md5.h`, `crypto/sha1.h`, `crypto/sha2.h`, `linux/device.h`, `linux/dma-mapping.h`, `cesa.h`.
- Detected declarations: `struct mv_cesa_ahash_dma_iter`, `function mv_cesa_ahash_req_iter_init`, `function mv_cesa_ahash_req_iter_next_op`, `function mv_cesa_ahash_dma_alloc_cache`, `function mv_cesa_ahash_dma_free_cache`, `function mv_cesa_ahash_dma_alloc_padding`, `function mv_cesa_ahash_dma_free_padding`, `function mv_cesa_ahash_dma_last_cleanup`, `function mv_cesa_ahash_dma_cleanup`, `function mv_cesa_ahash_cleanup`.
- Atlas domain: Driver Families / drivers/crypto.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.