linux-kernel - Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains

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: <CAPDyKFqeAWoy-vfN89j8Yv1HTMpNqwcVk3XrTQoXH5JNrQ9Maw@mail.gmail.com>
Date:   Wed, 3 May 2017 19:12:05 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Jon Hunter <jonathanh@...dia.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of
 PM domains

[...]

>>>
>>>> What is missing, is how a call to pm_runtime_get_sync() by a driver,
>>>> can inform the ->start() callback about what exact power resource(s)
>>>> it shall turn on, because it may not always be all of them. Similar
>>>> problem exists for pm_runtime_put().
>>>
>>> Yes that is missing too, but I still don't see how you bind a device to
>>> more than one power-domain :-(
>>
>> I think this is what Rafael wanted us avoid (because of the complexity
>> involved). Instead the suggestion is to deal with this on top of the
>> existing PM domain structure, as "power resources" instead. Unless I
>> missed his point. :-)
>>
>> Then *my* point is: To be able to implement that, still only allowing
>> one PM domain per device, we would anyway need a new layer in-between
>> the PM domain (genpd) and the driver controlling the device. Simply
>> because these two entities, needs to be able to exchange information
>> about which "power resources" that shall be turned off/on, when the
>> driver do pm_runtime_get|put().
>
> Right, but isn't this similar to what I was suggesting above in my
> previous email?

Perhaps it was, apologize for my ignorance in that case.

Then, isn't that quite what you already started hacking on in $subject
series? What's the new thing in your previous reply?

However, I was under the impression that Rafael preferred another way
- but again I might have missed his point.

>
> I was proposing to have such a lower-layer by splitting the existing
> genpd framework so the drivers would have the option of calling the
> lower-level power control functions to look-up pm-domains and control
> them directly from their rpm callbacks (if they need to). Same as we do
> for clocks. This way you would not need to mess with the genpd ->start()
> callback and leave it to the driver to handle itself as it knows what
> needs to be done. This assumes that the device is never bound to the
> pm-domain by the genpd core.

Yes, agree! To me this is the only solution what would really work.

Perhaps Rafael can confirm that he is fine with a solution like this?

Kind regards
Uffe