Re: [PATCH v8 1/5] crypto: aspeed: Add HACE hash driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022/8/8 17:30, Neal Liu wrote:
>> -----Original Message-----
>> From: liulongfang <liulongfang@xxxxxxxxxx>
>> Sent: Monday, August 8, 2022 10:53 AM
>> To: Neal Liu <neal_liu@xxxxxxxxxxxxxx>; Corentin Labbe
>> <clabbe.montjoie@xxxxxxxxx>; Christophe JAILLET
>> <christophe.jaillet@xxxxxxxxxx>; Randy Dunlap <rdunlap@xxxxxxxxxxxxx>;
>> Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; David S . Miller
>> <davem@xxxxxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Krzysztof
>> Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Joel Stanley <joel@xxxxxxxxx>;
>> Andrew Jeffery <andrew@xxxxxxxx>; Dhananjay Phadke
>> <dhphadke@xxxxxxxxxxxxx>; Johnny Huang
>> <johnny_huang@xxxxxxxxxxxxxx>
>> Cc: linux-aspeed@xxxxxxxxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx;
>> devicetree@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
>> linux-kernel@xxxxxxxxxxxxxxx; BMC-SW <BMC-SW@xxxxxxxxxxxxxx>
>> Subject: Re: [PATCH v8 1/5] crypto: aspeed: Add HACE hash driver
>>
>>
>> On 2022/7/26 19:34, Neal Liu wrote:
>>> 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@xxxxxxxxxxxxxx>
>>> Signed-off-by: Johnny Huang <johnny_huang@xxxxxxxxxxxxxx>
>>> ---
>>>  MAINTAINERS                              |    7 +
>>>  drivers/crypto/Kconfig                   |    1 +
>>>  drivers/crypto/Makefile                  |    1 +
>>>  drivers/crypto/aspeed/Kconfig            |   32 +
>>>  drivers/crypto/aspeed/Makefile           |    6 +
>>>  drivers/crypto/aspeed/aspeed-hace-hash.c | 1389
>> ++++++++++++++++++++++
>>>  drivers/crypto/aspeed/aspeed-hace.c      |  213 ++++
>>>  drivers/crypto/aspeed/aspeed-hace.h      |  186 +++
>>>  8 files changed, 1835 insertions(+)
>>>  create mode 100644 drivers/crypto/aspeed/Kconfig
>>>  create mode 100644 drivers/crypto/aspeed/Makefile
>>>  create mode 100644 drivers/crypto/aspeed/aspeed-hace-hash.c
>>>  create mode 100644 drivers/crypto/aspeed/aspeed-hace.c
>>>  create mode 100644 drivers/crypto/aspeed/aspeed-hace.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index f55aea311af5..23a0215b7e42 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -3140,6 +3140,13 @@ S:	Maintained
>>>  F:	Documentation/devicetree/bindings/media/aspeed-video.txt
>>>  F:	drivers/media/platform/aspeed/
>>>
>>> +ASPEED CRYPTO DRIVER
>>> +M:	Neal Liu <neal_liu@xxxxxxxxxxxxxx>
>>> +L:	linux-aspeed@xxxxxxxxxxxxxxxx (moderated for non-subscribers)
>>> +S:	Maintained
>>> +F:
>> 	Documentation/devicetree/bindings/crypto/aspeed,ast2500-hace.yaml
>>> +F:	drivers/crypto/aspeed/
>>> +
>>>  ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
>>>  M:	Corentin Chary <corentin.chary@xxxxxxxxx>
>>>  L:	acpi4asus-user@xxxxxxxxxxxxxxxxxxxxx
>>> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
>>> index ee99c02c84e8..b9f5ee126881 100644
>>> --- a/drivers/crypto/Kconfig
>>> +++ b/drivers/crypto/Kconfig
>>> @@ -933,5 +933,6 @@ config CRYPTO_DEV_SA2UL
>>>  	  acceleration for cryptographic algorithms on these devices.
>>>
>>>  source "drivers/crypto/keembay/Kconfig"
>>> +source "drivers/crypto/aspeed/Kconfig"
>>>
>>>  endif # CRYPTO_HW
>>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>>> index f81703a86b98..116de173a66c 100644
>>> --- a/drivers/crypto/Makefile
>>> +++ b/drivers/crypto/Makefile
>>> @@ -1,5 +1,6 @@
>>>  # SPDX-License-Identifier: GPL-2.0
>>>  obj-$(CONFIG_CRYPTO_DEV_ALLWINNER) += allwinner/
>>> +obj-$(CONFIG_CRYPTO_DEV_ASPEED) += aspeed/
>>>  obj-$(CONFIG_CRYPTO_DEV_ATMEL_AES) += atmel-aes.o
>>>  obj-$(CONFIG_CRYPTO_DEV_ATMEL_SHA) += atmel-sha.o
>>>  obj-$(CONFIG_CRYPTO_DEV_ATMEL_TDES) += atmel-tdes.o
>>> diff --git a/drivers/crypto/aspeed/Kconfig b/drivers/crypto/aspeed/Kconfig
>>> new file mode 100644
>>> index 000000000000..059e627efef8
>>> --- /dev/null
>>> +++ b/drivers/crypto/aspeed/Kconfig
>>> @@ -0,0 +1,32 @@
>>> +config CRYPTO_DEV_ASPEED
>>> +	tristate "Support for Aspeed cryptographic engine driver"
>>> +	depends on ARCH_ASPEED
>>> +	help
>>> +	  Hash and Crypto Engine (HACE) is designed to accelerate the
>>> +	  throughput of hash data digest, encryption and decryption.
>>> +
>>> +	  Select y here to have support for the cryptographic driver
>>> +	  available on Aspeed SoC.
>>> +
>>> +config CRYPTO_DEV_ASPEED_HACE_HASH
>>> +	bool "Enable Aspeed Hash & Crypto Engine (HACE) hash"
>>> +	depends on CRYPTO_DEV_ASPEED
>>> +	select CRYPTO_ENGINE
>>> +	select CRYPTO_SHA1
>>> +	select CRYPTO_SHA256
>>> +	select CRYPTO_SHA512
>>> +	select CRYPTO_HMAC
>>> +	help
>>> +	  Select here to enable Aspeed Hash & Crypto Engine (HACE)
>>> +	  hash driver.
>>> +	  Supports multiple message digest standards, including
>>> +	  SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and so on.
>>> +
>>> +config CRYPTO_DEV_ASPEED_HACE_HASH_DEBUG
>>> +	bool "Enable HACE hash debug messages"
>>> +	depends on CRYPTO_DEV_ASPEED_HACE_HASH
>>> +	help
>>> +	  Print HACE hash debugging messages if you use this option
>>> +	  to ask for those messages.
>>> +	  Avoid enabling this option for production build to
>>> +	  minimize driver timing.
>>> diff --git a/drivers/crypto/aspeed/Makefile
>> b/drivers/crypto/aspeed/Makefile
>>> new file mode 100644
>>> index 000000000000..8bc8d4fed5a9
>>> --- /dev/null
>>> +++ b/drivers/crypto/aspeed/Makefile
>>> @@ -0,0 +1,6 @@
>>> +obj-$(CONFIG_CRYPTO_DEV_ASPEED) += aspeed_crypto.o
>>> +aspeed_crypto-objs := aspeed-hace.o \
>>> +		      $(hace-hash-y)
>>> +
>>> +obj-$(CONFIG_CRYPTO_DEV_ASPEED_HACE_HASH) += aspeed-hace-hash.o
>>> +hace-hash-$(CONFIG_CRYPTO_DEV_ASPEED_HACE_HASH) :=
>> aspeed-hace-hash.o
>>> diff --git a/drivers/crypto/aspeed/aspeed-hace-hash.c
>> b/drivers/crypto/aspeed/aspeed-hace-hash.c
>>> new file mode 100644
>>> index 000000000000..63a8ad694996
>>> --- /dev/null
>>> +++ b/drivers/crypto/aspeed/aspeed-hace-hash.c
>>> @@ -0,0 +1,1389 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (c) 2021 Aspeed Technology Inc.
>>> + */
>>> +
>>> +#include "aspeed-hace.h"
>>> +
>>> +#ifdef CONFIG_CRYPTO_DEV_ASPEED_HACE_HASH_DEBUG
>>> +#define AHASH_DBG(h, fmt, ...)	\
>>> +	dev_info((h)->dev, "%s() " fmt, __func__, ##__VA_ARGS__)
>>> +#else
>>> +#define AHASH_DBG(h, fmt, ...)	\
>>> +	dev_dbg((h)->dev, "%s() " fmt, __func__, ##__VA_ARGS__)
>>> +#endif
>>> +
>>> +/* Initialization Vectors for SHA-family */
>>> +static const __be32 sha1_iv[8] = {
>>> +	cpu_to_be32(SHA1_H0), cpu_to_be32(SHA1_H1),
>>> +	cpu_to_be32(SHA1_H2), cpu_to_be32(SHA1_H3),
>>> +	cpu_to_be32(SHA1_H4), 0, 0, 0
>>> +};
>>> +
>>> +static const __be32 sha224_iv[8] = {
>>> +	cpu_to_be32(SHA224_H0), cpu_to_be32(SHA224_H1),
>>> +	cpu_to_be32(SHA224_H2), cpu_to_be32(SHA224_H3),
>>> +	cpu_to_be32(SHA224_H4), cpu_to_be32(SHA224_H5),
>>> +	cpu_to_be32(SHA224_H6), cpu_to_be32(SHA224_H7),
>>> +};
>>> +
>>> +static const __be32 sha256_iv[8] = {
>>> +	cpu_to_be32(SHA256_H0), cpu_to_be32(SHA256_H1),
>>> +	cpu_to_be32(SHA256_H2), cpu_to_be32(SHA256_H3),
>>> +	cpu_to_be32(SHA256_H4), cpu_to_be32(SHA256_H5),
>>> +	cpu_to_be32(SHA256_H6), cpu_to_be32(SHA256_H7),
>>> +};
>>> +
>>> +static const __be64 sha384_iv[8] = {
>>> +	cpu_to_be64(SHA384_H0), cpu_to_be64(SHA384_H1),
>>> +	cpu_to_be64(SHA384_H2), cpu_to_be64(SHA384_H3),
>>> +	cpu_to_be64(SHA384_H4), cpu_to_be64(SHA384_H5),
>>> +	cpu_to_be64(SHA384_H6), cpu_to_be64(SHA384_H7)
>>> +};
>>> +
>>> +static const __be64 sha512_iv[8] = {
>>> +	cpu_to_be64(SHA512_H0), cpu_to_be64(SHA512_H1),
>>> +	cpu_to_be64(SHA512_H2), cpu_to_be64(SHA512_H3),
>>> +	cpu_to_be64(SHA512_H4), cpu_to_be64(SHA512_H5),
>>> +	cpu_to_be64(SHA512_H6), cpu_to_be64(SHA512_H7)
>>> +};
>>> +
>>> +static const __be32 sha512_224_iv[16] = {
>>> +	cpu_to_be32(0xC8373D8CUL), cpu_to_be32(0xA24D5419UL),
>>> +	cpu_to_be32(0x6699E173UL), cpu_to_be32(0xD6D4DC89UL),
>>> +	cpu_to_be32(0xAEB7FA1DUL), cpu_to_be32(0x829CFF32UL),
>>> +	cpu_to_be32(0x14D59D67UL), cpu_to_be32(0xCF9F2F58UL),
>>> +	cpu_to_be32(0x692B6D0FUL), cpu_to_be32(0xA84DD47BUL),
>>> +	cpu_to_be32(0x736FE377UL), cpu_to_be32(0x4289C404UL),
>>> +	cpu_to_be32(0xA8859D3FUL), cpu_to_be32(0xC8361D6AUL),
>>> +	cpu_to_be32(0xADE61211UL), cpu_to_be32(0xA192D691UL)
>>> +};
>>> +
>>> +static const __be32 sha512_256_iv[16] = {
>>> +	cpu_to_be32(0x94213122UL), cpu_to_be32(0x2CF72BFCUL),
>>> +	cpu_to_be32(0xA35F559FUL), cpu_to_be32(0xC2644CC8UL),
>>> +	cpu_to_be32(0x6BB89323UL), cpu_to_be32(0x51B1536FUL),
>>> +	cpu_to_be32(0x19773896UL), cpu_to_be32(0xBDEA4059UL),
>>> +	cpu_to_be32(0xE23E2896UL), cpu_to_be32(0xE3FF8EA8UL),
>>> +	cpu_to_be32(0x251E5EBEUL), cpu_to_be32(0x92398653UL),
>>> +	cpu_to_be32(0xFC99012BUL), cpu_to_be32(0xAAB8852CUL),
>>> +	cpu_to_be32(0xDC2DB70EUL), cpu_to_be32(0xA22CC581UL)
>>> +};
>>> +
>>> +/* The purpose of this padding is to ensure that the padded message is a
>>> + * multiple of 512 bits (SHA1/SHA224/SHA256) or 1024 bits
>> (SHA384/SHA512).
>>> + * The bit "1" is appended at the end of the message followed by
>>> + * "padlen-1" zero bits. Then a 64 bits block (SHA1/SHA224/SHA256) or
>>> + * 128 bits block (SHA384/SHA512) equals to the message length in bits
>>> + * is appended.
>>> + *
>>> + * For SHA1/SHA224/SHA256, padlen is calculated as followed:
>>> + *  - if message length < 56 bytes then padlen = 56 - message length
>>> + *  - else padlen = 64 + 56 - message length
>>> + *
>>> + * For SHA384/SHA512, padlen is calculated as followed:
>>> + *  - if message length < 112 bytes then padlen = 112 - message length
>>> + *  - else padlen = 128 + 112 - message length
>>> + */
>>> +static void aspeed_ahash_fill_padding(struct aspeed_hace_dev *hace_dev,
>>> +				      struct aspeed_sham_reqctx *rctx)
>>> +{
>>> +	unsigned int index, padlen;
>>> +	__be64 bits[2];
>>> +
>>> +	AHASH_DBG(hace_dev, "rctx flags:0x%x\n", (u32)rctx->flags);
>>> +
>>> +	switch (rctx->flags & SHA_FLAGS_MASK) {
>>> +	case SHA_FLAGS_SHA1:
>>> +	case SHA_FLAGS_SHA224:
>>> +	case SHA_FLAGS_SHA256:
>>> +		bits[0] = cpu_to_be64(rctx->digcnt[0] << 3);
>>> +		index = rctx->bufcnt & 0x3f;
>>> +		padlen = (index < 56) ? (56 - index) : ((64 + 56) - index);
>>> +		*(rctx->buffer + rctx->bufcnt) = 0x80;
>>> +		memset(rctx->buffer + rctx->bufcnt + 1, 0, padlen - 1);
>>> +		memcpy(rctx->buffer + rctx->bufcnt + padlen, bits, 8);
>>> +		rctx->bufcnt += padlen + 8;
>>> +		break;
>>> +	default:
>>> +		bits[1] = cpu_to_be64(rctx->digcnt[0] << 3);
>>> +		bits[0] = cpu_to_be64(rctx->digcnt[1] << 3 |
>>> +				      rctx->digcnt[0] >> 61);
>>> +		index = rctx->bufcnt & 0x7f;
>>> +		padlen = (index < 112) ? (112 - index) : ((128 + 112) - index);
>>> +		*(rctx->buffer + rctx->bufcnt) = 0x80;
>>> +		memset(rctx->buffer + rctx->bufcnt + 1, 0, padlen - 1);
>>> +		memcpy(rctx->buffer + rctx->bufcnt + padlen, bits, 16);
>>> +		rctx->bufcnt += padlen + 16;
>>> +		break;
>>> +	}
>>> +}
>>> +
>>> +/*
>>> + * Prepare DMA buffer before hardware engine
>>> + * processing.
>>> + */
>>> +static int aspeed_ahash_dma_prepare(struct aspeed_hace_dev *hace_dev)
>>> +{
>>> +	struct aspeed_engine_hash *hash_engine = &hace_dev->hash_engine;
>>> +	struct ahash_request *req = hash_engine->req;
>>> +	struct aspeed_sham_reqctx *rctx = ahash_request_ctx(req);
>>> +	int length, remain;
>>> +
>>> +	length = rctx->total + rctx->bufcnt;
>>> +	remain = length % rctx->block_size;
>>> +
>>> +	AHASH_DBG(hace_dev, "length:0x%x, remain:0x%x\n", length, remain);
>>> +
>>> +	if (rctx->bufcnt)
>>> +		memcpy(hash_engine->ahash_src_addr, rctx->buffer, rctx->bufcnt);
>>> +
>>> +	if (rctx->total + rctx->bufcnt < ASPEED_CRYPTO_SRC_DMA_BUF_LEN) {
>>> +		scatterwalk_map_and_copy(hash_engine->ahash_src_addr +
>>> +					 rctx->bufcnt, rctx->src_sg,
>>> +					 rctx->offset, rctx->total - remain, 0);
>>> +		rctx->offset += rctx->total - remain;
>>> +
>>> +	} else {
>>> +		dev_warn(hace_dev->dev, "Hash data length is too large\n");
>>> +		return -EINVAL;
>>> +	}
>>> +
>>> +	scatterwalk_map_and_copy(rctx->buffer, rctx->src_sg,
>>> +				 rctx->offset, remain, 0);
>>> +
>>> +	rctx->bufcnt = remain;
>>> +	rctx->digest_dma_addr = dma_map_single(hace_dev->dev, rctx->digest,
>>> +					       SHA512_DIGEST_SIZE,
>>> +					       DMA_BIDIRECTIONAL);
>>> +	if (dma_mapping_error(hace_dev->dev, rctx->digest_dma_addr)) {
>>> +		dev_warn(hace_dev->dev, "dma_map() rctx digest error\n");
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	hash_engine->src_length = length - remain;
>>> +	hash_engine->src_dma = hash_engine->ahash_src_dma_addr;
>>> +	hash_engine->digest_dma = rctx->digest_dma_addr;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +/*
>>> + * Prepare DMA buffer as SG list buffer before
>>> + * hardware engine processing.
>>> + */
>>> +static int aspeed_ahash_dma_prepare_sg(struct aspeed_hace_dev
>> *hace_dev)
>>> +{
>>> +	struct aspeed_engine_hash *hash_engine = &hace_dev->hash_engine;
>>> +	struct ahash_request *req = hash_engine->req;
>>> +	struct aspeed_sham_reqctx *rctx = ahash_request_ctx(req);
>>> +	struct aspeed_sg_list *src_list;
>>> +	struct scatterlist *s;
>>> +	int length, remain, sg_len, i;
>>> +	int rc = 0;
>>> +
>>> +	remain = (rctx->total + rctx->bufcnt) % rctx->block_size;
>>> +	length = rctx->total + rctx->bufcnt - remain;
>>> +
>>> +	AHASH_DBG(hace_dev, "%s:0x%x, %s:0x%x, %s:0x%x, %s:0x%x\n",
>>> +		  "rctx total", rctx->total, "bufcnt", rctx->bufcnt,
>>> +		  "length", length, "remain", remain);
>>> +
>>> +	sg_len = dma_map_sg(hace_dev->dev, rctx->src_sg, rctx->src_nents,
>>> +			    DMA_TO_DEVICE);
>>> +	if (!sg_len) {
>>> +		dev_warn(hace_dev->dev, "dma_map_sg() src error\n");
>>> +		rc = -ENOMEM;
>>> +		goto end;
>>> +	}
>>> +
>>> +	src_list = (struct aspeed_sg_list *)hash_engine->ahash_src_addr;
>>> +	rctx->digest_dma_addr = dma_map_single(hace_dev->dev, rctx->digest,
>>> +					       SHA512_DIGEST_SIZE,
>>> +					       DMA_BIDIRECTIONAL);
>>> +	if (dma_mapping_error(hace_dev->dev, rctx->digest_dma_addr)) {
>>> +		dev_warn(hace_dev->dev, "dma_map() rctx digest error\n");
>>> +		rc = -ENOMEM;
>>> +		goto free_src_sg;
>>> +	}
>>> +
>>> +	if (rctx->bufcnt != 0) {
>>> +		rctx->buffer_dma_addr = dma_map_single(hace_dev->dev,
>>> +						       rctx->buffer,
>>> +						       rctx->block_size * 2,
>>> +						       DMA_TO_DEVICE);
>>> +		if (dma_mapping_error(hace_dev->dev, rctx->buffer_dma_addr)) {
>>> +			dev_warn(hace_dev->dev, "dma_map() rctx buffer error\n");
>>> +			rc = -ENOMEM;
>>> +			goto free_rctx_digest;
>>> +		}
>>> +
>>> +		src_list[0].phy_addr = rctx->buffer_dma_addr;
>>> +		src_list[0].len = rctx->bufcnt;
>>> +		length -= src_list[0].len;
>>> +
>>> +		/* Last sg list */
>>> +		if (length == 0)
>>> +			src_list[0].len |= HASH_SG_LAST_LIST;
>>> +
>>> +		src_list[0].phy_addr = cpu_to_le32(src_list[0].phy_addr);
>>> +		src_list[0].len = cpu_to_le32(src_list[0].len);
>>> +		src_list++;
>>> +	}
>>> +
>>> +	if (length != 0) {
>>> +		for_each_sg(rctx->src_sg, s, sg_len, i) {
>>> +			src_list[i].phy_addr = sg_dma_address(s);
>>> +
>>> +			if (length > sg_dma_len(s)) {
>>> +				src_list[i].len = sg_dma_len(s);
>>> +				length -= sg_dma_len(s);
>>> +
>>> +			} else {
>>> +				/* Last sg list */
>>> +				src_list[i].len = length;
>>> +				src_list[i].len |= HASH_SG_LAST_LIST;
>>> +				length = 0;
>>> +			}
>>> +
>>> +			src_list[i].phy_addr = cpu_to_le32(src_list[i].phy_addr);
>>> +			src_list[i].len = cpu_to_le32(src_list[i].len);
>>> +		}
>>> +	}
>>> +
>>> +	if (length != 0) {
>>> +		rc = -EINVAL;
>>> +		goto free_rctx_buffer;
>>> +	}
>>> +
>>> +	rctx->offset = rctx->total - remain;
>>> +	hash_engine->src_length = rctx->total + rctx->bufcnt - remain;
>>> +	hash_engine->src_dma = hash_engine->ahash_src_dma_addr;
>>> +	hash_engine->digest_dma = rctx->digest_dma_addr;
>>> +
>>> +	goto end;
>> Exiting via "goto xx" is not recommended in normal code logic (this requires
>> two jumps),
>> exiting via "return 0" is more efficient.
>> This code method has many times in your entire driver, it is recommended to
>> modify it.
> 
> If not exiting via "goto xx", how to release related resources without any problem?
> Is there any proper way to do this?
maybe I didn't describe it clearly enough.
"in normal code logic"  means rc=0
In this scenario (rc=0), "goto xx" is no longer required,
it can be replaced with "return 0"
> 
>>> +
>>> +free_rctx_buffer:
>>> +	if (rctx->bufcnt != 0)
>>> +		dma_unmap_single(hace_dev->dev, rctx->buffer_dma_addr,
>>> +				 rctx->block_size * 2, DMA_TO_DEVICE);
>>> +free_rctx_digest:
>>> +	dma_unmap_single(hace_dev->dev, rctx->digest_dma_addr,
>>> +			 SHA512_DIGEST_SIZE, DMA_BIDIRECTIONAL);
>>> +free_src_sg:
>>> +	dma_unmap_sg(hace_dev->dev, rctx->src_sg, rctx->src_nents,
>>> +		     DMA_TO_DEVICE);
>>> +end:
>>> +	return rc;
>>> +}
>>> +
>>> +static int aspeed_ahash_complete(struct aspeed_hace_dev *hace_dev)
>>> +{
>>> +	struct aspeed_engine_hash *hash_engine = &hace_dev->hash_engine;
>>> +	struct ahash_request *req = hash_engine->req;
>>> +
>>> +	AHASH_DBG(hace_dev, "\n");
>>> +
>>> +	hash_engine->flags &= ~CRYPTO_FLAGS_BUSY;
>>> +
>>> +	crypto_finalize_hash_request(hace_dev->crypt_engine_hash, req, 0);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +/*
>>> + * Copy digest to the corresponding request result.
>>> + * This function will be called at final() stage.
>>> + */
>>> +static int aspeed_ahash_transfer(struct aspeed_hace_dev *hace_dev)
>>> +{
>>> +	struct aspeed_engine_hash *hash_engine = &hace_dev->hash_engine;
>>> +	struct ahash_request *req = hash_engine->req;
>>> +	struct aspeed_sham_reqctx *rctx = ahash_request_ctx(req);
>>> +
>>> +	AHASH_DBG(hace_dev, "\n");
>>> +
>>> +	dma_unmap_single(hace_dev->dev, rctx->digest_dma_addr,
>>> +			 SHA512_DIGEST_SIZE, DMA_BIDIRECTIONAL);
>>> +
>>> +	dma_unmap_single(hace_dev->dev, rctx->buffer_dma_addr,
>>> +			 rctx->block_size * 2, DMA_TO_DEVICE);
>>> +
>>> +	memcpy(req->result, rctx->digest, rctx->digsize);
>>> +
>>> +	return aspeed_ahash_complete(hace_dev);
>>> +}
>>> +
>>> +/*
>>> + * Trigger hardware engines to do the math.
>>> + */
>>> +static int aspeed_hace_ahash_trigger(struct aspeed_hace_dev *hace_dev,
>>> +				     aspeed_hace_fn_t resume)
>>> +{
>>> +	struct aspeed_engine_hash *hash_engine = &hace_dev->hash_engine;
>>> +	struct ahash_request *req = hash_engine->req;
>>> +	struct aspeed_sham_reqctx *rctx = ahash_request_ctx(req);
>>> +
>>> +	AHASH_DBG(hace_dev, "src_dma:0x%x, digest_dma:0x%x,
>> length:0x%x\n",
>>> +		  hash_engine->src_dma, hash_engine->digest_dma,
>>> +		  hash_engine->src_length);
>>> +
>>> +	rctx->cmd |= HASH_CMD_INT_ENABLE;
>>> +	hash_engine->resume = resume;
>>> +
>>> +	ast_hace_write(hace_dev, hash_engine->src_dma,
>> ASPEED_HACE_HASH_SRC);
>>> +	ast_hace_write(hace_dev, hash_engine->digest_dma,
>>> +		       ASPEED_HACE_HASH_DIGEST_BUFF);
>>> +	ast_hace_write(hace_dev, hash_engine->digest_dma,
>>> +		       ASPEED_HACE_HASH_KEY_BUFF);
>>> +	ast_hace_write(hace_dev, hash_engine->src_length,
>>> +		       ASPEED_HACE_HASH_DATA_LEN);
>>> +
>>> +	/* Memory barrier to ensure all data setup before engine starts */
>>> +	mb();
>>> +
>>> +	ast_hace_write(hace_dev, rctx->cmd, ASPEED_HACE_HASH_CMD);
>> A hardware service sending requires 5 hardware commands to complete.
>> In a multi-concurrency scenario, how to ensure the order of commands?
>> (If two processes send hardware task at the same time,
>> How to ensure that the hardware recognizes which task the current
>> command belongs to?)
> 
> Linux crypto engine would guarantee that only one request at each time to be dequeued from engine queue to process.
> And there has lock mechanism inside Linux crypto engine to prevent the scenario you mentioned.
> So only 1 aspeed_hace_ahash_trigger() hardware service would go through at a time.
> 
> [...]
> .
> 
You may not understand what I mean, the command flow in a normal scenario:
request_A: Acmd1-->Acmd2-->Acmd3-->Acmd4-->Acmd5
request_B: Bcmd1-->Bcmd2-->Bcmd3-->Bcmd4-->Bcmd5
In a multi-process concurrent scenario, multiple crypto engines can be enabled,
and each crypto engine sends a request. If multiple requests here enter
aspeed_hace_ahash_trigger() at the same time, the command flow will be
intertwined like this:
request_A, request_B: Acmd1-->Bcmd1-->Acmd2-->Acmd3-->Bcmd2-->Acmd4-->Bcmd3-->Bcmd4-->Acmd5-->Bcmd5

In this command flow, how does your hardware identify whether these commands
belong to request_A or request_B?
Thanks.
Longfang.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux