linux-kernel - Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Oct 2016 12:24:15 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Kevin Hilman <khilman@...libre.com>
CC:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>
Subject: Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with
 multiple domains


On 07/10/16 10:14, Kevin Hilman wrote:
> Jon Hunter <jonathanh@...dia.com> writes:
> 
>> Some devices may require more than one PM domain to operate and this is
>> not currently by the PM domain framework. Furthermore, the current Linux
>> 'device' structure only allows devices to be associated with a single PM
>> domain and so cannot easily be associated with more than one. To allow
>> devices to be associated with more than one PM domain, if multiple
>> domains are defined for a given device (eg. via device-tree), then:
>> 1. Create a new PM domain for this device. The name of the new PM domain
>>    created matches the device name for which it was created for.
>> 2. Register the new PM domain as a sub-domain for all PM domains
>>    required by the device.
>> 3. Attach the device to the new PM domain.
> 
> Did you look at what might be involved to extend struct device to hace a
> list of pm_domains?  Like Ulf, I'm a bit unsettled by this
> implementation that has to work around the basic limitation in the
> driver model.

I had but it was going to be a much bigger and intrusive change. So I
went with this as a initial idea to see if others also had a need for
it. I am happy to start looking at extended the device struct if this is
the preferred path and I would agree that would make most sense.

> Having devices in multitple domains is needed for SoCs I'm familiar with
> also, so is a needed feature.

Ok great.

> I think removing the struct device limitation and corresponding
> assumptions in the driver and PM core is a prerequisite for this
> feature.
> 
> Doing that will lead to several questions about how to handle runtime PM
> operations (e.g. which of the multiple PM domains should the one to call
> the drivers runtime PM hooks when a device changes runtime PM state?)

Right. My initial thought would be that at least for device-tree based
configuration, that the order in which the pm-domains are defined in DT
would determine the order in which the pm-domains are power-on/off.

> Anyways, even with the potential complexities, I think attempting this
> is the right way forward.

Ok. I will start having a think about this but will probably not get
back to this for a few weeks.

Cheers
Jon

-- 
nvpublic