From: Rob Herring <robh@kernel.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Hector Yuan <hector.yuan@mediatek.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH v3] dt-bindings: dvfs: Add support for generic performance domains
Date: Wed, 7 Apr 2021 14:08:08 -0500 [thread overview]
Message-ID: <20210407190808.GA4053148@robh.at.kernel.org> (raw)
In-Reply-To: <20210407135913.2067694-1-sudeep.holla@arm.com>
On Wed, Apr 07, 2021 at 02:59:13PM +0100, Sudeep Holla wrote:
> The CLKSCREW attack [0] exposed security vulnerabilities in energy management
> implementations where untrusted software had direct access to clock and
> voltage hardware controls. In this attack, the malicious software was able to
> place the platform into unsafe overclocked or undervolted configurations. Such
> configurations then enabled the injection of predictable faults to reveal
> secrets.
>
> Many Arm-based systems used to or still use voltage regulator and clock
> frameworks in the kernel. These frameworks allow callers to independently
> manipulate frequency and voltage settings. Such implementations can render
> systems susceptible to this form of attack.
>
> Attacks such as CLKSCREW are now being mitigated by not having direct and
> independent control of clock and voltage in the kernel and moving that
> control to a trusted entity, such as the SCP firmware or secure world
> firmware/software which are to perform sanity checking on the requested
> performance levels, thereby preventing any attempted malicious programming.
>
> With the advent of such an abstraction, there is a need to replace the
> generic clock and regulator bindings used by such devices with a generic
> performance domains bindings.
>
> [0] https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
>
> Link: https://lore.kernel.org/r/20201116181356.804590-1-sudeep.holla@arm.com
> Cc: Rob Herring <robh+dt@kernel.org>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>
> Hi All,
>
> Sorry for the delay, I thought I had sent this out last week and it turns
> out that I had dry-run in my git email command and never removed it. Just
> noticed now looking for response for this patch on the list to find out
> that I never sent it out :(.
>
> v2[2]->v3:
> - Dropped required properties
> - Added non cpu device example
> - Updated cpu bindings too
>
> v1[1]->v2[2]:
> - Changed to Dual License
> - Added select: true, enum for #performance-domain-cells and
> $ref for performance-domain
> - Changed the example to use real existing compatibles instead
> of made-up ones
>
> [1] https://lore.kernel.org/lkml/20201105173539.1426301-1-sudeep.holla@arm.com
> [2] https://lore.kernel.org/lkml/20201116181356.804590-1-sudeep.holla@arm.com
>
> .../devicetree/bindings/arm/cpus.yaml | 7 ++
> .../bindings/dvfs/performance-domain.yaml | 80 +++++++++++++++++++
> 2 files changed, 87 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dvfs/performance-domain.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> index 26b886b20b27..98590a2982d0 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> @@ -255,6 +255,13 @@ description: |+
>
> where voltage is in V, frequency is in MHz.
>
> + performance-domains:
> + $ref: '/schemas/types.yaml#/definitions/phandle-array'
Can drop as it already has a type def.
Does more than 1 entry make sense for a CPU? If not, 'maxItems: 1'. It
can always be extended later if the need arises.
> + description:
> + List of phandles and performance domain specifiers, as defined by
> + bindings of the performance domain provider. See also
> + dvfs/performance-domain.yaml.
> +
> power-domains:
> $ref: '/schemas/types.yaml#/definitions/phandle-array'
> description:
> diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
> new file mode 100644
> index 000000000000..640e676ed228
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dvfs/performance-domain.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic performance domains
> +
> +maintainers:
> + - Sudeep Holla <sudeep.holla@arm.com>
> +
> +description: |+
> + This binding is intended for performance management of groups of devices or
> + CPUs that run in the same performance domain. Performance domains must not
> + be confused with power domains. A performance domain is defined by a set
> + of devices that always have to run at the same performance level. For a given
> + performance domain, there is a single point of control that affects all the
> + devices in the domain, making it impossible to set the performance level of
> + an individual device in the domain independently from other devices in
> + that domain. For example, a set of CPUs that share a voltage domain, and
> + have a common frequency control, is said to be in the same performance
> + domain.
> +
> + This device tree binding can be used to bind performance domain consumer
> + devices with their performance domains provided by performance domain
> + providers. A performance domain provider can be represented by any node in
> + the device tree and can provide one or more performance domains. A consumer
> + node can refer to the provider by a phandle and a set of phandle arguments
> + (so called performance domain specifiers) of length specified by the
> + \#performance-domain-cells property in the performance domain provider node.
> +
> +select: true
> +
> +properties:
> + "#performance-domain-cells":
> + description:
> + Number of cells in a performance domain specifier. Typically 0 for nodes
> + representing a single performance domain and 1 for nodes providing
> + multiple performance domains (e.g. performance controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
> + enum: [ 0, 1 ]
> +
> + performance-domains:
> + $ref: '/schemas/types.yaml#/definitions/phandle-array'
> + description:
> + A phandle and performance domain specifier as defined by bindings of the
> + performance controller/provider specified by phandle.
This implies there is only 1.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + performance: performance-controller@12340000 {
> + compatible = "qcom,cpufreq-hw";
> + reg = <0x12340000 0x1000>;
> + #performance-domain-cells = <1>;
> + };
> +
> + // The node above defines a performance controller that is a performance
> + // domain provider and expects one cell as its phandle argument.
> + gpu@2d000000 {
> + compatible = "arm,mali-t624";
> + reg = <0x2d000000 0x10000>;
> + power-domains = <&power_devpd 2>;
> + performance-domains = <&performance 4>;
> + };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + performance-domains = <&performance 1>;
> + };
> + };
> +
> --
> 2.25.1
>
prev parent reply other threads:[~2021-04-07 19:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 13:59 [PATCH v3] dt-bindings: dvfs: Add support for generic performance domains Sudeep Holla
2021-04-07 17:56 ` Rob Herring
2021-04-07 19:08 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210407190808.GA4053148@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=hector.yuan@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).