From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752050AbdK1Jsv (ORCPT ); Tue, 28 Nov 2017 04:48:51 -0500 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:57797 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751377AbdK1Jsj (ORCPT ); Tue, 28 Nov 2017 04:48:39 -0500 From: Fabien DESSENNE To: Herbert Xu CC: Corentin Labbe , "David S . Miller" , Rob Herring , Mark Rutland , Maxime Coquelin , Alexandre TORGUE , "linux-crypto@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Lionel DEBIEVE , Benjamin GAIGNARD , Ludovic BARRE Subject: Re: [PATCH v5 2/2] crypto: stm32 - Support for STM32 CRYP crypto module Thread-Topic: [PATCH v5 2/2] crypto: stm32 - Support for STM32 CRYP crypto module Thread-Index: AQHTSwcl1K2W6s+Fk0aj0KDz6vayHqMJBfYAgAkoHoCAF4cFgA== Date: Tue, 28 Nov 2017 09:47:54 +0000 Message-ID: <63a930a0-e56b-9fd4-ad47-e8ebb494a77f@st.com> References: <1508425830-13565-1-git-send-email-fabien.dessenne@st.com> <1508425830-13565-3-git-send-email-fabien.dessenne@st.com> <20171022072659.GB8489@Red> <774a92f2-af70-0424-b066-0cc1db3f9ab0@st.com> In-Reply-To: <774a92f2-af70-0424-b066-0cc1db3f9ab0@st.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.44] Content-Type: text/plain; charset="utf-8" Content-ID: <16DC39CAF100614886DB8316D4C7E37B@st.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-28_06:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vAS9mv1Q013794 Just a gentle ping ... or have I missed out on a reply? On 13/11/17 11:30, Fabien DESSENNE wrote: > Hi Herbert, > > Can you check if this patchset (removed the AEAD part as you suggested + > libkcapi test OK as suggested by Corentin) can be applied now? > > BR > > Fabien > > > On 07/11/17 15:40, Fabien DESSENNE wrote: >> On 22/10/17 09:26, Corentin Labbe wrote: >>> On Thu, Oct 19, 2017 at 05:10:30PM +0200, Fabien Dessenne wrote: >>>> This module registers block cipher algorithms that make use of the >>>> STMicroelectronics STM32 crypto "CRYP1" hardware. >>>> The following algorithms are supported: >>>> - aes: ecb, cbc, ctr >>>> - des: ecb, cbc >>>> - tdes: ecb, cbc >>>> >>>> Signed-off-by: Fabien Dessenne >>>> --- >>>> drivers/crypto/stm32/Kconfig | 9 + >>>> drivers/crypto/stm32/Makefile | 3 +- >>>> drivers/crypto/stm32/stm32-cryp.c | 1172 +++++++++++++++++++++++++++++++++++++ >>>> 3 files changed, 1183 insertions(+), 1 deletion(-) >>>> create mode 100644 drivers/crypto/stm32/stm32-cryp.c >>>> >>>> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig >>>> +static void stm32_cryp_irq_write_block(struct stm32_cryp *cryp) >>>> +{ >>>> + unsigned int i, j; >>>> + u32 *src; >>>> + u8 d8[4]; >>>> + >>>> + src = sg_virt(cryp->in_sg) + _walked_in; >>>> + >>>> + for (i = 0; i < cryp->hw_blocksize / sizeof(u32); i++) { >>>> + if (likely(cryp->total_in >= sizeof(u32))) { >>>> + /* Write a full u32 */ >>>> + stm32_cryp_write(cryp, CRYP_DIN, *src); >>> Hello >>> >>> Try also to test your driver with userspace via AF_ALG (libkcapi is a good start). >>> It should probably crash here. >>> I have do the same on my first sunxi-ss driver and you should use kmap(). >>> >>> Regards >> Hi Corentin, >> >> Thank you for suggesting to test from userspace through the AF_ALG >> socket with libkcapi. >> This increases my test coverage. >> >> I ran the miscellaneous tests (kcapi-enc-test(large).sh + test.sh) and >> could not observe any crash. >> Note that I had already fixed some 'memory crashes' while testing with >> testmgr / tcrypt while testing from the kernel. >> >> So it looks like the proposed implementation is fine. >> >> BR >> >> Fabien