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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20161125124528.GJ14217@n2100.armlinux.org.uk>
Date:   Fri, 25 Nov 2016 12:45:29 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Vinod Koul <vinod.koul@...el.com>
Cc:     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>,
        Mans Rullgard <mans@...sr.com>,
        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

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...

(We also have more complex situations already supported, such as
PL08x with a FPGA routing on three of its request signals.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.