[RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support

[RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support

[Kalyani Akula]

This patch set adds support for
- dt-binding docs for Xilinx ZynqMP SHA3 driver
- Adds communication layer support for sha_hash in zynqmp.c
- Adds Xilinx ZynqMP driver for SHA3 Algorithm
- Adds device tree node for ZynqMP SHA3 driver

V3 Changes :
- Removed zynqmp_sha_import and export APIs.The reason as follows
The user space code does an accept on an already accepted FD
when we create AF_ALG socket and call accept on it,
it calls af_alg_accept and not hash_accept.
import and export APIs are called from hash_accept.
The flow is as below
accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
for hash salg_type.
- Resolved comments from 
        https://patchwork.kernel.org/patch/10753719/

V2 Changes :
- Added new patch (2/4) for sha_hash zynqmp API support
- Incorporated code review comments from v1 patch series. Discussed below:
        https://lore.kernel.org/patchwork/patch/1029433/


Kalyani Akula (4):
  dt-bindings: crypto: Add bindings for ZynqMP SHA3 driver
  firmware: xilinx: Add ZynqMP sha_hash API for SHA3 functionality
  crypto: Add Xilinx SHA3 driver
  ARM64: zynqmp: Add Xilinix SHA-384 node.

 .../devicetree/bindings/crypto/zynqmp-sha.txt      |  12 ++
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |   4 +
 drivers/crypto/Kconfig                             |  10 +
 drivers/crypto/Makefile                            |   1 +
 drivers/crypto/zynqmp-sha.c                        | 240 +++++++++++++++++++++
 drivers/firmware/xilinx/zynqmp.c                   |  27 +++
 include/linux/firmware/xlnx-zynqmp.h               |   2 +
 7 files changed, 296 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/zynqmp-sha.txt
 create mode 100644 drivers/crypto/zynqmp-sha.c

-- 
1.9.5

[RFC PATCH V3 1/4] dt-bindings: crypto: Add bindings for ZynqMP SHA3 driver

[Kalyani Akula]

Add documentation to describe Xilinx ZynqMP SHA3 driver
bindings.

Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com>
---
 Documentation/devicetree/bindings/crypto/zynqmp-sha.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/zynqmp-sha.txt

diff --git a/Documentation/devicetree/bindings/crypto/zynqmp-sha.txt b/Documentation/devicetree/bindings/crypto/zynqmp-sha.txt
new file mode 100644
index 0000000..8b3cc55
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/zynqmp-sha.txt
@@ -0,0 +1,12 @@
+Xilinx ZynqMP SHA3(keccak-384) hw acceleration support.
+
+The ZynqMp PS-SHA hw accelerator is used to calculate the
+SHA3(keccak-384) hash value on the given user data.
+
+Required properties:
+- compatible:	should contain "xlnx,zynqmp-sha3-384"
+
+Example:
+	xlnx_sha3_384: sha384 {
+		compatible = "xlnx,zynqmp-sha3-384";
+	};
-- 
1.9.5

[RFC PATCH V3 2/4] firmware: xilinx: Add ZynqMP sha_hash API for SHA3 functionality

[Kalyani Akula]

Add ZynqMP firmware SHA_HASH API to compute SHA3 hash of given data.

Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com>
---
 drivers/firmware/xilinx/zynqmp.c     | 27 +++++++++++++++++++++++++++
 include/linux/firmware/xlnx-zynqmp.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 98f9361..22a062a 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -619,9 +619,36 @@ static int zynqmp_pm_set_requirement(const u32 node, const u32 capabilities,
 				   qos, ack, NULL);
 }
 
+/**
+ * zynqmp_pm_sha_hash - Access the SHA engine to calculate the hash
+ * @address:	Address of the data/ Address of output buffer where
+ *		hash should be stored.
+ * @size:	Size of the data.
+ * @flags:
+ *	BIT(0) - for initializing csudma driver and SHA3(Here address
+ *		 and size inputs can be NULL).
+ *	BIT(1) - to call Sha3_Update API which can be called multiple
+ *		 times when data is not contiguous.
+ *	BIT(2) - to get final hash of the whole updated data.
+ *		 Hash will be overwritten at provided address with
+ *		 48 bytes.
+ *
+ * Return:	Returns status, either success or error code.
+ */
+static int zynqmp_pm_sha_hash(const u64 address, const u32 size,
+			      const u32 flags)
+{
+	u32 lower_32_bits = (u32)address;
+	u32 upper_32_bits = (u32)(address >> 32);
+
+	return zynqmp_pm_invoke_fn(PM_SECURE_SHA, upper_32_bits, lower_32_bits,
+				   size, flags, NULL);
+}
+
 static const struct zynqmp_eemi_ops eemi_ops = {
 	.get_api_version = zynqmp_pm_get_api_version,
 	.get_chipid = zynqmp_pm_get_chipid,
+	.sha_hash = zynqmp_pm_sha_hash,
 	.query_data = zynqmp_pm_query_data,
 	.clock_enable = zynqmp_pm_clock_enable,
 	.clock_disable = zynqmp_pm_clock_disable,
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 642dab1..124e5f0 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -57,6 +57,7 @@ enum pm_api_id {
 	PM_RESET_GET_STATUS,
 	PM_PM_INIT_FINALIZE = 21,
 	PM_GET_CHIPID = 24,
+	PM_SECURE_SHA = 26,
 	PM_IOCTL = 34,
 	PM_QUERY_DATA,
 	PM_CLOCK_ENABLE,
@@ -283,6 +284,7 @@ struct zynqmp_eemi_ops {
 			       const u32 capabilities,
 			       const u32 qos,
 			       const enum zynqmp_pm_request_ack ack);
+	int (*sha_hash)(const u64 address, const u32 size, const u32 flags);
 };
 
 int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
-- 
1.9.5

[RFC PATCH V3 3/4] crypto: Add Xilinx SHA3 driver

[Kalyani Akula]

This patch adds SHA3 driver support for the Xilinx
ZynqMP SoC.

Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com>
---
 drivers/crypto/Kconfig      |  10 ++
 drivers/crypto/Makefile     |   1 +
 drivers/crypto/zynqmp-sha.c | 240 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 251 insertions(+)
 create mode 100644 drivers/crypto/zynqmp-sha.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 0be55fc..d9647a0 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -667,6 +667,16 @@ config CRYPTO_DEV_ROCKCHIP
 	  This driver interfaces with the hardware crypto accelerator.
 	  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
 
+config CRYPTO_DEV_ZYNQMP_SHA3
+	tristate "Support for Xilinx ZynqMP SHA3 hw accelerator"
+	depends on ARCH_ZYNQMP || COMPILE_TEST
+	select CRYPTO_HASH
+	help
+	  Xilinx ZynqMP has SHA3 engine used for secure hash calculation.
+	  This driver interfaces with SHA3 hw engine.
+	  Select this if you want to use the ZynqMP module
+	  for SHA3 hash computation.
+
 config CRYPTO_DEV_MEDIATEK
 	tristate "MediaTek's EIP97 Cryptographic Engine driver"
 	depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 8e7e225..64c29fe 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -47,3 +47,4 @@ obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
 obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
 obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/
 obj-y += hisilicon/
+obj-$(CONFIG_CRYPTO_DEV_ZYNQMP_SHA3) += zynqmp-sha.o
diff --git a/drivers/crypto/zynqmp-sha.c b/drivers/crypto/zynqmp-sha.c
new file mode 100644
index 0000000..e8efe17
--- /dev/null
+++ b/drivers/crypto/zynqmp-sha.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cryptographic API.
+ *
+ * Support for Xilinx ZynqMP SHA3 HW Acceleration.
+ *
+ * Copyright (c) 2018 Xilinx Inc.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
+#include <linux/of_device.h>
+#include <linux/crypto.h>
+#include <linux/cryptohash.h>
+#include <crypto/scatterwalk.h>
+#include <crypto/algapi.h>
+#include <crypto/sha.h>
+#include <crypto/hash.h>
+#include <crypto/internal/hash.h>
+#include <linux/firmware/xlnx-zynqmp.h>
+
+#define ZYNQMP_SHA3_INIT	1
+#define ZYNQMP_SHA3_UPDATE	2
+#define ZYNQMP_SHA3_FINAL	4
+
+static const struct zynqmp_eemi_ops *eemi_ops;
+struct zynqmp_sha_dev *sha_dd;
+
+struct zynqmp_sha_reqctx {
+	struct zynqmp_sha_dev	*dd;
+	unsigned long		flags;
+};
+
+struct zynqmp_sha_ctx {
+	struct zynqmp_sha_dev	*dd;
+	unsigned long		flags;
+};
+
+struct zynqmp_sha_dev {
+	struct device		*dev;
+	int			err;
+
+	unsigned long		flags;
+	struct ahash_request	*req;
+};
+
+static int zynqmp_sha_init(struct ahash_request *req)
+{
+	struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+	struct zynqmp_sha_ctx *tctx = crypto_ahash_ctx(tfm);
+	struct zynqmp_sha_reqctx *ctx = ahash_request_ctx(req);
+	struct zynqmp_sha_dev *dd = sha_dd;
+	int ret;
+
+	if (!eemi_ops->sha_hash)
+		return -ENOTSUPP;
+
+	if (!tctx->dd)
+		tctx->dd = dd;
+	else
+		dd = tctx->dd;
+
+	ctx->dd = dd;
+	dev_dbg(dd->dev, "init: digest size: %d\n",
+		crypto_ahash_digestsize(tfm));
+
+	ret = eemi_ops->sha_hash(0, 0, ZYNQMP_SHA3_INIT);
+
+	return ret;
+}
+
+static int zynqmp_sha_update(struct ahash_request *req)
+{
+	struct zynqmp_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
+	struct zynqmp_sha_dev *dd = tctx->dd;
+	size_t dma_size = req->nbytes;
+	dma_addr_t dma_addr;
+	char *kbuf;
+	int ret;
+
+	if (!req->nbytes)
+		return 0;
+
+	if (!eemi_ops->sha_hash)
+		return -ENOTSUPP;
+
+	kbuf = dma_alloc_coherent(dd->dev, dma_size, &dma_addr, GFP_KERNEL);
+	if (!kbuf)
+		return -ENOMEM;
+
+	scatterwalk_map_and_copy(kbuf, req->src, 0, req->nbytes, 0);
+	ret = eemi_ops->sha_hash(dma_addr, req->nbytes, ZYNQMP_SHA3_UPDATE);
+	dma_free_coherent(dd->dev, dma_size, kbuf, dma_addr);
+
+	return ret;
+}
+
+static int zynqmp_sha_final(struct ahash_request *req)
+{
+	struct zynqmp_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
+	struct zynqmp_sha_dev *dd = tctx->dd;
+	size_t dma_size = SHA384_DIGEST_SIZE;
+	dma_addr_t dma_addr;
+	char *kbuf;
+	int ret;
+
+	if (!eemi_ops->sha_hash)
+		return -ENOTSUPP;
+
+	kbuf = dma_alloc_coherent(dd->dev, dma_size, &dma_addr, GFP_KERNEL);
+	if (!kbuf)
+		return -ENOMEM;
+
+	ret = eemi_ops->sha_hash(dma_addr, dma_size, ZYNQMP_SHA3_FINAL);
+	memcpy(req->result, kbuf, SHA384_DIGEST_SIZE);
+	dma_free_coherent(dd->dev, dma_size, kbuf, dma_addr);
+
+	return ret;
+}
+
+static int zynqmp_sha_finup(struct ahash_request *req)
+{
+	zynqmp_sha_update(req);
+	zynqmp_sha_final(req);
+
+	return 0;
+}
+
+static int zynqmp_sha_digest(struct ahash_request *req)
+{
+	zynqmp_sha_init(req);
+	zynqmp_sha_update(req);
+	zynqmp_sha_final(req);
+
+	return 0;
+}
+
+static int zynqmp_sha_cra_init(struct crypto_tfm *tfm)
+{
+	crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
+				 sizeof(struct zynqmp_sha_reqctx));
+
+	return 0;
+}
+
+static struct ahash_alg sha3_alg = {
+	.init		= zynqmp_sha_init,
+	.update		= zynqmp_sha_update,
+	.final		= zynqmp_sha_final,
+	.finup		= zynqmp_sha_finup,
+	.digest		= zynqmp_sha_digest,
+	.halg = {
+		.digestsize	= SHA384_DIGEST_SIZE,
+		.statesize	= sizeof(struct sha256_state),
+		.base	= {
+			.cra_name		= "xilinx-sha3-384",
+			.cra_driver_name	= "zynqmp-sha3-384",
+			.cra_priority		= 300,
+			.cra_flags		= CRYPTO_ALG_ASYNC,
+			.cra_blocksize		= SHA384_BLOCK_SIZE,
+			.cra_ctxsize		= sizeof(struct zynqmp_sha_ctx),
+			.cra_alignmask		= 0,
+			.cra_module		= THIS_MODULE,
+			.cra_init		= zynqmp_sha_cra_init,
+		}
+	}
+};
+
+static const struct of_device_id zynqmp_sha_dt_ids[] = {
+	{ .compatible = "xlnx,zynqmp-sha3-384" },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, zynqmp_sha_dt_ids);
+
+static int zynqmp_sha_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	int err;
+
+	eemi_ops = zynqmp_pm_get_eemi_ops();
+	if (IS_ERR(eemi_ops))
+		return PTR_ERR(eemi_ops);
+
+	sha_dd = devm_kzalloc(&pdev->dev, sizeof(*sha_dd), GFP_KERNEL);
+	if (!sha_dd)
+		return -ENOMEM;
+
+	sha_dd->dev = dev;
+	platform_set_drvdata(pdev, sha_dd);
+
+	err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(44));
+	if (err < 0) {
+		dev_err(dev, "no usable DMA configuration");
+		goto err_algs;
+	}
+
+	err = crypto_register_ahash(&sha3_alg);
+	if (err)
+		goto err_algs;
+
+	return 0;
+
+err_algs:
+	return err;
+}
+
+static int zynqmp_sha_remove(struct platform_device *pdev)
+{
+	sha_dd = platform_get_drvdata(pdev);
+
+	if (!sha_dd)
+		return -ENODEV;
+
+	crypto_unregister_ahash(&sha3_alg);
+
+	return 0;
+}
+
+static struct platform_driver zynqmp_sha_driver = {
+	.probe		= zynqmp_sha_probe,
+	.remove		= zynqmp_sha_remove,
+	.driver		= {
+		.name	= "zynqmp-keccak-384",
+		.of_match_table	= of_match_ptr(zynqmp_sha_dt_ids),
+	},
+};
+
+module_platform_driver(zynqmp_sha_driver);
+
+MODULE_DESCRIPTION("ZynqMP SHA3 hw acceleration support.");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Nava kishore Manne <navam@xilinx.com>");
-- 
1.9.5

[RFC PATCH V3 4/4] ARM64: zynqmp: Add Xilinix SHA-384 node.

[Kalyani Akula]

This patch adds a SHA3 DT node for Xilinx ZynqMP SoC.

Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com>
---
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 9aa6734..0532de7 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -124,6 +124,10 @@
 			     <1 10 0xf08>;
 	};
 
+	xlnx_sha3_384: sha384 {
+		compatible = "xlnx,zynqmp-sha3-384";
+	};
+
 	amba_apu: amba-apu@0 {
 		compatible = "simple-bus";
 		#address-cells = <2>;
-- 
1.9.5

Re: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support

[Corentin Labbe]

On Thu, May 02, 2019 at 04:04:38PM +0530, Kalyani Akula wrote:
> This patch set adds support for
> - dt-binding docs for Xilinx ZynqMP SHA3 driver
> - Adds communication layer support for sha_hash in zynqmp.c
> - Adds Xilinx ZynqMP driver for SHA3 Algorithm
> - Adds device tree node for ZynqMP SHA3 driver
> 
> V3 Changes :
> - Removed zynqmp_sha_import and export APIs.The reason as follows
> The user space code does an accept on an already accepted FD
> when we create AF_ALG socket and call accept on it,
> it calls af_alg_accept and not hash_accept.
> import and export APIs are called from hash_accept.
> The flow is as below
> accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
> for hash salg_type.
> - Resolved comments from 
>         https://patchwork.kernel.org/patch/10753719/
> 


Your driver still doesnt handle the case where two hash are done in parallel.

Furthermore, you miss the export/import functions.

Regards

RE: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support

[Kalyani Akula]

Hi Corentin,

Please find my response inline.

> -----Original Message-----
> From: Corentin Labbe <clabbe.montjoie@gmail.com>
> Sent: Thursday, May 2, 2019 5:30 PM
> To: Kalyani Akula <kalyania@xilinx.com>
> Cc: herbert@gondor.apana.org.au; kstewart@linuxfoundation.org;
> gregkh@linuxfoundation.org; tglx@linutronix.de; pombredanne@nexb.com;
> linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; Sarat Chand Savitala <saratcha@xilinx.com>; Kalyani
> Akula <kalyania@xilinx.com>
> Subject: Re: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support
> 
> On Thu, May 02, 2019 at 04:04:38PM +0530, Kalyani Akula wrote:
> > This patch set adds support for
> > - dt-binding docs for Xilinx ZynqMP SHA3 driver
> > - Adds communication layer support for sha_hash in zynqmp.c
> > - Adds Xilinx ZynqMP driver for SHA3 Algorithm
> > - Adds device tree node for ZynqMP SHA3 driver
> >
> > V3 Changes :
> > - Removed zynqmp_sha_import and export APIs.The reason as follows The
> > user space code does an accept on an already accepted FD when we
> > create AF_ALG socket and call accept on it, it calls af_alg_accept and
> > not hash_accept.
> > import and export APIs are called from hash_accept.
> > The flow is as below
> > accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_noke
> > accept--> y
> > for hash salg_type.
> > - Resolved comments from
> >         https://patchwork.kernel.org/patch/10753719/
> >
> 
> 
> Your driver still doesnt handle the case where two hash are done in parallel.
> 

Our Firmware uses IPI protocol to send this SHA3 requests to SHA3 HW engine, which doesn't support parallel processing of 2 hash requests.
The flow is 
SHA3 request from App -> SHA3 driver-> ZynqMp driver-> Firmware (which doesn't support parallel processing of 2 requests) -> SHA3 HW Engine


> Furthermore, you miss the export/import functions.
> 

When user space code does an accept on an already accepted FD as below
sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sockfd, (struct sockaddr *)&sa, sizeof(sa));
fd = accept(sockfd, NULL, 0);

where my sockaddr is 
struct sockaddr_alg sa = {
        .salg_family = AF_ALG,
        .salg_type = "hash",
        .salg_name = "xilinx-sha3-384"
 };

Upon calling accept the flow in the kernel is as mentioned
accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
for hash salg_type.

And where import and export functions are called from hash_accept. hence, these functions never be called from the application.
So, I removed those from the driver.

Regards
Kalyani.

> Regards

Re: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support

[Corentin Labbe]

On Thu, May 02, 2019 at 03:12:55PM +0000, Kalyani Akula wrote:
> Hi Corentin,
> 
> Please find my response inline.
> 
> > -----Original Message-----
> > From: Corentin Labbe <clabbe.montjoie@gmail.com>
> > Sent: Thursday, May 2, 2019 5:30 PM
> > To: Kalyani Akula <kalyania@xilinx.com>
> > Cc: herbert@gondor.apana.org.au; kstewart@linuxfoundation.org;
> > gregkh@linuxfoundation.org; tglx@linutronix.de; pombredanne@nexb.com;
> > linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org;
> > netdev@vger.kernel.org; Sarat Chand Savitala <saratcha@xilinx.com>; Kalyani
> > Akula <kalyania@xilinx.com>
> > Subject: Re: [RFC PATCH V3 0/4] Add Xilinx's ZynqMP SHA3 driver support
> > 
> > On Thu, May 02, 2019 at 04:04:38PM +0530, Kalyani Akula wrote:
> > > This patch set adds support for
> > > - dt-binding docs for Xilinx ZynqMP SHA3 driver
> > > - Adds communication layer support for sha_hash in zynqmp.c
> > > - Adds Xilinx ZynqMP driver for SHA3 Algorithm
> > > - Adds device tree node for ZynqMP SHA3 driver
> > >
> > > V3 Changes :
> > > - Removed zynqmp_sha_import and export APIs.The reason as follows The
> > > user space code does an accept on an already accepted FD when we
> > > create AF_ALG socket and call accept on it, it calls af_alg_accept and
> > > not hash_accept.
> > > import and export APIs are called from hash_accept.
> > > The flow is as below
> > > accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_noke
> > > accept--> y
> > > for hash salg_type.
> > > - Resolved comments from
> > >         https://patchwork.kernel.org/patch/10753719/
> > >
> > 
> > 
> > Your driver still doesnt handle the case where two hash are done in parallel.
> > 
> 
> Our Firmware uses IPI protocol to send this SHA3 requests to SHA3 HW engine, which doesn't support parallel processing of 2 hash requests.
> The flow is 
> SHA3 request from App -> SHA3 driver-> ZynqMp driver-> Firmware (which doesn't support parallel processing of 2 requests) -> SHA3 HW Engine
> 
> 

So your driver will just send bad result in that case.

You need to export and store the intermediate result in a request context.

> > Furthermore, you miss the export/import functions.
> > 
> 
> When user space code does an accept on an already accepted FD as below
> sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
> bind(sockfd, (struct sockaddr *)&sa, sizeof(sa));
> fd = accept(sockfd, NULL, 0);
> 
> where my sockaddr is 
> struct sockaddr_alg sa = {
>         .salg_family = AF_ALG,
>         .salg_type = "hash",
>         .salg_name = "xilinx-sha3-384"
>  };
> 
> Upon calling accept the flow in the kernel is as mentioned
> accept--> af_alg_accept-->hash_accept_parent-->hash_accept_parent_nokey
> for hash salg_type.
> 
> And where import and export functions are called from hash_accept. hence, these functions never be called from the application.
> So, I removed those from the driver.
> 
> Regards
> Kalyani.
> 

Handling your own worflow is not enough.

You need to support two client doing multiple update in parallel.
It seems that your driver is bugged in that case.

Furthermore, i am pretty sure that export and import are mandatory, and without them self-test should fail.
Do you have self test enabled and tryed to load the tcrypt module ?

Regards