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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 16 Nov 2016 10:48:29 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Kevin Hilman <khilman@...nel.org>
CC:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "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

Hi Kevin, Ulf,

On 03/11/16 14:20, Jon Hunter wrote:
> 
> 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.

Any more thoughts on this? Seems that there are a few others that would
be interested in supporting multiple domains for a device.

Cheers
Jon

-- 
nvpublic