linux-kernel - Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require 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:   Thu, 3 Nov 2016 14:20:27 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...nel.org>,
        "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>,
        Rajendra Nayak <rnayak@...eaurora.org>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that
 require multiple domains


On 11/10/16 10:15, Jon Hunter wrote:

...

>>>> Second, another way of seeing this is: Depending on the current
>>>> runtime selected configuration you need to re-configure the PM domain
>>>> topology - but the device would still remain in the same PM domain.
>>>>
>>>> In other words, you would need to remove/add subdomain(s) depending on
>>>> the selected configuration. Would that better reflect the HW?
>>>
>>> I am not 100% sure I follow what you are saying, but ultimately, I would
>>> like to get to ...
>>>
>>>         usb@...90000 {
>>>                 compatible = "nvidia,tegra210-xusb";
>>>                 ...
>>>                 power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>         };
>>
>> So, is this really is a proper description of the HW? Isn't it so,
>> that the usb device always resides in one and the same PM domain?
> 
> I guess technically, the usbhost controller resides in one partition and
> the super-speed logic in another. So could the usbhost domain be the
> primary? Possibly, but the device cannot be probed without both enabled.
> 
>> Now, depending on the selected speed mode (superspeed) additional
>> logic may needs to be powered on and configured for the usb device to
>> work?
>> Perhaps, one could consider those additional logics as a master/parent
>> PM domain for the usb device's PM domain?
>>
>> Or this is not how the HW works? :-)
> 
> It might be possible for this case, but to be honest, the more I think
> about this, I do wonder if we need to be able to make the framework a
> lot more flexible for devices that need multiple power-domains. In other
> words, for devices that use multiple domains allow them to control them
> similarly to what we do for regulators or clocks. So if there is more
> than one defined, then the genpd core will not bind the device to the
> pm-domain and let the driver handle it. This way if you do need more
> granular control of the pm-domains in the driver you can do whatever you
> need to.
> 
> I know that Rajendra (CC'ed) was looking into whether he had a need to
> control multiple power-domains individually from within the context of a
> single device driver.

So Rajendra commented to say that he does not see a need for individual
control of power-domains for now, but a need for specifying multiple.

One simple option would be to allow users to specify multiple and have
the genpd core effectively ignore such devices and leave it to the
driver to configure manually. I have been able to do this for XUSB by
dynamically adding power-domains to the device.

Let me know if you have any more thoughts on how we can do this.

Cheers
Jon

-- 
nvpublic