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  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, 29 Nov 2017 10:46:09 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Kevin Hilman <khilman@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC V7 1/2] OPP: Allow OPP table to be used for power-domains

On Tue, Oct 31, 2017 at 7:47 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> Power-domains can also have their active states and this patch enhances
> the OPP binding to define those.
>
> The power domains can use the OPP bindings mostly as is. Though there
> are some changes required to support special cases:
>
> - Allow "operating-points-v2" to contain multiple phandles for power
>   domain providers providing multiple domains.
>
> - A new property "power-domain-opp" is added for devices to specify the
>   minimum required OPP of the master domain for the functioning of the
>   device. We can add this property directly to device's node if the
>   device has a fixed minimum OPP requirement from the master power
>   domain. Or we can add this property to each OPP node of the device, if
>   different OPP nodes have different minimum OPP requirement from the
>   master power domain.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
>  Documentation/devicetree/bindings/opp/opp.txt      | 12 +++++
>  .../devicetree/bindings/power/power_domain.txt     | 62 ++++++++++++++++++++++
>  2 files changed, 74 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 9d733af26be7..203e09fe7698 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -45,6 +45,11 @@ Devices supporting OPPs must set their "operating-points-v2" property with
>  phandle to a OPP table in their DT node. The OPP core will use this phandle to
>  find the operating points for the device.
>
> +This can contain more than one phandle for power domain providers that provide
> +multiple power domains. That is, one phandle for each power domain. If only one
> +phandle is available, then the same OPP table will be used for all power domains
> +provided by the power domain provider.
> +
>  If required, this can be extended for SoC vendor specific bindings. Such bindings
>  should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
>  and should have a compatible description like: "operating-points-v2-<vendor>".
> @@ -154,6 +159,13 @@ properties.
>
>  - status: Marks the node enabled/disabled.
>
> +- power-domain-opp: This contains phandle to one of the OPP nodes of the master
> +  power domain. This specifies the minimum required OPP of the master domain for
> +  the functioning of the device in this OPP (where this property is present).
> +  This property can only be set for a device if the device node contains the
> +  "power-domains" property. Also, either all or none of the OPP nodes in an OPP
> +  table should have it set.

This is a "this device requires OPP n" property. Couldn't we want this
for cases other than a powerdomain OPP? What if a device has
requirements 2 different OPPs?

On the flipside, I don't think we want devices picking things like CPU
OPPs and putting policy here. But I'd rather things be extendable than
reviewing yet another OPP property next month.

Rob

Powered by blists - more mailing lists