linux-kernel - Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

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: <CAPDyKFo=2+9cVN-9N1w8z_+dpopgccceA=x0cimxNG9w4xZX0g@mail.gmail.com>
Date:   Wed, 14 Sep 2016 13:54:50 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
Cc:     "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        iommu@...ts.linux-foundation.org,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        Joerg Roedel <joro@...tes.org>,
        Inki Dae <inki.dae@...sung.com>, Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <k.kozlowski@...sung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Mark Brown <broonie@...nel.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Lukas Wunner <lukas@...ner.de>,
        Kevin Hilman <khilman@...nel.org>
Subject: Re: [PATCH v3 2/2] iommu/exynos: Add proper runtime pm support

[...]

>>>
>>>> To solve this problem, I was thinking we could convert to use the
>>>> asynchronous pm_runtime_get() API, when trying to runtime resume the
>>>> device from atomic contexts.
>>>
>>> I'm not sure if this will work for DMA engine devices. If I understand
>>> correctly some client's of DMA engine device might rely on the DMA
>>> engine being configured and operational after queuing a request and
>>> they might lock up if the DMA engine device activation if postponed
>>> because of async runtime pm activation.
>>
>> I didn't know about this. If you have an example from the top of your
>> head, could you perhaps point me to it?
>
>
> No, I don't have any example. This is just my fear that there might be some
> hardware which works this way. I can imagine a driver, which queue dma
> engine
> request and then triggers 'start' command to its hw block. HW blocks usually
> uses some additional signal lines for DMA, so the HW block might check if
> all
> needed signals from DMA engine HW are ready. If not it will fail to start
> avoid lockup of starting without DMA engine HW being ready.

Well, I think this reasoning makes lots of sense! Clearly we wouldn't
be able to guarantee that there's isn't a glitch in an undefined HW
behaviour.

I will drop my suggested approach and try out another one.

>
> However I don't have much experience with DMA engine and drivers. I only
> helped in adding DMA engine support to Samsung UART driver and in the
> hardware manual there is information about additional lines between DMA
> controller and UART module, which are used in the DMA mode.

Thanks for sharing your experience!

Now, I should allow you to get back to the original review! :-)

Kind regards
Uffe