linux-kernel - Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

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: <CAPDyKFr6qB7j23E2pVqkBn8OWRZkwE_Diex8ttPiyPWZrruFYw@mail.gmail.com>
Date:   Mon, 13 Feb 2017 16:09:56 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
Cc:     Vinod Koul <vinod.koul@...el.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        dmaengine@...r.kernel.org,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Arnd Bergmann <arnd@...db.de>, Inki Dae <inki.dae@...sung.com>
Subject: Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

[...]

>> The only related PM thing, that shall be the decision of the driver,
>> is whether it wants to enable runtime PM or not, during ->probe().
>
>
> So do you want to create the links during the DMAengine driver probe? How do
> you
> plan to find all the client devices? Please note that you really want to
> create
> links to devices which will really use the DMA engine calls. Some client
> drivers might decide in runtime weather to use DMA engine or not, depending
> on
> other data.

I don't have great plan, just wanted to share my thoughts around the
problems we want to solve.

[...]

>>
>> If we could set up the device link already at device initialization,
>> it should also be possible to avoid getting -EPROBE_DEFER for dma
>> client drivers when requesting their dma channels.
>
>
> At the first glance this sounds like an ultimate solution for all problems,
> but I don't think that device links can be used this way. If I get it right,
> you would like to create links on client device initialization, preferably
> somewhere in the kernel driver core. This will be handled somehow by a
> completely generic code, which will create a link each pair of devices,
> which are connected by a phandle. Is this what you meant? Please note that
> that time no driver for both client and provider are probed. IMHO that
> doesn't look like a right generic approach
>
> How that code will know get following information:
> 1. is it really needed to create a link for given device pair?
> 2. what link flags should it use?
> 3. what about circular dependencies?
> 4. what about runtime optional dependencies?
> 5. what about non-dt platforms? acpi?
>

To give a good answer of these questions, I need to spend more time
investigating.

However, from a top-level point of view, I think the device links
seems like the perfect match for solving the runtime/system PM
problems.

No matter whether we can set up the links at device initialization
time, driver probe or whatever time.

> This looks like another newer ending story of "how can we avoid deferred
> probe
> in a generic way". IMHO we should first solve the problem of irq-safe
> runtime
> PM in DMA engine drivers first. I proposed how it can be done with device
> links.
> With no changes in the client API. Later if one decide to extend the client
> API
> in a way it will allow other runtime PM implementation - I see no problem to
> convert pl330 driver to the new approach, but for the time being - this
> would
> be the easiest way to get it really functional.

Agree, let's drop the deferred probe topic from the discussions - it's
just going to be overwhelming. :-)

[...]

>> So besides solving the irq-safe issue for dma driver, using the
>> device-links has additionally two advantages. I already mentioned the
>> -EPROBE_DEFER issue above.
>
>
> Not really. IMHO device links can be properly established once both drivers
> are probed...

Okay.

>
>>
>> The second thing, is the runtime/system PM relations we get for free
>> by using the links. In other words, the dma driver/core don't need to
>> care about dealing with pm_runtime_get|put() as that would be managed
>> by the dma client driver.
>
>
> IMHO there might be drivers which don't want to use device links based
> runtime
> PM in favor of irq-safe PM or something else. This should be really left to
> drivers.

Okay.

Kind regards
Uffe