linux-kernel - Re: [PATCH v6 16/36] nds32: DMA mapping API

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: <CAK8P3a0YrwAXH8n83wf=34zmN44KgJu-JVXfQWhuquNxVmZ8Sw@mail.gmail.com>
Date:   Thu, 25 Jan 2018 11:42:38 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Greentime Hu <green.hu@...il.com>
Cc:     Greentime <greentime@...estech.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Networking <netdev@...r.kernel.org>,
        Vincent Chen <deanbo422@...il.com>,
        DTML <devicetree@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-serial@...r.kernel.org,
        Geert Uytterhoeven <geert.uytterhoeven@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>, Greg KH <greg@...ah.com>,
        Guo Ren <ren_guo@...ky.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        David Miller <davem@...emloft.net>,
        Jonas Bonn <jonas@...thpole.se>,
        Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
        Stafford Horne <shorne@...il.com>,
        Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API

On Thu, Jan 25, 2018 at 4:45 AM, Greentime Hu <green.hu@...il.com> wrote:
> 2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
>> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@...il.com> wrote:
>>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@...il.com>:
>>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
>>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@...il.com> wrote:
>>
>> That looks reasonable enough, but it does depend on a number of factors,
>> and the dma-mapping.h implementation is not just about cache flushes.
>>
>> As I don't know the microarchitecture, can you answer these questions:
>>
>> - are caches always write-back, or could they be write-through?
> Yes, we can config it to write-back or write-through.

Ok. If a WT-cache is common enough, you could optimize for that
case by skipping the explicit writeback here and just doing a synchronizing
instruction. Usually if the cache is configurable, one would pick the
writeback option though, so it's probably not important.

>> - is the CPU physical address always the same as the address visible to the
>>   device?
> Yes, it is always the same unless the CPU uses local memory. The
> physical address of local memory will overlap the original bus
> address.
> I think the local memory case can be ignored because we don't use it for now.

Ok, makes sense.

>> - are there devices that can only see a subset of the physical memory?
> All devices are able to see the whole physical memory in our current
> SoC, but I think other SoC may support such kind of HW behavior.

This is one area that might need a more complex implementation then,
depending on what devices are used in other SoCs. For network or
storage devices, it's usually sufficient to configure a DMA mask
from the "dma-ranges" property of the parent bus in the device tree,
the kernel code will then use bounce buffers.

For other types of drivers, using the streaming DMA interfaces
can require using the swiotlb helper that performs the bounce
buffering at in place of the cache operations. With a bit of luck,
you won't ever need to worry about it, just mentioning it here in
case you run into that problem later.

The consistent_sync() implementaiton you showed earlier should be
good enough then.  With that change,

Acked-by: Arnd Bergmann <arnd@...db.de>