lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <851ae9b3-80c8-1089-060c-f4baa4e57489@deltatee.com>
Date:   Wed, 4 Jul 2018 11:21:47 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Andy Shevchenko <andy.shevchenko@...il.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 7/4/2018 11:16 AM, Andy Shevchenko wrote:
> 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.

So the main question is if they were to add BE support, would they leave
the trigger in the same address or swap it to the other address so that
it's always the LO part that triggers? Otherwise it's hard to say what
we really want for the BE variants of the non-atomic hi-lo operations.

In the end, the driver author is free to use specifically which ever
function is necessary in any given situation (lo-hi vs hi-lo) and they
can read the definitions and no one is using them yet. So either way is
probably just as valid and it's probably not really worth fussing too
much about.

Logan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ