linux-kernel - Re: [RFC PATCH 2/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]

Date:   Mon, 10 Apr 2017 20:48:38 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Rajendra Nayak <rnayak@...eaurora.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>, <geert@...ux-m68k.org>
CC:     <stanimir.varbanov@...aro.org>, <sboyd@...eaurora.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>
Subject: Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of
 PM domains


On 10/04/17 11:02, Rajendra Nayak wrote:
> 
> 
> On 04/10/2017 01:54 PM, Jon Hunter wrote:
>>
>> On 10/04/17 05:09, Rajendra Nayak wrote:
>>> Hey Jon,
>>>
>>> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>>>> The current generic PM domain framework (GenDP) only allows a single
>>>> PM domain to be associated with a given device. There are several
>>>> use-cases for various system-on-chip devices where it is necessary for
>>>> a PM domain consumer to control more than one PM domain where the PM
>>>> domains:
>>>> i).  Do not conform to a parent-child relationship so are not nested
>>>> ii). May not be powered on and off at the same time so need independent
>>>>      control.
>>>>
>>>> To support the above, add new APIs for GenPD to allow consumers to get,
>>>> power-on, power-off and put PM domains so that they can be explicitly
>>>> controlled by the consumer.
>>>
>>> thanks for working on this RFC.
>>>
>>> []..
>>>   
>>>> +/**
>>>> + * pm_genpd_get - Get a generic I/O PM domain by name
>>>> + * @name: Name of the PM domain.
>>>> + *
>>>> + * Look-ups a PM domain by name. If found, increment the device
>>>> + * count for PM domain to ensure that the PM domain cannot be
>>>> + * removed, increment the suspended count so that it can still
>>>> + * be turned off (when not in-use) and return a pointer to its
>>>> + * generic_pm_domain structure. If not found return ERR_PTR().
>>>> + */
>>>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>>>> +{
>>>> +	struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>>>> +
>>>> +	if (!name)
>>>> +		return ERR_PTR(-EINVAL);
>>>> +
>>>> +	mutex_lock(&gpd_list_lock);
>>>> +	list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>>>> +		if (!strcmp(gpd->name, name)) {
> 
> Also looking up the powerdomain this way means the consumers need
> to know the _exact_ name with which the providers have registered
> the powerdomains?

Yes, this provides a means for someone not using DT to lookup a PM
domain. How else would you do it?

Patch 3/4 allows you to use DT instead, which I imagine anyone using DT
would use.

Jon

-- 
nvpublic