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]

Message-ID: <yw1xtwav9092.fsf@unicorn.mansr.com>
Date:   Fri, 25 Nov 2016 13:07:05 +0000
From:   Måns Rullgård <mans@...sr.com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Vinod Koul <vinod.koul@...el.com>, Mason <slash.tmp@...e.fr>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Dave Jiang <dave.jiang@...el.com>,
        Arnd Bergmann <arnd@...db.de>, Mark Brown <broonie@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        dmaengine@...r.kernel.org, Dan Williams <dan.j.williams@...el.com>,
        Jon Mason <jon.mason@...el.com>,
        Lee Jones <lee.jones@...aro.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Tearing down DMA transfer setup after DMA client has finished

Russell King - ARM Linux <linux@...linux.org.uk> writes:

> On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>> Looking at thread and discussion now, first thinking would be to ensure
>> the transaction is completed properly and then isr fired. You may need
>> to talk to your HW designers to find a way for that. It is quite common
>> that DMA controllers will fire and complete whereas the transaction is
>> still in flight.
>> 
>> If that is not doable, then since you claim this is custom part which
>> other vendors wont use (hope we are wrong down the line), then we can
>> have a custom api,
>> 
>> foo_sbox_configure(bool enable, ...);
>> 
>> This can be invoked from NFC driver when required for configuration and
>> teardown. For very specific cases where people need some specific
>> configuration we do allow custom APIs.
>> 
>> Only problem with that would be it wont be a generic solution and you
>> seem to be fine with that.
>
> Isn't this just the same problem as PL08x or any other system which
> has multiple requests from devices, but only a limited number of
> hardware channels - so you have to route the request signals to the
> appropriate hardware channels according to the requests queued up?
>
> If so, no new "custom" APIs are required, it's already able to be
> solved within the DMA engine drivers...

That isn't the problem.  The multiplexing of many devices on a limited
number of hardware channels is working fine.  The problem is that (some)
client devices need the routing to remain for some time after the dma
interrupt signals completion.  I'd characterise this hardware as broken,
but there's nothing we can do about that.

The fix has to provide some way for the dma driver to delay reusing a
hardware channel until the client device indicates completion.  If only
a short delay (a few bus cycles) is needed, it is probably acceptable to
rework the driver such that the descriptor completion callback can do
the necessary waiting (e.g. by busy-polling a device status register).
If the delay can be longer, some other method needs to be devised.

-- 
Måns Rullgård