From: Horia Geanta <horia.geanta@nxp.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: Logan Gunthorpe <logang@deltatee.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Aymen Sghaier <aymen.sghaier@nxp.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
"linux-ntb@googlegroups.com" <linux-ntb@googlegroups.com>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dan Douglass <dan.douglass@nxp.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
Date: Wed, 4 Jul 2018 15:59:01 +0000 [thread overview]
Message-ID: <VI1PR0402MB3485AB652FBD61CE27965D3798410@VI1PR0402MB3485.eurprd04.prod.outlook.com> (raw)
In-Reply-To: CAOMZO5C7V4_SpXOcAz0KbGYScpos0HRD-aa-Zh_6M3p9EqLsLQ@mail.gmail.com
On 7/4/2018 6:06 PM, Fabio Estevam wrote:
> Hi Horia,
>
> On Wed, Jul 4, 2018 at 8:45 AM, Horia Geanta <horia.geanta@nxp.com> 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")
>> - <asm-generic/io-64-nonatomic-lo-hi.h> provides non-atomic readq/ writeq with
>> the order of lower address -> higher address
>> - <asm-generic/io-64-nonatomic-hi-lo.h> 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.
>
I guess it would be better this way.
Thanks,
Horia
next prev parent reply other threads:[~2018-07-04 15:59 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-22 19:47 [PATCH v18 0/7] Add io{read|write}64 to io-64-atomic headers Logan Gunthorpe
2018-06-22 19:47 ` [PATCH v18 1/7] iomap: Use non-raw io functions for io{read|write}XXbe Logan Gunthorpe
2018-06-22 19:47 ` [PATCH v18 2/7] parisc: iomap: introduce io{read|write}64 Logan Gunthorpe
2018-06-22 19:47 ` [PATCH v18 3/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo} Logan Gunthorpe
2018-07-13 23:38 ` [v18,3/7] " Guenter Roeck
2018-07-14 0:20 ` Logan Gunthorpe
2018-07-14 1:12 ` Guenter Roeck
2018-06-22 19:47 ` [PATCH v18 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros Logan Gunthorpe
2018-06-22 19:47 ` [PATCH v18 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks Logan Gunthorpe
2018-06-22 19:47 ` [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64 Logan Gunthorpe
2018-07-03 15:31 ` Fabio Estevam
2018-07-03 17:36 ` Andy Shevchenko
2018-07-03 17:44 ` Fabio Estevam
2018-07-03 18:01 ` Logan Gunthorpe
2018-07-03 18:06 ` Fabio Estevam
2018-07-03 18:09 ` Andy Shevchenko
2018-07-03 18:11 ` Fabio Estevam
2018-07-03 18:47 ` Logan Gunthorpe
2018-07-03 19:40 ` Fabio Estevam
2018-07-03 19:58 ` Andy Shevchenko
2018-07-03 20:10 ` Fabio Estevam
2018-07-03 20:40 ` Andy Shevchenko
2018-07-03 20:42 ` Andy Shevchenko
2018-07-03 23:55 ` Fabio Estevam
2018-07-03 21:16 ` Logan Gunthorpe
2018-07-03 23:56 ` Fabio Estevam
2018-07-03 21:20 ` Logan Gunthorpe
2018-07-03 22:21 ` Andy Shevchenko
2018-07-03 23:20 ` Logan Gunthorpe
2018-07-03 23:52 ` Fabio Estevam
2018-07-03 23:57 ` Logan Gunthorpe
2018-07-04 0:02 ` Logan Gunthorpe
2018-07-04 0:06 ` Fabio Estevam
2018-07-04 11:45 ` Horia Geanta
2018-07-04 15:06 ` Fabio Estevam
2018-07-04 15:59 ` Horia Geanta [this message]
2018-07-04 16:16 ` Fabio Estevam
2018-07-04 17:01 ` Logan Gunthorpe
2018-07-04 17:10 ` Andy Shevchenko
2018-07-04 17:13 ` Logan Gunthorpe
2018-07-04 17:16 ` Andy Shevchenko
2018-07-04 17:21 ` Logan Gunthorpe
2018-07-04 17:21 ` Andy Shevchenko
2018-07-04 17:23 ` Logan Gunthorpe
2018-07-04 17:25 ` Andy Shevchenko
2018-07-04 17:32 ` Andy Shevchenko
2018-07-04 17:36 ` Logan Gunthorpe
2018-07-03 18:06 ` Andy Shevchenko
2018-06-22 19:47 ` [PATCH v18 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header Logan Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR0402MB3485AB652FBD61CE27965D3798410@VI1PR0402MB3485.eurprd04.prod.outlook.com \
--to=horia.geanta@nxp.com \
--cc=akpm@linux-foundation.org \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=aymen.sghaier@nxp.com \
--cc=dan.douglass@nxp.com \
--cc=davem@davemloft.net \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arch@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntb@googlegroups.com \
--cc=logang@deltatee.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).