| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management updates from Rafael Wysocki:
"These update ARM cpufreq drivers, the OPP (Operating Performance
Points) library and the power management documentation.
Specifics:
- Add per core DVFS support for QCom SoC (Bjorn Andersson), convert
to yaml binding (Manivannan Sadhasivam) and various other fixes to
the QCom drivers (Luca Weiss).
- Add OPP table for imx7s SoC (Denys Drozdov) and minor fixes (Stefan
Agner).
- Fix CPPC driver's freq/performance conversions (Pierre Gondois).
- Minor generic cleanups (Yury Norov).
- Introduce opp-microwatt property to the OPP core, bindings, etc
(Lukasz Luba).
- Convert DT bindings to schema format and various related fixes
(Yassine Oudjana).
- Expose OPP's OF node in debugfs (Viresh Kumar).
- Add Intel uncore frequency scaling documentation file to its
MAINTAINERS entry (Srinivas Pandruvada).
- Clean up the AMD P-state driver documentation (Jan Engelhardt)"
* tag 'pm-5.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (24 commits)
Documentation: amd-pstate: grammar and sentence structure updates
dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings
dt-bindings: dvfs: Use MediaTek CPUFREQ HW as an example
Documentation: EM: Describe new registration method using DT
OPP: Add support of "opp-microwatt" for EM registration
PM: EM: add macro to set .active_power() callback conditionally
OPP: Add "opp-microwatt" supporting code
dt-bindings: opp: Add "opp-microwatt" entry in the OPP
MAINTAINERS: Add additional file to uncore frequency control
cpufreq: blocklist Qualcomm sc8280xp and sa8540p in cpufreq-dt-platdev
cpufreq: qcom-hw: Add support for per-core-dcvs
dt-bindings: power: avs: qcom,cpr: Convert to DT schema
arm64: dts: qcom: qcs404: Rename CPU and CPR OPP tables
arm64: dts: qcom: msm8996: Rename cluster OPP tables
dt-bindings: opp: Convert qcom-nvmem-cpufreq to DT schema
dt-bindings: opp: qcom-opp: Convert to DT schema
arm64: dts: qcom: msm8996-mtp: Add msm8996 compatible
dt-bindings: arm: qcom: Add msm8996 and apq8096 compatibles
opp: Expose of-node's name in debugfs
cpufreq: CPPC: Fix performance/frequency conversion
...
|
|
Qcom CPUFREQ HW don't have the support for generic performance domains yet.
So use MediaTek CPUFREQ HW that has the support available in mainline.
This also silences the below dtschema warnings for "cpufreq-qcom-hw.yaml":
Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: reg: [[305397760, 4096]] is too short
From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: 'clocks' is a required property
From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: 'clock-names' is a required property
From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: '#freq-domain-cells' is a required property
From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
Documentation/devicetree/bindings/dvfs/performance-domain.example.dt.yaml: performance-controller@12340000: '#performance-domain-cells' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
Cc: Hector Yuan <hector.yuan@mediatek.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
The 'phandle-array' type is a bit ambiguous. It can be either just an
array of phandles or an array of phandles plus args. Many schemas for
phandle-array properties aren't clear in the schema which case applies
though the description usually describes it.
The array of phandles case boils down to needing:
items:
maxItems: 1
The phandle plus args cases should typically take this form:
items:
- items:
- description: A phandle
- description: 1st arg cell
- description: 2nd arg cell
With this change, some examples need updating so that the bracketing of
property values matches the schema.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Georgi Djakov <djakov@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20220119015038.2433585-1-robh@kernel.org
|
|
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
Cc: Rob Herring <robh+dt@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
