From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E184C3279B for ; Wed, 4 Jul 2018 17:01:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B9CA121564 for ; Wed, 4 Jul 2018 17:01:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9CA121564 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deltatee.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753326AbeGDRBj (ORCPT ); Wed, 4 Jul 2018 13:01:39 -0400 Received: from ale.deltatee.com ([207.54.116.67]:42694 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752634AbeGDRBg (ORCPT ); Wed, 4 Jul 2018 13:01:36 -0400 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fal9j-0007el-Cm; Wed, 04 Jul 2018 11:01:29 -0600 To: Fabio Estevam , Horia Geanta Cc: Andy Shevchenko , Aymen Sghaier , Andrew Morton , linux-kernel , Linux-Arch , "linux-ntb@googlegroups.com" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Arnd Bergmann , Greg Kroah-Hartman , Dan Douglass , Herbert Xu , "David S. Miller" References: <20180622194752.11221-1-logang@deltatee.com> <20180622194752.11221-7-logang@deltatee.com> <13ea3f97-4a33-3a24-1b7e-b819be73d867@deltatee.com> <6e5224b9-343f-990c-19bd-fe37c6fbdc9b@deltatee.com> <7ddda181-6337-32cc-7a0d-43fc6a7ba78b@deltatee.com> <991b2298-bb3f-dad3-c93b-b43ee5f372de@deltatee.com> From: Logan Gunthorpe Message-ID: <55236e2b-a2a5-493a-5696-19c5926885b3@deltatee.com> Date: Wed, 4 Jul 2018 11:01:24 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: davem@davemloft.net, herbert@gondor.apana.org.au, dan.douglass@nxp.com, gregkh@linuxfoundation.org, arnd@arndb.de, linux-crypto@vger.kernel.org, linux-ntb@googlegroups.com, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, aymen.sghaier@nxp.com, andy.shevchenko@gmail.com, horia.geanta@nxp.com, festevam@gmail.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/4/2018 9:06 AM, Fabio Estevam wrote: >> Logan, you mentioned the following (which unfortunately I somehow missed): >> https://lore.kernel.org/lkml/c3f2e061-5ed1-5c74-b955-3d2bfb0da074@deltatee.com >> The lo_hi/hi_lo functions seem to always refer to the data being written >> or read not to the address operated on. Oy, yes that was more than a year ago. >> OTOH, initial commit that added asm-generic/io-64-nonatomic-lo-hi.h and >> asm-generic/io-64-nonatomic-hi-lo.h mentions: >> 797a796a13df6 ("asm-generic: architecture independent readq/writeq for 32bit >> environment") >> - provides non-atomic readq/ writeq with >> the order of lower address -> higher address >> - provides non-atomic readq/ writeq with >> reversed order Hmm, well in fairness that commit didn't add any BE operations so lower/higher address is the same as lower/higher data being written. hi-lo/lo-hi is a bit ambiguous in that sense and designing it to match the semantics of the only user seemed to make sense at the time. I didn't even check the rough comments in an old commit message which I wouldn't really take as canonical. Also, it seems to me, most hardware would expect you to write in order of the address (if it cares at all) not in the order of the higher/lower data word. Though, I have no explicit examples only a gut feeling. >> I think we should keep the initial semantics when adding support for >> io{read|write}64, i.e. "lo" and "hi" to refer to address and not to value. >> >> Actually this is the semantics intended for the CAAM patch, see the note at the >> end of the commit message that refers to addresses, not values: >> To be consistent with CAAM engine HW spec: in case of 64-bit registers, >> irrespective of device endianness, the lower address should be read from >> / written to first, followed by the upper address. >> >> >> 2. CAAM driver I/O accessors for i.MX case >> Since this quirk cannot be accommodated in generic fashion, code dealing with >> caam_imx has to stay. Yes, though IMO, I think the patch I sent earlier is clearer than the current code with the nested ifs in different static functions. In any case, I'll drop it and let you make any changes you see fit. Logan