linux-kernel - Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to of

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: <26397455-1237-2a66-acf8-215aacc7c9ce@metafoo.de>
Date:   Wed, 25 Jan 2017 14:12:38 +0100
From:   Lars-Peter Clausen <lars@...afoo.de>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        linux-samsung-soc@...r.kernel.org, dmaengine@...r.kernel.org,
        alsa-devel@...a-project.org, linux-arm-kernel@...ts.infradead.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Vinod Koul <vinod.koul@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Mark Brown <broonie@...nel.org>,
        Inki Dae <inki.dae@...sung.com>
Subject: Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to
 of_xlate callback

On 01/25/2017 11:28 AM, Marek Szyprowski wrote:
> Add pointer to slave device to of_dma_xlate to let DMA engine driver
> to know which slave device is using given DMA channel. This will be
> later used to implement non-irq-safe runtime PM for DMA engine driver.

of_dma_xlate() is used to translate from a OF phandle and a specifier to a
DMA channel. On one hand this does not necessarily mean that the channel is
actually going to be used by the slave that called the xlate function.
Modifying the driver state when a lookup of the channel is done is a
layering violation. And this approach is also missing a way to disassociate
a slave from a DMA channel, e.g. when it is no longer used.

On the other hand there are other mechanisms to translate between some kind
of firmware handle to a DMA channel which are completely ignored here.

So this approach does not work. This is something that needs to be done at
the dmaengine level, not a the firmware resource translation level. And it
needs a matching method that is called when the channel is disassociated
from a device, when the device no longer uses the DMA channel.