From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Estevam Subject: Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Date: Wed, 4 Jul 2018 12:06:14 -0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Horia Geanta Cc: Logan Gunthorpe , 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" List-Id: linux-arch.vger.kernel.org Hi Horia, On Wed, Jul 4, 2018 at 8:45 AM, Horia Geanta wrote: > I think there are two separate issues here: > > 1. Semantics of operations in io-64-nonatomic-lo-hi.h, io-64-nonatomic-hi-lo.h > > 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. > > 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 > > 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 > > CAAM block in some i.MX parts has broken endianness for 64b registers. > For e.g. for i.MX6S/SL/D/Q even though CAAM is little endian, BARs for I/O rings > have to be programmed as: > I/O Ring BAR+0: unused > I/O Ring BAR+4: IOVA (32-bit little endian) > when the proper layout (for a 64b register) would have been to program IOVA at > BAR+0. > > This explains why I/O accessors in CAAM driver handle things differently in case > caam_imx=true. > > Since this quirk cannot be accommodated in generic fashion, code dealing with > caam_imx has to stay. Should I sent a revert of patch 46e4bf08f6388 for the boot regression for now? Then the two issues you pointed out could be fixed later. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f67.google.com ([209.85.218.67]:38723 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752114AbeGDPGQ (ORCPT ); Wed, 4 Jul 2018 11:06:16 -0400 MIME-Version: 1.0 In-Reply-To: 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: Fabio Estevam Date: Wed, 4 Jul 2018 12:06:14 -0300 Message-ID: Subject: Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Horia Geanta Cc: Logan Gunthorpe , 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" Message-ID: <20180704150614.Rg7R0Sic6kVjB0fDgUjb9uaXu9M3R28Z8soi7J3VfRU@z> Hi Horia, On Wed, Jul 4, 2018 at 8:45 AM, Horia Geanta wrote: > I think there are two separate issues here: > > 1. Semantics of operations in io-64-nonatomic-lo-hi.h, io-64-nonatomic-hi-lo.h > > 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. > > 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 > > 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 > > CAAM block in some i.MX parts has broken endianness for 64b registers. > For e.g. for i.MX6S/SL/D/Q even though CAAM is little endian, BARs for I/O rings > have to be programmed as: > I/O Ring BAR+0: unused > I/O Ring BAR+4: IOVA (32-bit little endian) > when the proper layout (for a 64b register) would have been to program IOVA at > BAR+0. > > This explains why I/O accessors in CAAM driver handle things differently in case > caam_imx=true. > > Since this quirk cannot be accommodated in generic fashion, code dealing with > caam_imx has to stay. Should I sent a revert of patch 46e4bf08f6388 for the boot regression for now? Then the two issues you pointed out could be fixed later.