Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Kalyani Akula <kalyania@xilinx.com>
To:     Corentin Labbe <clabbe.montjoie@gmail.com>
CC:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Harsh Jain <harshj@xilinx.com>,
        Sarat Chand Savitala <saratcha@xilinx.com>,
        Mohan Marutirao Dhanawade <mohand@xilinx.com>
Subject: RE: [PATCH V3 4/4] crypto: Add Xilinx AES driver
Thread-Topic: [PATCH V3 4/4] crypto: Add Xilinx AES driver
Thread-Index: AQHVlJdPZqOBmIFx+0erb8mfNok4M6eMO+GAgAdzZcA=
Date:   Wed, 20 Nov 2019 06:41:58 +0000
Message-ID: <SN6PR02MB5135492A38B7B2302D6AC8BDAF4F0@SN6PR02MB5135.namprd02.prod.outlook.com>
References: <1573040435-6932-1-git-send-email-kalyani.akula@xilinx.com>
 <1573040435-6932-5-git-send-email-kalyani.akula@xilinx.com>
 <20191115124517.GA31038@Red>
In-Reply-To: <20191115124517.GA31038@Red>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: xilinx.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 45dba63f-92c9-40b4-77bf-08d76d84be52
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 06:41:58.9852
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5IaZofMVPqPMD87AhJX5onNaSFdD68jn6/eR8vbxQAgA9larXVFf23lvaF8JnTwDfD3t84QpEbbkQsHSl+O+wQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4223
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

Hi Corentin,

Thanks for the review. Please find my response inline.


> -----Original Message-----
> From: Corentin Labbe <clabbe.montjoie@gmail.com>
> Sent: Friday, November 15, 2019 6:15 PM
> To: Kalyani Akula <kalyania@xilinx.com>
> Cc: linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org; Kalyani
> Akula <kalyania@xilinx.com>; Harsh Jain <harshj@xilinx.com>; Sarat Chand
> Savitala <saratcha@xilinx.com>; Mohan Marutirao Dhanawade
> <mohand@xilinx.com>
> Subject: Re: [PATCH V3 4/4] crypto: Add Xilinx AES driver
>=20
> On Wed, Nov 06, 2019 at 05:10:35PM +0530, Kalyani Akula wrote:
> > This patch adds AES driver support for the Xilinx ZynqMP SoC.
> >
> > Signed-off-by: Kalyani Akula <kalyani.akula@xilinx.com>
> > ---
> >  drivers/crypto/Kconfig                 |  11 +
> >  drivers/crypto/Makefile                |   2 +
> >  drivers/crypto/xilinx/Makefile         |   3 +
> >  drivers/crypto/xilinx/zynqmp-aes-gcm.c | 457
> > +++++++++++++++++++++++++++++++++
> >  4 files changed, 473 insertions(+)
> >  create mode 100644 drivers/crypto/xilinx/Makefile  create mode 100644
> > drivers/crypto/xilinx/zynqmp-aes-gcm.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index
> > 1fb622f..8e7d3a9 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -696,6 +696,17 @@ config CRYPTO_DEV_ROCKCHIP
> >  	help
> >  	  This driver interfaces with the hardware crypto accelerator.
> >  	  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher
> mode.
> > +config CRYPTO_DEV_ZYNQMP_AES
> > +	tristate "Support for Xilinx ZynqMP AES hw accelerator"
> > +	depends on ARCH_ZYNQMP || COMPILE_TEST
> > +	select CRYPTO_AES
> > +	select CRYPTO_ENGINE
> > +	select CRYPTO_AEAD
> > +	help
> > +	  Xilinx ZynqMP has AES-GCM engine used for symmetric key
> > +	  encryption and decryption. This driver interfaces with AES hw
> > +	  accelerator. Select this if you want to use the ZynqMP module
> > +	  for AES algorithms.
> >
> >  config CRYPTO_DEV_MEDIATEK
> >  	tristate "MediaTek's EIP97 Cryptographic Engine driver"
> > diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index
> > afc4753..b6124b8 100644
> > --- a/drivers/crypto/Makefile
> > +++ b/drivers/crypto/Makefile
> > @@ -47,4 +47,6 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) +=3D vmx/
> >  obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) +=3D bcm/
> >  obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) +=3D inside-secure/
> >  obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) +=3D axis/
> > +obj-$(CONFIG_CRYPTO_DEV_ZYNQMP_AES) +=3D xilinx/
> > +
>=20
> Hello
>=20
> you insert a useless newline

Will fix it.

>=20
> [...]
> > +static int zynqmp_handle_aes_req(struct crypto_engine *engine,
> > +				 void *req)
> > +{
> > +	struct aead_request *areq =3D
> > +				container_of(req, struct aead_request,
> base);
> > +	struct crypto_aead *aead =3D crypto_aead_reqtfm(req);
> > +	struct zynqmp_aead_tfm_ctx *tfm_ctx =3D crypto_aead_ctx(aead);
> > +	struct zynqmp_aead_req_ctx *rq_ctx =3D aead_request_ctx(areq);
> > +	struct aead_request *subreq;
> > +	int need_fallback;
> > +	int err;
> > +
> > +	need_fallback =3D zynqmp_fallback_check(tfm_ctx, areq);
> > +
> > +	if (need_fallback) {
> > +		subreq =3D aead_request_alloc(tfm_ctx->fbk_cipher,
> GFP_KERNEL);
> > +		if (!subreq)
> > +			return -ENOMEM;
> > +
> > +		aead_request_set_callback(subreq, areq->base.flags,
> > +					  NULL, NULL);
> > +		aead_request_set_crypt(subreq, areq->src, areq->dst,
> > +				       areq->cryptlen, areq->iv);
> > +		aead_request_set_ad(subreq, areq->assoclen);
> > +		if (rq_ctx->op =3D=3D ZYNQMP_AES_ENCRYPT)
> > +			err =3D crypto_aead_encrypt(subreq);
> > +		else
> > +			err =3D crypto_aead_decrypt(subreq);
> > +		aead_request_free(subreq);
>=20
> Every other crypto driver which use async fallback does not use
> aead_request_free() (and do not allocate a new request).
> I am puzzled that you can free an async request without waiting for its
> completion.
> Perhaps I am wrong, but since no other driver do like that...

Thanks for pointing out. I will make sure I don't allocate the new request =
by adjusting the aead_req_size in init API.

>=20
> [...]
> > +static int zynqmp_aes_aead_probe(struct platform_device *pdev) {
> > +	struct device *dev =3D &pdev->dev;
> > +	int err =3D -1;
> > +
> > +	if (!pdev->dev.of_node)
> > +		return -ENODEV;
> > +
> > +	aes_drv_ctx.dev =3D dev;
>=20
> You should test if dev is not already set.
> And add a comment like "this driver support only one instance".

Will fix it

>=20
> > +	aes_drv_ctx.eemi_ops =3D zynqmp_pm_get_eemi_ops();
> > +	if (IS_ERR(aes_drv_ctx.eemi_ops)) {
> > +		dev_err(dev, "Failed to get ZynqMP EEMI interface\n");
> > +		return PTR_ERR(aes_drv_ctx.eemi_ops);
> > +	}
> > +
> > +	err =3D dma_set_mask_and_coherent(dev,
> DMA_BIT_MASK(ZYNQMP_DMA_BIT_MASK));
> > +	if (err < 0) {
> > +		dev_err(dev, "No usable DMA configuration\n");
> > +		return err;
> > +	}
> > +
> > +	aes_drv_ctx.engine =3D crypto_engine_alloc_init(dev, 1);
> > +	if (!aes_drv_ctx.engine) {
> > +		dev_err(dev, "Cannot alloc AES engine\n");
> > +		return err;
> > +	}
> > +
> > +	err =3D crypto_engine_start(aes_drv_ctx.engine);
> > +	if (err) {
> > +		dev_err(dev, "Cannot start AES engine\n");
> > +		return err;
> > +	}
> > +
> > +	err =3D crypto_register_aead(&aes_drv_ctx.alg.aead);
> > +	if (err < 0)
> > +		dev_err(dev, "Failed to register AEAD alg.\n");
>=20
> In case of error you didnt crypto_engine_exit()

I will fix it.

>=20
> Regards