linux-kernel - Re: Tearing down DMA transfer setup after DMA client has finished

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 08 Dec 2016 12:20:30 +0000
From:   Måns Rullgård <mans@...sr.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Vinod Koul <vinod.koul@...el.com>, Mason <slash.tmp@...e.fr>,
        Russell King <linux@....linux.org.uk>,
        dmaengine@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>,
        Dan Williams <dan.j.williams@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Jon Mason <jdmason@...zu.us>, Mark Brown <broonie@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Lee Jones <lee.jones@...aro.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Arnd Bergmann <arnd@...db.de>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Sebastian Frias <sf84@...oste.net>,
        Thibaud Cornic <thibaud_cornic@...madesigns.com>
Subject: Re: Tearing down DMA transfer setup after DMA client has finished

Geert Uytterhoeven <geert@...ux-m68k.org> writes:

> On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård <mans@...sr.com> wrote:
>> Vinod Koul <vinod.koul@...el.com> writes:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>>>> Vinod Koul <vinod.koul@...el.com> writes:
>>>> > On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote:
>>>> >> That's not going to work very well.  Device drivers typically request
>>>> >> dma channels in their probe functions or when the device is opened.
>>>> >> This means that reserving one of the few channels there will inevitably
>>>> >> make some other device fail to operate.
>>>> >
>>>> > No that doesnt make sense at all, you should get a channel only when you
>>>> > want to use it and not in probe!
>>>>
>>>> Tell that to just about every single driver ever written.
>>>
>>> Not really, few do yes which is wrong but not _all_ do that.
>>
>> Every driver I ever looked at does.  Name one you consider "correct."
>
> I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but
> it does request DMA channels at open time, not at probe time.

In the part quoted above, I said most drivers request dma channels in
their probe or open functions.  For the purposes of this discussion,
that distinction is irrelevant.  In either case, the channel is held
indefinitely.  If this wasn't the correct way to use the dmaengine,
there would be no need for the virt-dma helpers which are specifically
designed for cases the one currently at hand.

The only problem we have is that nobody envisioned hardware where the
dma engine indicates completion slightly too soon.  I suspect there's a
fifo or such somewhere, and the interrupt is triggered when the last
byte has been placed in the fifo rather than when it has been removed
which would have been more correct.

-- 
Måns Rullgård