* [PATCH 11/15] arm: dts: berlin: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing properties (clocks, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/berlin2.dtsi | 10 ++++++++++
arch/arm/boot/dts/berlin2q.dtsi | 33 +++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index d575823c5750..487e9de53244 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -81,6 +81,16 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
};
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index bf3a6c9a1d34..9cd00ab53f2d 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -76,6 +76,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
cpu at 2 {
@@ -83,6 +94,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <2>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
cpu at 3 {
@@ -90,6 +112,17 @@
device_type = "cpu";
next-level-cache = <&l2>;
reg = <3>;
+
+ clocks = <&chip_clk CLKID_CPU>;
+ clock-latency = <100000>;
+ /* Can be modified by the bootloader */
+ operating-points = <
+ /* kHz uV */
+ 1200000 1200000
+ 1000000 1200000
+ 800000 1200000
+ 600000 1200000
+ >;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 10/15] arm: dts: rk3288: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/rk3288.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d7e49d29ace5..752a892847dd 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -122,18 +122,72 @@
compatible = "arm,cortex-a12";
reg = <0x501>;
resets = <&cru SRST_CORE1>;
+ operating-points = <
+ /* KHz uV */
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <40000>;
+ clocks = <&cru ARMCLK>;
};
cpu2: cpu at 502 {
device_type = "cpu";
compatible = "arm,cortex-a12";
reg = <0x502>;
resets = <&cru SRST_CORE2>;
+ operating-points = <
+ /* KHz uV */
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <40000>;
+ clocks = <&cru ARMCLK>;
};
cpu3: cpu at 503 {
device_type = "cpu";
compatible = "arm,cortex-a12";
reg = <0x503>;
resets = <&cru SRST_CORE3>;
+ operating-points = <
+ /* KHz uV */
+ 1608000 1350000
+ 1512000 1300000
+ 1416000 1200000
+ 1200000 1100000
+ 1008000 1050000
+ 816000 1000000
+ 696000 950000
+ 600000 900000
+ 408000 900000
+ 312000 900000
+ 216000 900000
+ 126000 900000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <40000>;
+ clocks = <&cru ARMCLK>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/exynos4210.dtsi | 13 +++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++++++++++++++++++
4 files changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 962af97c1883..aff5d66ae058 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -78,6 +78,22 @@
compatible = "arm,cortex-a7";
reg = <1>;
clock-frequency = <1000000000>;
+ clocks = <&cmu CLK_ARM_CLK>;
+ clock-names = "cpu";
+ #cooling-cells = <2>;
+
+ operating-points = <
+ 1000000 1150000
+ 900000 1112500
+ 800000 1075000
+ 700000 1037500
+ 600000 1000000
+ 500000 962500
+ 400000 925000
+ 300000 887500
+ 200000 850000
+ 100000 850000
+ >;
};
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 88fb47cef9a8..b6091c27f155 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -55,6 +55,19 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0x901>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+ clock-latency = <160000>;
+
+ operating-points = <
+ 1200000 1250000
+ 1000000 1150000
+ 800000 1075000
+ 500000 975000
+ 400000 975000
+ 200000 950000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 7b43c10c510b..51f72f0327e5 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -49,21 +49,30 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA01>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu at a02 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA02>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu at a03 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA03>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 2daf505b3d08..69648f83b8b4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -84,6 +84,29 @@
compatible = "arm,cortex-a15";
reg = <1>;
clock-frequency = <1700000000>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+ clock-latency = <140000>;
+
+ operating-points = <
+ 1700000 1300000
+ 1600000 1250000
+ 1500000 1225000
+ 1400000 1200000
+ 1300000 1150000
+ 1200000 1125000
+ 1100000 1100000
+ 1000000 1075000
+ 900000 1050000
+ 800000 1025000
+ 700000 1012500
+ 600000 1000000
+ 500000 975000
+ 400000 950000
+ 300000 937500
+ 200000 925000
+ >;
+ #cooling-cells = <2>; /* min followed by max */
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 06/15] arm: dts: sun: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 30 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
arch/arm/boot/dts/sun8i-a33.dtsi | 9 +++++++++
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++++++++
4 files changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c72992556a86..debc0bf22ea3 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -119,18 +119,48 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..35372a0cfc8d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -122,6 +122,19 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 960000 1400000
+ 912000 1400000
+ 864000 1300000
+ 720000 1200000
+ 528000 1100000
+ 312000 1000000
+ 144000 1000000
+ >;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 8d278ee001e9..4e92741b24a7 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -132,21 +132,30 @@
};
cpu at 1 {
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 41d57c76f290..9dff6887923c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -84,21 +84,30 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 05/15] arm: dts: uniphier: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index debcbd15c24b..40ed15465095 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -36,6 +36,7 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
cpu2: cpu at 2 {
@@ -46,6 +47,7 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
cpu3: cpu at 3 {
@@ -56,6 +58,7 @@
enable-method = "psci";
next-level-cache = <&l2>;
operating-points-v2 = <&cpu_opp>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 04/15] arm: dts: rk322x: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/rk322x.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index be80e9a2c9af..ef414e39bf3a 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -80,6 +80,7 @@
reg = <0xf01>;
resets = <&cru SRST_CORE1>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
enable-method = "psci";
};
@@ -89,6 +90,7 @@
reg = <0xf02>;
resets = <&cru SRST_CORE2>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
enable-method = "psci";
};
@@ -98,6 +100,7 @@
reg = <0xf03>;
resets = <&cru SRST_CORE3>;
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
enable-method = "psci";
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 03/15] arm: dts: mediatek: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/mt7623.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index d1eb123bc73b..1cdc346a05e8 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -92,6 +92,7 @@
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
clock-frequency = <1300000000>;
};
@@ -103,6 +104,7 @@
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
clock-frequency = <1300000000>;
};
@@ -114,6 +116,7 @@
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
clock-frequency = <1300000000>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 01/15] arm: dts: armada: Fix "#cooling-cells" property's name
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527244200.git.viresh.kumar@linaro.org>
It should be "#cooling-cells" instead of "cooling-cells". Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-385-synology-ds116.dts b/arch/arm/boot/dts/armada-385-synology-ds116.dts
index 6782ce481ac9..d8769956cbfc 100644
--- a/arch/arm/boot/dts/armada-385-synology-ds116.dts
+++ b/arch/arm/boot/dts/armada-385-synology-ds116.dts
@@ -139,7 +139,7 @@
3700 5
3900 6
4000 7>;
- cooling-cells = <2>;
+ #cooling-cells = <2>;
};
gpio-leds {
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH 00/15] arm: dts: Fix OPP and cooling device properties
From: Viresh Kumar @ 2018-05-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
This fixes missing OPP and cooling device properties for CPUs for the
ARM 32 bit platforms. This is build tested by the zero day testing
infrastructure as well.
Individual maintainers can pick the patches to their SoC trees or I will
ask ARM SoC maintainers to pick them up later.
--
viresh
Viresh Kumar (15):
arm: dts: armada: Fix "#cooling-cells" property's name
arm: dts: ls1021a: Add missing cooling device properties for CPUs
arm: dts: mediatek: Add missing cooling device properties for CPUs
arm: dts: rk322x: Add missing cooling device properties for CPUs
arm: dts: uniphier: Add missing cooling device properties for CPUs
arm: dts: sun: Add missing cooling device properties for CPUs
arm: dts: exynos: Add missing cooling device properties for CPUs
arm: dts: dra74x: Add missing cooling device properties for CPUs
arm: dts: omap: Add missing cooling device properties for CPUs
arm: dts: rk3288: Add missing cooling device properties for CPUs
arm: dts: berlin: Add missing OPP properties for CPUs
arm: dts: highbank: Add missing OPP properties for CPUs
arm: dts: r8a7743: Add missing OPP properties for CPUs
arm: dts: qcom: Add missing OPP properties for CPUs
arm: dts: imx: Add missing OPP properties for CPUs
arch/arm/boot/dts/armada-385-synology-ds116.dts | 2 +-
arch/arm/boot/dts/berlin2.dtsi | 10 +++
arch/arm/boot/dts/berlin2q.dtsi | 33 ++++++++++
arch/arm/boot/dts/dra74x.dtsi | 10 +++
arch/arm/boot/dts/exynos3250.dtsi | 16 +++++
arch/arm/boot/dts/exynos4210.dtsi | 13 ++++
arch/arm/boot/dts/exynos4412.dtsi | 9 +++
arch/arm/boot/dts/exynos5250.dtsi | 23 +++++++
arch/arm/boot/dts/highbank.dts | 30 +++++++++
arch/arm/boot/dts/imx6dl.dtsi | 23 +++++++
arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 87 ++++++++++++++++++++++++-
arch/arm/boot/dts/imx7d.dtsi | 5 ++
arch/arm/boot/dts/ls1021a.dtsi | 1 +
arch/arm/boot/dts/mt7623.dtsi | 3 +
arch/arm/boot/dts/omap5.dtsi | 14 ++++
arch/arm/boot/dts/qcom-ipq4019.dtsi | 24 +++++++
arch/arm/boot/dts/r8a7743.dtsi | 9 +++
arch/arm/boot/dts/rk322x.dtsi | 3 +
arch/arm/boot/dts/rk3288.dtsi | 54 +++++++++++++++
arch/arm/boot/dts/sun6i-a31.dtsi | 30 +++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 13 ++++
arch/arm/boot/dts/sun8i-a33.dtsi | 9 +++
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 3 +
25 files changed, 495 insertions(+), 4 deletions(-)
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply
* [PATCH v4 04/26] arm64: alternative: Apply alternatives early in boot process
From: Julien Thierry @ 2018-05-25 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <89769f8d-2ed0-1eb7-0373-09fc25f8071a@arm.com>
On 25/05/18 11:00, Suzuki K Poulose wrote:
> On 25/05/18 10:49, Julien Thierry wrote:
>> From: Daniel Thompson <daniel.thompson@linaro.org>
>>
>> Currently alternatives are applied very late in the boot process (and
>> a long time after we enable scheduling). Some alternative sequences,
>> such as those that alter the way CPU context is stored, must be applied
>> much earlier in the boot sequence.
>>
>> Introduce apply_boot_alternatives() to allow some alternatives to be
>> applied immediately after we detect the CPU features of the boot CPU.
>>
>> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
>> [julien.thierry at arm.com: rename to fit new cpufeature framework better,
>> ???????????? apply BOOT_SCOPE feature early in boot]
>> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@linaro.org>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> ? arch/arm64/include/asm/alternative.h |? 3 +--
>> ? arch/arm64/include/asm/cpufeature.h? |? 2 ++
>> ? arch/arm64/kernel/alternative.c????? | 30
>> +++++++++++++++++++++++++++---
>> ? arch/arm64/kernel/cpufeature.c?????? |? 5 +++++
>> ? arch/arm64/kernel/smp.c????????????? |? 7 +++++++
>> ? 5 files changed, 42 insertions(+), 5 deletions(-)
>>
>
> ...
>
>> +unsigned long boot_capabilities;
>> +
>> ? /*
>> ?? * Flag to indicate if we have computed the system wide
>> ?? * capabilities based on the boot time active CPUs. This
>> @@ -1370,6 +1372,9 @@ static void __update_cpu_capabilities(const
>> struct arm64_cpu_capabilities *caps,
>> ????????? if (!cpus_have_cap(caps->capability) && caps->desc)
>> ????????????? pr_info("%s %s\n", info, caps->desc);
>> ????????? cpus_set_cap(caps->capability);
>> +
>> +??????? if (scope_mask & SCOPE_BOOT_CPU)
>> +??????????? __set_bit(caps->capability, &boot_capabilities);
>
> Julien
>
> I think this check is problematic. The scope_mask passed on by the boot CPU
> is (SCOPE_BOOT_CPU | SCOPE_LOCAL_CPU) to cover both BOOT CPU
> capabilities *and*
> CPU local capabilites on the boot CPU. So, you might apply the
> alternatives for
> a "local" CPU erratum, which is not intended. You may change the above
> check to :
>
> ????if (caps->type & SCOPE_BOOT_CPU)
>
> to make sure you check the "capability" has the SCOPE_BOOT_CPU set.
>
Makes sense, I'll do that.
Thanks,
--
Julien Thierry
^ permalink raw reply
* [PATCHv4 06/10] arm64: add basic pointer authentication support
From: Mark Rutland @ 2018-05-25 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <114d65a8-ffa5-7061-864a-a32aa3baa5c5@arm.com>
On Wed, May 23, 2018 at 09:42:56AM +0100, Suzuki K Poulose wrote:
> On 03/05/18 14:20, Mark Rutland wrote:
> > +#define __ptrauth_key_install(k, v) \
> > +do { \
> > + write_sysreg_s(v.lo, SYS_ ## k ## KEYLO_EL1); \
> > + write_sysreg_s(v.hi, SYS_ ## k ## KEYHI_EL1); \
> > +} while (0)
>
> I think it might be safer to have parentheses around v, to prevent
> something like __ptrauth_key_install(APIA, *key_val) work fine.
In case v is ever an expression with side-effects, I've made this:
#define __ptrauth_key_install(k, v) \
do { \
struct ptrauth_key __pki_v = (v); \
write_sysreg_s(__pki_v.lo, SYS_ ## k ## KEYLO_EL1); \
write_sysreg_s(__pki_v.hi, SYS_ ## k ## KEYHI_EL1); \
} while (0)
... though I could just move the raw sysreg accesses into
ptrauth_keys_switch() for now.
[...]
> > +#ifdef CONFIG_ARM64_PNTR_AUTH
> > + HWCAP_CAP(SYS_ID_AA64ISAR1_EL1, ID_AA64ISAR1_APA_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_APIA),
> > +#endif
>
> Did you mean CONFIG_ARM64_PTR_AUTH here ?
Yes; fixed now.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] mmc: sdhci-*: Don't emit error msg if sdhci_add_host() fails
From: Viresh Kumar @ 2018-05-25 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525151509.0270dbe1@xhacker.debian>
On 25-05-18, 15:15, Jisheng Zhang wrote:
> I noticed below error msg with sdhci-pxav3 on some berlin platforms:
>
> [.....] sdhci-pxav3 f7ab0000.sdhci failed to add host
>
> It is due to getting related vmmc or vqmmc regulator returns
> -EPROBE_DEFER. It doesn't matter at all but it's confusing.
>
> From another side, if driver probing fails and the error number isn't
> -EPROBE_DEFER, the core will tell us something as below:
>
> [.....] sdhci-pxav3: probe of f7ab0000.sdhci failed with error -EXX
>
> So it's not necessary to emit error msg if sdhci_add_host() fails. And
> some other sdhci host drivers also have this issue, let's fix them
> together.
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> drivers/mmc/host/sdhci-spear.c | 4 +---
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Julien Thierry @ 2018-05-25 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e44df12f-9868-ae94-4623-ec221d72d783@arm.com>
On 25/05/18 11:04, Suzuki K Poulose wrote:
> On 25/05/18 10:49, Julien Thierry wrote:
>> Add a cpufeature indicating whether a cpu supports masking interrupts
>> by priority.
>
> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
> the description ?
More or less.
It is just to have an easier condition in the rest of the series.
Basically the PRIO masking feature is enabled if we have a GICv3 CPUIF
working *and* the option was selected at build time. Before this meant
that I was checking for the GIC_CPUIF cap inside #ifdefs (and putting
alternatives depending on that inside #ifdefs as well).
Having this as a separate feature feels easier to manage in the code. It
also makes it clearer at boot time that the kernel will be using irq
priorities (although I admit it was not the initial intention):
[ 0.000000] CPU features: detected: IRQ priority masking
But yes that new feature will be detected only if SYSREG_GIC_CPUIF gets
detected as well.
Cheers,
--
Julien Thierry
^ permalink raw reply
* [PATCH v4 00/26] arm64: provide pseudo NMI with GICv3
From: Daniel Thompson @ 2018-05-25 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527241772-48007-1-git-send-email-julien.thierry@arm.com>
On Fri, May 25, 2018 at 10:49:06AM +0100, Julien Thierry wrote:
> This series is a continuation of the work started by Daniel [1]. The goal
> is to use GICv3 interrupt priorities to simulate an NMI.
>
> To achieve this, set two priorities, one for standard interrupts and
> another, higher priority, for NMIs. Whenever we want to disable interrupts,
> we mask the standard priority instead so NMIs can still be raised. Some
> corner cases though still require to actually mask all interrupts
> effectively disabling the NMI.
>
> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently
> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI
> for now. I don't think there is any reason LPIs should be allowed to be set
> as NMI as they do not have an active state.
> When an NMI is active on a CPU, no other NMI can be triggered on the CPU.
>
> After the big refactoring I get performances similar to the ones I had
> in v3[2], reposting old results here:
>
> - "hackbench 200 process 1000" (average over 20 runs)
> +-----------+----------+------------+------------------+
> | | native | PMR guest | v4.17-rc6 guest |
> +-----------+----------+------------+------------------+
> | PMR host | 40.0336s | 39.3039s | 39.2044s |
> | v4.17-rc6 | 40.4040s | 39.6011s | 39.1147s |
> +-----------+----------+------------+------------------+
>
> - Kernel build from defconfig:
> PMR host: 13m45.743s
> v4.17-rc6: 13m40.400s
>
> I'll try to post more detailed benchmarks later if I find notable
> differences with the previous version.
Do you have a public git tree anywhere... I *can* apply 26 patches from
e-mail but I'd rather pull them!
Daniel.
>
>
> Requirements to use this:
> - Have GICv3
> - SCR_EL3.FIQ is set to 1 when linux runs or have single security state
> - Select Kernel Feature -> Use ICC system registers for IRQ masking
>
>
> * Patches 1 to 4 aim at applying some alternatives early in the boot
> process, including the feature for priority masking.
>
> * Patches 5 to 7 and 17 lightly refactor bits of GIC driver to make things
> nicer for the rest of the series.
>
> * Patches 8 to 10 and 16 ensure the logic of daifflags remains valid
> after arch_local_irq flags use ICC_PMR_EL1.
>
> * Patches 11 to 14 do some required PMR treatement in order for things to
> work when the system uses priority masking.
>
> * Patches 15, 18, 19, 20 and 21 actually make the changes to use
> ICC_PMR_EL1 for priority masking/unmasking when disabling/enabling
> interrupts.
>
> * Patches 22 to 26 provide support for pseudo-NMI in the GICv3 driver
> when priority masking is enabled.
>
>
> Changes since V3[2]:
> * Big refactoring. As suggested by Marc Z., some of the bigger patches
> needed to be split into smaller one.
>
> * Try to reduce the amount of #ifdef for the new feature by introducing
> an individual cpufeature for priority masking
>
> * Do not track which alternatives have been applied (was a bit dodgy
> anyway), and use an alternative for VHE cpu_enable callback
>
> * Fix a build failure with arm by adding the correct RPR accessors
>
> * Added Suggested-by tags for changes from comming or inspired by Daniel's
> series. Do let me know if you feel I missed something and am not giving
> you due credit.
>
> Changes since V2[3]:
> * Series rebase to v4.17-rc6
>
> * Adapt pathces 1 and 2 to the rework of cpufeatures framework
>
> * Use the group0 detection scheme in the GICv3 driver to identify
> the priority view, and drop the use of a fake interrupt
>
> * Add the case for a GIC configured in a single security state
>
> * Use local_daif_restore instead of local_irq_enable the first time
> we enable interrupts after a bp hardening in the handling of a kernel
> entry. Otherwise PRS.I remains set...
>
> Changes since V1[4]:
> * Series rebased to v4.15-rc8.
>
> * Check for arm64_early_features in this_cpu_has_cap (spotted by Suzuki).
>
> * Fix issue where debug exception were not masked when enabling debug in
> mdscr_el1.
>
> Changes since RFC[5]:
> * The series was rebased to v4.15-rc2 which implied some changes mainly
> related to the work on exception entries and daif flags by James Morse.
>
> - The first patch in the previous series was dropped because no longer
> applicable.
>
> - With the semantics James introduced of "inheriting" daif flags,
> handling of PMR on exception entry is simplified as PMR is not altered
> by taking an exception and already inherited from previous state.
>
> - James pointed out that taking a PseudoNMI before reading the FAR_EL1
> register should not be allowed as per the TRM (D10.2.29):
> "FAR_EL1 is made UNKNOWN on an exception return from EL1."
> So in this submission PSR.I bit is cleared only after FAR_EL1 is read.
>
> * For KVM, only deal with PMR unmasking/restoring in common code, and VHE
> specific code makes sure PSR.I bit is set when necessary.
>
> * When detecting the GIC priority view (patch 5), wait for an actual
> interrupt instead of trying only once.
>
>
> [1] http://www.spinics.net/lists/arm-kernel/msg525077.html
> [2] https://lkml.org/lkml/2018/5/21/276
> [3] https://lkml.org/lkml/2018/1/17/335
> [4] https://www.spinics.net/lists/arm-kernel/msg620763.html
> [5] https://www.spinics.net/lists/arm-kernel/msg610736.html
>
> Cheers,
>
> Julien
>
> -->
>
> Daniel Thompson (1):
> arm64: alternative: Apply alternatives early in boot process
>
> Julien Thierry (25):
> arm64: cpufeature: Set SYSREG_GIC_CPUIF as a boot system feature
> arm64: cpufeature: Add cpufeature for IRQ priority masking
> arm64: cpufeature: Use alternatives for VHE cpu_enable
> irqchip/gic: Unify GIC priority definitions
> irqchip/gic: Lower priority of GIC interrupts
> irqchip/gic-v3: Remove acknowledge loop
> arm64: daifflags: Use irqflags functions for daifflags
> arm64: Use daifflag_restore after bp_hardening
> arm64: Delay daif masking for user return
> arm64: Make PMR part of task context
> arm64: Unmask PMR before going idle
> arm/arm64: gic-v3: Add helper functions to manage IRQ priorities
> arm64: kvm: Unmask PMR before entering guest
> arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
> arm64: daifflags: Include PMR in daifflags restore operations
> irqchip/gic-v3: Factor group0 detection into functions
> irqchip/gic-v3: Do not overwrite PMR value
> irqchip/gic-v3: Switch to PMR masking after IRQ acknowledge
> arm64: Switch to PMR masking when starting CPUs
> arm64: Add build option for IRQ masking via priority
> arm64: Detect current view of GIC priorities
> irqchip/gic: Add functions to access irq priorities
> irqchip/gic-v3: Add base support for pseudo-NMI
> irqchip/gic-v3: Provide NMI handlers
> irqchip/gic-v3: Allow interrupts to be set as pseudo-NMI
>
> Documentation/arm64/booting.txt | 5 +
> arch/arm/include/asm/arch_gicv3.h | 33 ++++
> arch/arm64/Kconfig | 15 ++
> arch/arm64/include/asm/alternative.h | 3 +-
> arch/arm64/include/asm/arch_gicv3.h | 32 ++++
> arch/arm64/include/asm/assembler.h | 17 +-
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/include/asm/cpufeature.h | 2 +
> arch/arm64/include/asm/daifflags.h | 32 ++--
> arch/arm64/include/asm/efi.h | 3 +-
> arch/arm64/include/asm/irqflags.h | 100 ++++++++---
> arch/arm64/include/asm/kvm_host.h | 12 ++
> arch/arm64/include/asm/processor.h | 1 +
> arch/arm64/include/asm/ptrace.h | 13 +-
> arch/arm64/kernel/alternative.c | 30 +++-
> arch/arm64/kernel/asm-offsets.c | 1 +
> arch/arm64/kernel/cpufeature.c | 35 +++-
> arch/arm64/kernel/entry.S | 67 ++++++-
> arch/arm64/kernel/head.S | 35 ++++
> arch/arm64/kernel/process.c | 2 +
> arch/arm64/kernel/smp.c | 12 ++
> arch/arm64/kvm/hyp/switch.c | 17 ++
> arch/arm64/mm/fault.c | 5 +-
> arch/arm64/mm/proc.S | 18 ++
> drivers/irqchip/irq-gic-common.c | 10 ++
> drivers/irqchip/irq-gic-common.h | 2 +
> drivers/irqchip/irq-gic-v3-its.c | 2 +-
> drivers/irqchip/irq-gic-v3.c | 318 +++++++++++++++++++++++++++------
> include/linux/interrupt.h | 1 +
> include/linux/irqchip/arm-gic-common.h | 6 +
> include/linux/irqchip/arm-gic.h | 5 -
> 31 files changed, 719 insertions(+), 118 deletions(-)
>
> --
> 1.9.1
^ permalink raw reply
* linux-next: manual merge of the userns tree with the arm tree
From: Mark Brown @ 2018-05-25 10:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Eric,
Yesterday's linux-next merge of the userns tree got a conflict in:
arch/arm/mm/fault.c
between commit:
8d9267cedb9e1d8edb8 ("ARM: spectre-v2: harden user aborts in kernel space")
from the arm tree and commit:
3eb0f5193b497083391 ("signal: Ensure every siginfo we send has all bits initialized")
from the userns tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc arch/arm/mm/fault.c
index 3b1ba003c4f9,32034543f49c..000000000000
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@@ -163,9 -163,8 +163,11 @@@ __do_user_fault(struct task_struct *tsk
{
struct siginfo si;
+ clear_siginfo(&si);
+
+ if (addr > TASK_SIZE)
+ harden_branch_predictor();
+
#ifdef CONFIG_DEBUG_USER
if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
((user_debug & UDBG_BUS) && (sig == SIGBUS))) {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180525/38d71e1f/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable BD9571MWV regulator
From: Simon Horman @ 2018-05-25 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527082531-11640-1-git-send-email-geert+renesas@glider.be>
On Wed, May 23, 2018 at 03:35:31PM +0200, Geert Uytterhoeven wrote:
> From: Dien Pham <dien.pham.ry@renesas.com>
>
> The BD9571 PMIC is present on the Renesas Salvator-X(S) and R-Car
> Starter Kit Premier/Pro development boards.
>
> Signed-off-by: Dien Pham <dien.pham.ry@renesas.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH] ARM: dts: porter: Add missing PMIC nodes
From: Simon Horman @ 2018-05-25 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVCPEChhbHsc1Tcp-zkBY5v8Mz+8qq-v3GVFifL_uLyeA@mail.gmail.com>
On Wed, May 23, 2018 at 01:52:32PM +0200, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Wed, May 23, 2018 at 1:43 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Add PMIC nodes to Porter and connect CPU DVFS supply. There is
> > one DA9063L and one DA9210 on Porter, the only difference from
> > the other boards is that DA9063L is at I2C address 0x5a rather
> > than 0x58 .
>
> Ah, so porter needs the regulator quirk, too.
>
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Suzuki K Poulose @ 2018-05-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527241772-48007-3-git-send-email-julien.thierry@arm.com>
On 25/05/18 10:49, Julien Thierry wrote:
> Add a cpufeature indicating whether a cpu supports masking interrupts
> by priority.
How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
the description ?
Suzuki
^ permalink raw reply
* [PATCH v11 08/19] arm64: fpsimd: Eliminate task->mm checks
From: Alex Bennée @ 2018-05-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527181008-13549-9-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> Currently the FPSIMD handling code uses the condition task->mm ==
> NULL as a hint that task has no FPSIMD register context.
>
> The ->mm check is only there to filter out tasks that cannot
> possibly have FPSIMD context loaded, for optimisation purposes.
> Also, TIF_FOREIGN_FPSTATE must always be checked anyway before
> saving FPSIMD context back to memory. For these reasons, the ->mm
> checks are not useful, providing that TIF_FOREIGN_FPSTATE is
> maintained in a consistent way for all threads.
>
> The context switch logic is already deliberately optimised to defer
> reloads of the regs until ret_to_user (or sigreturn as a special
> case), and save them only if they have been previously loaded.
> These paths are the only places where the wrong_task and wrong_cpu
> conditions can be made false, by calling fpsimd_bind_task_to_cpu().
> Kernel threads by definition never reach these paths. As a result,
> the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will
> always yield true for kernel threads.
>
> This patch removes the redundant checks and special-case code, ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread is scheduled in, and ensures that this flag is set for the init
> task. The fpsimd_flush_task_state() call already present in
> copy_thread() ensures the same for any new task.
>
> With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch
> ensures that no extra context save work is added for kernel
> threads, and eliminates the redundant context saving that may
> currently occur for kernel threads that have acquired an mm via
> use_mm().
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
Still good (although obviously without the ws damage in the commit).
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> ---
>
> Changes since v10:
>
> * The INIT_THREAD flag change is split out into the prior
> patch, since it is in principle a fix rather than simply a
> tidy-up.
>
> Requested by Christoffer Dall / Catalin Marinas:
>
> * Reworded commit message to explain the change more clearly,
> and remove confusing claims about things being true by
> construction.
>
> * Added a comment to the code explaining that wrong_cpu and
> wrong_task will always be true for kernel threads.
>
> * Ensure .fpsimd_cpu = NR_CPUS for the init task.
>
> This does not seem to be a bug, because the wrong_task check in
> fpsimd_thread_switch() should still always be true for the init
> task; but it is nonetheless an inconsistency compared with what
> copy_thread() does.
>
> So fix it to avoid future surprises.
> ---
> arch/arm64/include/asm/processor.h | 4 +++-
> arch/arm64/kernel/fpsimd.c | 40 +++++++++++++++-----------------------
> 2 files changed, 19 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 7675989..36d64f8 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -156,7 +156,9 @@ static inline void arch_thread_struct_whitelist(unsigned long *offset,
> /* Sync TPIDR_EL0 back to thread_struct for current */
> void tls_preserve_current_state(void);
>
> -#define INIT_THREAD { }
> +#define INIT_THREAD { \
> + .fpsimd_cpu = NR_CPUS, \
> +}
>
> static inline void start_thread_common(struct pt_regs *regs, unsigned long pc)
> {
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 2d9a9e8..d736b6c 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -892,31 +892,25 @@ asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
>
> void fpsimd_thread_switch(struct task_struct *next)
> {
> + bool wrong_task, wrong_cpu;
> +
> if (!system_supports_fpsimd())
> return;
> +
> + /* Save unsaved fpsimd state, if any: */
> + fpsimd_save();
> +
> /*
> - * Save the current FPSIMD state to memory, but only if whatever is in
> - * the registers is in fact the most recent userland FPSIMD state of
> - * 'current'.
> + * Fix up TIF_FOREIGN_FPSTATE to correctly describe next's
> + * state. For kernel threads, FPSIMD registers are never loaded
> + * and wrong_task and wrong_cpu will always be true.
> */
> - if (current->mm)
> - fpsimd_save();
> -
> - if (next->mm) {
> - /*
> - * If we are switching to a task whose most recent userland
> - * FPSIMD state is already in the registers of *this* cpu,
> - * we can skip loading the state from memory. Otherwise, set
> - * the TIF_FOREIGN_FPSTATE flag so the state will be loaded
> - * upon the next return to userland.
> - */
> - bool wrong_task = __this_cpu_read(fpsimd_last_state.st) !=
> + wrong_task = __this_cpu_read(fpsimd_last_state.st) !=
> &next->thread.uw.fpsimd_state;
> - bool wrong_cpu = next->thread.fpsimd_cpu != smp_processor_id();
> + wrong_cpu = next->thread.fpsimd_cpu != smp_processor_id();
>
> - update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
> - wrong_task || wrong_cpu);
> - }
> + update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
> + wrong_task || wrong_cpu);
> }
>
> void fpsimd_flush_thread(void)
> @@ -1121,9 +1115,8 @@ void kernel_neon_begin(void)
>
> __this_cpu_write(kernel_neon_busy, true);
>
> - /* Save unsaved task fpsimd state, if any: */
> - if (current->mm)
> - fpsimd_save();
> + /* Save unsaved fpsimd state, if any: */
> + fpsimd_save();
>
> /* Invalidate any task state remaining in the fpsimd regs: */
> fpsimd_flush_cpu_state();
> @@ -1245,8 +1238,7 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block *self,
> {
> switch (cmd) {
> case CPU_PM_ENTER:
> - if (current->mm)
> - fpsimd_save();
> + fpsimd_save();
> fpsimd_flush_cpu_state();
> break;
> case CPU_PM_EXIT:
--
Alex Benn?e
^ permalink raw reply
* [PATCH 03/14] ARM: bugs: hook processor bug checking into SMP and suspend paths
From: Russell King - ARM Linux @ 2018-05-25 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b454e37c-52a8-387f-3649-8ce72c9a5b18@gmail.com>
On Thu, May 24, 2018 at 04:30:40PM -0700, Florian Fainelli wrote:
> On 05/21/2018 04:44 AM, Russell King wrote:
> > Check for CPU bugs when secondary processors are being brought online,
> > and also when CPUs are resuming from a low power mode. This gives an
> > opportunity to check that processor specific bug workarounds are
> > correctly enabled for all paths that a CPU re-enters the kernel.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Something I missed, is that this correctly warns about e.g: missing the
> IBE bit for secondary cores, but it seems to be missing it for the boot CPU:
Are you sure that the boot CPU has the IBE bit clear?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCHv4 05/10] arm64/cpufeature: detect pointer authentication
From: Mark Rutland @ 2018-05-25 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4c057e99-61a9-7f75-664d-1f16f2631766@arm.com>
On Wed, May 23, 2018 at 09:48:28AM +0100, Suzuki K Poulose wrote:
>
> Mark,
>
> On 03/05/18 14:20, Mark Rutland wrote:
> > So that we can dynamically handle the presence of pointer authentication
> > functionality, wire up probing code in cpufeature.c.
> >
> > From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now
> > has four fields describing the presence of pointer authentication
> > functionality:
> >
> > * APA - address authentication present, using an architected algorithm
> > * API - address authentication present, using an IMP DEF algorithm
> > * GPA - generic authentication present, using an architected algorithm
> > * GPI - generic authentication present, using an IMP DEF algorithm
> >
> > For the moment we only care about address authentication, so we only
> > need to check APA and API. It is assumed that if all CPUs support an IMP
> > DEF algorithm, the same algorithm is used across all CPUs.
> >
> > Note that when we implement KVM support, we will also need to ensure
> > that CPUs have uniform support for GPA and GPI.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm64/include/asm/cpucaps.h | 5 ++++-
> > arch/arm64/kernel/cpufeature.c | 47 ++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> > index bc51b72fafd4..9dcb4d1b14f5 100644
> > --- a/arch/arm64/include/asm/cpucaps.h
> > +++ b/arch/arm64/include/asm/cpucaps.h
> > @@ -48,7 +48,10 @@
> > #define ARM64_HAS_CACHE_IDC 27
> > #define ARM64_HAS_CACHE_DIC 28
> > #define ARM64_HW_DBM 29
> > +#define ARM64_HAS_ADDRESS_AUTH_ARCH 30
> > +#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 31
>
> Where are these caps used ? I couldn't find anything in the series
> that uses them. Otherwise looks good to me.
Those were consumed by KVM support, which needed to detect if CPUs had
mismatched support. Currently they're just placeholders as I need a
cpucap value for the separate IMP-DEF / architected probing cases.
I *could* get rid of those and just have the ARM64_HAS_ADDRESS_AUTH case
log "Address authentication", but I wanted to have separate messages for
IMP-DEF vs architected.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v11 07/19] arm64: fpsimd: Avoid FPSIMD context leakage for the init task
From: Alex Bennée @ 2018-05-25 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527181008-13549-8-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> The init task is started with thread_flags equal to 0, which means
> that TIF_FOREIGN_FPSTATE is initially clear.
>
> It is theoretically possible (if unlikely) that the init task could
> reach userspace without ever being scheduled out. If this occurs,
> data left in the FPSIMD registers by the kernel could be exposed.
>
> This patch fixes this anomaly by ensuring that the init task's
> initial TIF_FOREIGN_FPSTATE is set.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Fixes: 005f78cd8849 ("arm64: defer reloading a task's FPSIMD state to userland resume")
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
Still good ;-)
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> ---
>
> Changes since v10:
>
> * New patch.
> ---
> arch/arm64/include/asm/thread_info.h | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
> index 740aa03c..af271f9 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -45,12 +45,6 @@ struct thread_info {
> int preempt_count; /* 0 => preemptable, <0 => bug */
> };
>
> -#define INIT_THREAD_INFO(tsk) \
> -{ \
> - .preempt_count = INIT_PREEMPT_COUNT, \
> - .addr_limit = KERNEL_DS, \
> -}
> -
> #define thread_saved_pc(tsk) \
> ((unsigned long)(tsk->thread.cpu_context.pc))
> #define thread_saved_sp(tsk) \
> @@ -117,5 +111,12 @@ void arch_release_task_struct(struct task_struct *tsk);
> _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
> _TIF_NOHZ)
>
> +#define INIT_THREAD_INFO(tsk) \
> +{ \
> + .flags = _TIF_FOREIGN_FPSTATE, \
> + .preempt_count = INIT_PREEMPT_COUNT, \
> + .addr_limit = KERNEL_DS, \
> +}
> +
> #endif /* __KERNEL__ */
> #endif /* __ASM_THREAD_INFO_H */
--
Alex Benn?e
^ permalink raw reply
* [PATCH v4 04/26] arm64: alternative: Apply alternatives early in boot process
From: Suzuki K Poulose @ 2018-05-25 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527241772-48007-5-git-send-email-julien.thierry@arm.com>
On 25/05/18 10:49, Julien Thierry wrote:
> From: Daniel Thompson <daniel.thompson@linaro.org>
>
> Currently alternatives are applied very late in the boot process (and
> a long time after we enable scheduling). Some alternative sequences,
> such as those that alter the way CPU context is stored, must be applied
> much earlier in the boot sequence.
>
> Introduce apply_boot_alternatives() to allow some alternatives to be
> applied immediately after we detect the CPU features of the boot CPU.
>
> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> [julien.thierry at arm.com: rename to fit new cpufeature framework better,
> apply BOOT_SCOPE feature early in boot]
> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> arch/arm64/include/asm/alternative.h | 3 +--
> arch/arm64/include/asm/cpufeature.h | 2 ++
> arch/arm64/kernel/alternative.c | 30 +++++++++++++++++++++++++++---
> arch/arm64/kernel/cpufeature.c | 5 +++++
> arch/arm64/kernel/smp.c | 7 +++++++
> 5 files changed, 42 insertions(+), 5 deletions(-)
>
...
>
> +unsigned long boot_capabilities;
> +
> /*
> * Flag to indicate if we have computed the system wide
> * capabilities based on the boot time active CPUs. This
> @@ -1370,6 +1372,9 @@ static void __update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
> if (!cpus_have_cap(caps->capability) && caps->desc)
> pr_info("%s %s\n", info, caps->desc);
> cpus_set_cap(caps->capability);
> +
> + if (scope_mask & SCOPE_BOOT_CPU)
> + __set_bit(caps->capability, &boot_capabilities);
Julien
I think this check is problematic. The scope_mask passed on by the boot CPU
is (SCOPE_BOOT_CPU | SCOPE_LOCAL_CPU) to cover both BOOT CPU capabilities *and*
CPU local capabilites on the boot CPU. So, you might apply the alternatives for
a "local" CPU erratum, which is not intended. You may change the above check to :
if (caps->type & SCOPE_BOOT_CPU)
to make sure you check the "capability" has the SCOPE_BOOT_CPU set.
Suzuki
^ permalink raw reply
* [PATCH v2 00/14] ARM Spectre variant 2 fixes
From: Russell King - ARM Linux @ 2018-05-25 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6845807d-4838-53e4-91ad-a7c6ef081f58@gmail.com>
On Thu, May 24, 2018 at 04:18:30PM -0700, Florian Fainelli wrote:
> On 05/21/2018 04:42 AM, Russell King - ARM Linux wrote:
> > This is the second posting - the original cover note is below. Comments
> > from previous series addresesd:
> > - Drop R7 and R8 changes.
> > - Remove "PSCI" from the hypervisor version of the workaround.
> >
> > arch/arm/include/asm/bugs.h | 6 +-
> > arch/arm/include/asm/cp15.h | 3 +
> > arch/arm/include/asm/cputype.h | 5 ++
> > arch/arm/include/asm/kvm_asm.h | 2 -
> > arch/arm/include/asm/kvm_host.h | 14 +++-
> > arch/arm/include/asm/kvm_mmu.h | 23 +++++-
> > arch/arm/include/asm/proc-fns.h | 4 +
> > arch/arm/include/asm/system_misc.h | 8 ++
> > arch/arm/kernel/Makefile | 1 +
> > arch/arm/kernel/bugs.c | 18 +++++
> > arch/arm/kernel/smp.c | 4 +
> > arch/arm/kernel/suspend.c | 2 +
> > arch/arm/kvm/hyp/hyp-entry.S | 108 +++++++++++++++++++++++++-
> > arch/arm/mm/Kconfig | 23 ++++++
> > arch/arm/mm/Makefile | 2 +-
> > arch/arm/mm/fault.c | 3 +
> > arch/arm/mm/proc-macros.S | 3 +-
> > arch/arm/mm/proc-v7-2level.S | 6 --
> > arch/arm/mm/proc-v7-bugs.c | 130 +++++++++++++++++++++++++++++++
> > arch/arm/mm/proc-v7.S | 154 +++++++++++++++++++++++++++++--------
> > 20 files changed, 469 insertions(+), 50 deletions(-)
> > create mode 100644 arch/arm/kernel/bugs.c
> > create mode 100644 arch/arm/mm/proc-v7-bugs.c
>
> Since there appears to be more work needed in the PSCI/KVM changes
> (patches 9 through 14), how about we go with the "bare-metal" parts:
> patches 1-8 first and try to get those included ASAP?
>
> The rationale being that a lot of affected people have Linux running on
> ARMv7-A Cortex-A, typically A9, A15, Brahma-B15, and are in need of
> those patches but do not necessarily require KVM fixes right now, and
> even less so PSCI infrastructure to mitigate ARMv8-A running in AArch32.
>
> In terms of backporting to -stable, and because the spectre variant 1
> patches have not been submitted yet, it is not like we can lump
> everything in one go anyway, so we are not making the lives of the
> -stable maintainers any worse than it currently is?
Patch 6 is implicated in the rework - it will cause big.Little systems
to either have the workaround applied when it isn't required or not
applied when it is required. It depends which CPU is the boot CPU.
For example, a big.Little A7/A15 cluster - if the boot CPU is an A15,
then we will use the ICIALLI switch_mm method for both the A15 and A7.
If the boot CPU is an A7, then we will use the standard switch_mm
method that does not contain the workaround even for the A15, and the
A15 will then be vulnerable.
I don't think we have a way to identify if we boot on a big.Little
system, so the kernel messages could claim to have the workarounds,
but they won't be effective.
This is the hardest one to solve, because it means more invasive
changes to deal with the MM switching paths, which need to become
per-cpu. The problem is, there are times that we call into that
path but the per-cpu variables are not accessible (because the CPU
isn't initialised sufficiently for them to work.)
It's trivial to solve the issues in the later patches by comparison.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v11 08/19] arm64: fpsimd: Eliminate task->mm checks
From: Dave Martin @ 2018-05-25 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525090257.GB54529@C02W217FHV2R.local>
On Fri, May 25, 2018 at 11:02:57AM +0200, Christoffer Dall wrote:
> On Thu, May 24, 2018 at 05:56:37PM +0100, Dave Martin wrote:
> > Currently the FPSIMD handling code uses the condition task->mm ==
> > NULL as a hint that task has no FPSIMD register context.
> >
> > The ->mm check is only there to filter out tasks that cannot
> > possibly have FPSIMD context loaded, for optimisation purposes.
> > Also, TIF_FOREIGN_FPSTATE must always be checked anyway before
> > saving FPSIMD context back to memory. For these reasons, the ->mm
> > checks are not useful, providing that TIF_FOREIGN_FPSTATE is
> > maintained in a consistent way for all threads.
> >
> > The context switch logic is already deliberately optimised to defer
> > reloads of the regs until ret_to_user (or sigreturn as a special
> > case), and save them only if they have been previously loaded.
> > These paths are the only places where the wrong_task and wrong_cpu
> > conditions can be made false, by calling fpsimd_bind_task_to_cpu().
> > Kernel threads by definition never reach these paths. As a result,
> > the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will
> > always yield true for kernel threads.
> >
> > This patch removes the redundant checks and special-case code, ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread is scheduled in, and ensures that this flag is set for the init
> > task. The fpsimd_flush_task_state() call already present in
> > copy_thread() ensures the same for any new task.
>
> nit: formatting still funny, but you shouldn't respin just for that.
Ah jeez... it was a long day.
I guess this isn't the end of the world, but I'll fix this in my branch
and point Marc at it.
> >
> > With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch
> > ensures that no extra context save work is added for kernel
> > threads, and eliminates the redundant context saving that may
> > currently occur for kernel threads that have acquired an mm via
> > use_mm().
>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
[...]
Thanks
---Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox