[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdtkYRWyKnD+wXo_Z_t=EK9dAOTFzbnHmraSt80sAmyHA@mail.gmail.com>
Date: Wed, 4 Jul 2018 20:16:01 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Logan Gunthorpe <logang@...tatee.com>
Cc: Fabio Estevam <festevam@...il.com>,
Horia Geanta <horia.geanta@....com>,
Aymen Sghaier <aymen.sghaier@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Linux-Arch <linux-arch@...r.kernel.org>,
"linux-ntb@...glegroups.com" <linux-ntb@...glegroups.com>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dan Douglass <dan.douglass@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v18 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when
using io{read|write}64
On Wed, Jul 4, 2018 at 8:13 PM, Logan Gunthorpe <logang@...tatee.com> wrote:
> On 7/4/2018 11:10 AM, Andy Shevchenko wrote:
>> We have an iDMA 32-bit hardware (see drivers/dma/dw/) which has an
>> extension 64-bit registers where only one of them has a specific bit
>> to "commit" the changes written to all of them. And by some very
>> unknown reason that bit is in lo part which automatically means we
>> must to write it last.
>
> And it supports both BE and LE? And in both cases it's the lo part?
It's only LE for now.
P.S. If you more interested in code in kernel look for idma32_fifo_partition()
(While the bit is set in each of 32-bit part, it's actually present in
only one place)
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists