Age | Commit message (Collapse) | Author |
|
Fix typo in the fallback code path.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506231830.us4hiwlZ-lkp@intel.com/
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The mapped SG lists are written to hash_engine->ahash_src_addr which
has the size ASPEED_HASH_SRC_DMA_BUF_LEN. Since scatterlists are
not bound in size, make sure that size is not exceeded.
If the mapped SG list is larger than the buffer, simply iterate
over it as is done in the dma_prepare case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Rather than failing a hash larger than ASPEED_CRYPTO_SRC_DMA_BUF_LEN,
just hash them over and over again until it's done.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
If a hash request fails due to a DMA mapping error, or if it is too
large to fit in the the driver buffer, use a fallback to do the hash
rather than failing.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Use the Crypto API partial block handling.
Also switch to the generic export format.
Remove final function that is no longer used by the Crypto API.
Move final padding into aspeed_ahash_dma_prepare_sg.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Removed unused sha_iv field from request context.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Rather than processing a final as two separate updates, combine
them into one for the linear dma_prepare case.
This means that the total hash size is slightly reduced, but that
will be fixed up later by repeating the hash if necessary.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The only time when sham_final needs to be called in sham_finup
is when the finup request fits into the partial block. Move this
special handling into sham_update.
The comment about releaseing resources is non-sense. The Crypto
API does not mandate the use of final so the user could always go
away after an update and never come back. Therefore the driver
must not hold any resources after an update call.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Instead of always writing the padding to rctx->buffer, make it
an argument.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Use the init_tfm interface instead of cra_init.
Also get rid of the dynamic reqsize.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The hmac implementation in aspeed simply duplicates what the new
ahash hmac template already does, namely construct ipad and opad
by hand and then adding them to the hash before feeding it to the
engine.
Remove them and just use the generic ahash hmac template.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Algorithms must never be added to a driver unless there is a generic
implementation. These truncated versions of sha512 slipped through.
Remove them as they are useless.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The callbacks for prepare and unprepare request in crypto_engine
is superfluous. They can be done directly from do_one_request.
Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
This patch fixes a bunch of bit endianness warnings and two missing
static modifiers.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: Neal Liu <neal_liu@aspeedtech.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
This fixes the following similar build warning when
enabling compile test:
aspeed-hace-hash.c:188:9: warning: format '%x' expects argument of type
'unsigned int', but argument 7 has type 'size_t' {aka 'long unsigned int'}
[-Wformat=]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Neal Liu <neal_liu@aspeedtech.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Hash and Crypto Engine (HACE) is designed to accelerate the
throughput of hash data digest, encryption, and decryption.
Basically, HACE can be divided into two independently engines
- Hash Engine and Crypto Engine. This patch aims to add HACE
hash engine driver for hash accelerator.
Signed-off-by: Neal Liu <neal_liu@aspeedtech.com>
Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com>
Reviewed-by: Dhananjay Phadke <dphadke@linux.microsoft.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|