Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756859AbbFPQAR (ORCPT ); Tue, 16 Jun 2015 12:00:17 -0400 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:27408 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753596AbbFPQAJ (ORCPT ); Tue, 16 Jun 2015 12:00:09 -0400 From: Victoria Milhoan To: Jon Nettleton CC: Herbert Xu , Steffen Trumtrar , "linux-kernel@vger.kernel.org" , Ruchika Gupta , "linux-arm-kernel@lists.infradead.org" , "kernel@pengutronix.de" , Geanta Neag Horia , "linux-crypto@vger.kernel.org" Subject: RE: [BUG?] crypto: caam: little/big endianness on ARM vs PPC Thread-Topic: [BUG?] crypto: caam: little/big endianness on ARM vs PPC Thread-Index: AQHQp4Q+kwP2iYCsTUSf4YJ09wO/X52uH6MAgABZwVCAAE+TgIAAfWJQ Date: Tue, 16 Jun 2015 16:00:05 +0000 Message-ID: References: <20150615155907.GC7947@pengutronix.de> <20150615220506.GA15134@gondor.apana.org.au> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [192.88.158.1] x-microsoft-exchange-diagnostics: 1;BLUPR03MB390;5:HLpdAq6SEj+iQP/jdWZ7NER4RbvPTJ0YMzl46wzLbW0LgB/R9BYigYQtH3fpTuOyNSr631u1DA1oPKotADNruhebRqNf2rV7aGfY7NFYlBT6qkTtzfBcvG4NqgV9NNBn6delowLhS1VqL1WuCObaqQ==;24:p+ypbv+Nqy1kKD0mSS+JqsTFxE+TCT2ywLLP0+lgXuD3RCxbcWND0yxqcCSztFjvQ/qZ4xGWtsg/QmJWVtRkhPTrB3mP6IL+bKt7byXJFbM=;20:QO+Hqvnbot6azR4m5norU05y7CU+wR/7OMGhMZMTJQKBsecU+ZBuouHkGHg3/bJIqAVEP5GZNr/IOWy/vnZyjQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(42134001)(42139001);SRVR:BLUPR03MB390; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BLUPR03MB390;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB390; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(76104003)(13464003)(377454003)(51704005)(164054003)(189998001)(5002640100001)(5001960100002)(110136002)(46102003)(33656002)(76576001)(19580395003)(19580405001)(76176999)(86362001)(54356999)(2656002)(87936001)(66066001)(50986999)(77096005)(102836002)(15975445007)(106116001)(40100003)(77156002)(122556002)(2950100001)(2900100001)(1720100001)(93886004)(92566002)(74316001)(5003600100002)(62966003);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR03MB390;H:BLUPR03MB391.namprd03.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 16:00:05.7859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB390 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 t5GG0OQj004102 Content-Length: 4897 Lines: 106 Jon, The patches published to the mailing list yesterday for comment (titled crypto: caam - Add i.MX6 support to the Freescale CAAM driver) are based on the patches in the Freescale 3.14 git repository which enable i.MX6 support. The initial patch set is intended to provide a functional driver, based on the mainline kernel, which supports both QorIQ and i.MX6. Thanks, Victoria -----Original Message----- From: Jon Nettleton [mailto:jon.nettleton@gmail.com] Sent: Tuesday, June 16, 2015 1:11 AM To: Milhoan Victoria-B42089 Cc: Herbert Xu; Steffen Trumtrar; Kim Phillips; linux-kernel@vger.kernel.org; Gupta Ruchika-R66431; linux-arm-kernel@lists.infradead.org; kernel@pengutronix.de; Geanta Neag Horia Ioan-B05471; linux-crypto@vger.kernel.org Subject: Re: [BUG?] crypto: caam: little/big endianness on ARM vs PPC Victoria, I was hoping you would join the conversation. I know you have a series of patches in Freescale's 3.14 git repository. Have you updated those for mainline and published them for review and inclusion in the upstream kernel? If yes to any could you post a link? -Jon On Tue, Jun 16, 2015 at 5:27 AM, Victoria Milhoan wrote: > All, > > Freescale has been adding i.MX6 support to the CAAM driver and testing on both i.MX6 and QorIQ platforms. The patch series is now available for review. Your feedback for the provided patches is appreciated. > > Thanks, > Victoria > > -----Original Message----- > From: linux-crypto-owner@vger.kernel.org > [mailto:linux-crypto-owner@vger.kernel.org] On Behalf Of Herbert Xu > Sent: Monday, June 15, 2015 3:05 PM > To: Steffen Trumtrar > Cc: linux-kernel@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; linux-crypto@vger.kernel.org; > Gupta Ruchika-R66431; kernel@pengutronix.de; Geanta Neag Horia > Ioan-B05471; Kim Phillips > Subject: Re: [BUG?] crypto: caam: little/big endianness on ARM vs PPC > > On Mon, Jun 15, 2015 at 05:59:07PM +0200, Steffen Trumtrar wrote: >> Hi! >> >> I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current >> drivers/crypto/caam driver only works for PowerPC AFAIK. >> Actually, there isn't that much to do, to get support for the i.MX6 >> but one patch breaks the driver severely: >> >> commit ef94b1d834aace7101de77c3a7c2631b9ae9c5f6 >> crypto: caam - Add definition of rd/wr_reg64 for little endian >> platform >> >> This patch adds >> >> +#ifdef __LITTLE_ENDIAN >> +static inline void wr_reg64(u64 __iomem *reg, u64 data) { >> + wr_reg32((u32 __iomem *)reg + 1, (data & 0xffffffff00000000ull) >> 32); >> + wr_reg32((u32 __iomem *)reg, data & 0x00000000ffffffffull); } >> >> The wr_reg64 function is only used in one place in the >> drivers/crypto/caam/jr.c >> driver: to write the dma_addr_t to the register. Without that patch >> everything works fine on ARM (little endian, 32bit), with that patch >> the driver will write 0's into the register that holds the DMA address (the numerically-higher) -> kernel hangs. >> Also, from my understanding, the comment above the defines, stating >> that you have to first write the numerically-lower and then the >> numerically-higher address on 32bit systems doesn't match with the implementation. >> >> What I don't know/understand is if this makes any sense for any PowerPC implementation. >> >> So, the question is, how to fix this? I'd prefer to do it directly in >> the jr driver instead of the ifdef-ery. >> >> Something like >> if (sizeof(dma_addr_t) == sizeof(u32)) >> wr_reg32(&jrp->rregs->inpring_base + 1, inpbusaddr); >> else if (sizeof(dma_addr_t) == sizeof(u64)) >> wr_reg64(...) >> >> or just go by DT compatible and then remove the inline function definitions. >> >> As far as I can tell, the compatible wouldn't be needed for anything >> else in the jr driver, so maybe that is not optimal. On the other >> hand the sizeof(..) solution would only catch little endian on 32bit >> and not big endian (?!) I however don't know what combinations >> actually >> *have* to be caught, as I don't know, which exist. >> >> So, what do you think people? > > I'm adding a couple of CCs. > > Thanks, > -- > Email: Herbert Xu Home Page: > http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- > To unsubscribe from this list: send the line "unsubscribe > linux-crypto" in the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?