* [PATCH 5/8] ARM: dts: keystone-clocks: Add missing unit name to clock nodes that have regs
From: Nishanth Menon @ 2017-12-15 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132102.435-1-nm@ti.com>
Add the control register as the base for the clock nodes which are
missing them. This squashes some 78 warnings of the effect when built
with W=1.
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/boot/dts/keystone-clocks.dtsi | 52 +++++++++++++++++-----------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-clocks.dtsi b/arch/arm/boot/dts/keystone-clocks.dtsi
index 2391e3e4d234..0d735e0288db 100644
--- a/arch/arm/boot/dts/keystone-clocks.dtsi
+++ b/arch/arm/boot/dts/keystone-clocks.dtsi
@@ -48,7 +48,7 @@ clocks {
clock-output-names = "gemtraceclk";
};
- chipstmxptclk: chipstmxptclk {
+ chipstmxptclk: chipstmxptclk at 2310164 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-divider-clock";
clocks = <&mainmuxclk>;
@@ -157,7 +157,7 @@ clocks {
clock-output-names = "chipclk1rstiso112";
};
- clkmodrst0: clkmodrst0 {
+ clkmodrst0: clkmodrst0 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
@@ -168,7 +168,7 @@ clocks {
};
- clkusb: clkusb {
+ clkusb: clkusb at 2350008 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
@@ -178,7 +178,7 @@ clocks {
domain-id = <0>;
};
- clkaemifspi: clkaemifspi {
+ clkaemifspi: clkaemifspi at 235000c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
@@ -189,7 +189,7 @@ clocks {
};
- clkdebugsstrc: clkdebugsstrc {
+ clkdebugsstrc: clkdebugsstrc at 2350014 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -199,7 +199,7 @@ clocks {
domain-id = <1>;
};
- clktetbtrc: clktetbtrc {
+ clktetbtrc: clktetbtrc at 2350018 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -209,7 +209,7 @@ clocks {
domain-id = <1>;
};
- clkpa: clkpa {
+ clkpa: clkpa at 235001c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&paclk13>;
@@ -219,7 +219,7 @@ clocks {
domain-id = <2>;
};
- clkcpgmac: clkcpgmac {
+ clkcpgmac: clkcpgmac at 2350020 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkpa>;
@@ -229,7 +229,7 @@ clocks {
domain-id = <2>;
};
- clksa: clksa {
+ clksa: clksa at 2350024 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkpa>;
@@ -239,7 +239,7 @@ clocks {
domain-id = <2>;
};
- clkpcie: clkpcie {
+ clkpcie: clkpcie at 2350028 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -249,7 +249,7 @@ clocks {
domain-id = <3>;
};
- clksr: clksr {
+ clksr: clksr at 2350034 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1rstiso112>;
@@ -259,7 +259,7 @@ clocks {
domain-id = <6>;
};
- clkgem0: clkgem0 {
+ clkgem0: clkgem0 at 235003c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -269,7 +269,7 @@ clocks {
domain-id = <8>;
};
- clkddr30: clkddr30 {
+ clkddr30: clkddr30 at 235005c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -279,7 +279,7 @@ clocks {
domain-id = <16>;
};
- clkwdtimer0: clkwdtimer0 {
+ clkwdtimer0: clkwdtimer0 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -289,7 +289,7 @@ clocks {
domain-id = <0>;
};
- clkwdtimer1: clkwdtimer1 {
+ clkwdtimer1: clkwdtimer1 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -299,7 +299,7 @@ clocks {
domain-id = <0>;
};
- clkwdtimer2: clkwdtimer2 {
+ clkwdtimer2: clkwdtimer2 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -309,7 +309,7 @@ clocks {
domain-id = <0>;
};
- clkwdtimer3: clkwdtimer3 {
+ clkwdtimer3: clkwdtimer3 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -319,7 +319,7 @@ clocks {
domain-id = <0>;
};
- clktimer15: clktimer15 {
+ clktimer15: clktimer15 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -329,7 +329,7 @@ clocks {
domain-id = <0>;
};
- clkuart0: clkuart0 {
+ clkuart0: clkuart0 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -339,7 +339,7 @@ clocks {
domain-id = <0>;
};
- clkuart1: clkuart1 {
+ clkuart1: clkuart1 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -349,7 +349,7 @@ clocks {
domain-id = <0>;
};
- clkaemif: clkaemif {
+ clkaemif: clkaemif at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkaemifspi>;
@@ -359,7 +359,7 @@ clocks {
domain-id = <0>;
};
- clkusim: clkusim {
+ clkusim: clkusim at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -369,7 +369,7 @@ clocks {
domain-id = <0>;
};
- clki2c: clki2c {
+ clki2c: clki2c at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -379,7 +379,7 @@ clocks {
domain-id = <0>;
};
- clkspi: clkspi {
+ clkspi: clkspi at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkaemifspi>;
@@ -389,7 +389,7 @@ clocks {
domain-id = <0>;
};
- clkgpio: clkgpio {
+ clkgpio: clkgpio at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -399,7 +399,7 @@ clocks {
domain-id = <0>;
};
- clkkeymgr: clkkeymgr {
+ clkkeymgr: clkkeymgr at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
--
2.14.1
^ permalink raw reply related
* [PATCH 6/8] ARM: dts: keystone-hk-clocks: Add missing unit name to clock nodes that have regs
From: Nishanth Menon @ 2017-12-15 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132102.435-1-nm@ti.com>
Add the control register as the base for the clock nodes which are
missing them. This squashes some 36 warnings of the effect when built
with W=1.
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/boot/dts/keystone-k2hk-clocks.dtsi | 74 ++++++++++++++---------------
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2hk-clocks.dtsi b/arch/arm/boot/dts/keystone-k2hk-clocks.dtsi
index 142c8491ff54..c2a5fd19ff49 100644
--- a/arch/arm/boot/dts/keystone-k2hk-clocks.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk-clocks.dtsi
@@ -50,7 +50,7 @@ clocks {
reg-names = "control";
};
- clktsip: clktsip {
+ clktsip: clktsip at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
@@ -60,7 +60,7 @@ clocks {
domain-id = <0>;
};
- clksrio: clksrio {
+ clksrio: clksrio at 235002c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1rstiso13>;
@@ -70,7 +70,7 @@ clocks {
domain-id = <4>;
};
- clkhyperlink0: clkhyperlink0 {
+ clkhyperlink0: clkhyperlink0 at 2350030 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -80,7 +80,7 @@ clocks {
domain-id = <5>;
};
- clkgem1: clkgem1 {
+ clkgem1: clkgem1 at 2350040 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -90,7 +90,7 @@ clocks {
domain-id = <9>;
};
- clkgem2: clkgem2 {
+ clkgem2: clkgem2 at 2350044 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -100,7 +100,7 @@ clocks {
domain-id = <10>;
};
- clkgem3: clkgem3 {
+ clkgem3: clkgem3 at 2350048 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -110,7 +110,7 @@ clocks {
domain-id = <11>;
};
- clkgem4: clkgem4 {
+ clkgem4: clkgem4 at 235004c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -120,7 +120,7 @@ clocks {
domain-id = <12>;
};
- clkgem5: clkgem5 {
+ clkgem5: clkgem5 at 2350050 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -130,7 +130,7 @@ clocks {
domain-id = <13>;
};
- clkgem6: clkgem6 {
+ clkgem6: clkgem6 at 2350054 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -140,7 +140,7 @@ clocks {
domain-id = <14>;
};
- clkgem7: clkgem7 {
+ clkgem7: clkgem7 at 2350058 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -150,7 +150,7 @@ clocks {
domain-id = <15>;
};
- clkddr31: clkddr31 {
+ clkddr31: clkddr31 at 2350060 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -160,7 +160,7 @@ clocks {
domain-id = <16>;
};
- clktac: clktac {
+ clktac: clktac at 2350064 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -170,7 +170,7 @@ clocks {
domain-id = <17>;
};
- clkrac01: clkrac01 {
+ clkrac01: clkrac01 at 2350068 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -180,7 +180,7 @@ clocks {
domain-id = <17>;
};
- clkrac23: clkrac23 {
+ clkrac23: clkrac23 at 235006c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -190,7 +190,7 @@ clocks {
domain-id = <18>;
};
- clkfftc0: clkfftc0 {
+ clkfftc0: clkfftc0 at 2350070 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -200,7 +200,7 @@ clocks {
domain-id = <19>;
};
- clkfftc1: clkfftc1 {
+ clkfftc1: clkfftc1 at 2350074 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -210,7 +210,7 @@ clocks {
domain-id = <19>;
};
- clkfftc2: clkfftc2 {
+ clkfftc2: clkfftc2 at 2350078 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -220,7 +220,7 @@ clocks {
domain-id = <20>;
};
- clkfftc3: clkfftc3 {
+ clkfftc3: clkfftc3 at 235007c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -230,7 +230,7 @@ clocks {
domain-id = <20>;
};
- clkfftc4: clkfftc4 {
+ clkfftc4: clkfftc4 at 2350080 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -240,7 +240,7 @@ clocks {
domain-id = <20>;
};
- clkfftc5: clkfftc5 {
+ clkfftc5: clkfftc5 at 2350084 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -250,7 +250,7 @@ clocks {
domain-id = <20>;
};
- clkaif: clkaif {
+ clkaif: clkaif at 2350088 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -260,7 +260,7 @@ clocks {
domain-id = <21>;
};
- clktcp3d0: clktcp3d0 {
+ clktcp3d0: clktcp3d0 at 235008c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -270,7 +270,7 @@ clocks {
domain-id = <22>;
};
- clktcp3d1: clktcp3d1 {
+ clktcp3d1: clktcp3d1 at 2350090 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -280,7 +280,7 @@ clocks {
domain-id = <22>;
};
- clktcp3d2: clktcp3d2 {
+ clktcp3d2: clktcp3d2 at 2350094 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -290,7 +290,7 @@ clocks {
domain-id = <23>;
};
- clktcp3d3: clktcp3d3 {
+ clktcp3d3: clktcp3d3 at 2350098 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -300,7 +300,7 @@ clocks {
domain-id = <23>;
};
- clkvcp0: clkvcp0 {
+ clkvcp0: clkvcp0 at 235009c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -310,7 +310,7 @@ clocks {
domain-id = <24>;
};
- clkvcp1: clkvcp1 {
+ clkvcp1: clkvcp1 at 23500a0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -320,7 +320,7 @@ clocks {
domain-id = <24>;
};
- clkvcp2: clkvcp2 {
+ clkvcp2: clkvcp2 at 23500a4 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -330,7 +330,7 @@ clocks {
domain-id = <24>;
};
- clkvcp3: clkvcp3 {
+ clkvcp3: clkvcp3 at 23500a8 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -340,7 +340,7 @@ clocks {
domain-id = <24>;
};
- clkvcp4: clkvcp4 {
+ clkvcp4: clkvcp4 at 23500ac {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -350,7 +350,7 @@ clocks {
domain-id = <25>;
};
- clkvcp5: clkvcp5 {
+ clkvcp5: clkvcp5 at 23500b0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -360,7 +360,7 @@ clocks {
domain-id = <25>;
};
- clkvcp6: clkvcp6 {
+ clkvcp6: clkvcp6 at 23500b4 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -370,7 +370,7 @@ clocks {
domain-id = <25>;
};
- clkvcp7: clkvcp7 {
+ clkvcp7: clkvcp7 at 23500b8 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -380,7 +380,7 @@ clocks {
domain-id = <25>;
};
- clkbcp: clkbcp {
+ clkbcp: clkbcp at 23500bc {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -390,7 +390,7 @@ clocks {
domain-id = <26>;
};
- clkdxb: clkdxb {
+ clkdxb: clkdxb at 23500c0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -400,7 +400,7 @@ clocks {
domain-id = <27>;
};
- clkhyperlink1: clkhyperlink1 {
+ clkhyperlink1: clkhyperlink1 at 23500c4 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -410,7 +410,7 @@ clocks {
domain-id = <28>;
};
- clkxge: clkxge {
+ clkxge: clkxge at 23500c8 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
--
2.14.1
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: keystone-k2e-clocks: Add missing unit name to clock nodes that have regs
From: Nishanth Menon @ 2017-12-15 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132102.435-1-nm@ti.com>
Add the control register as the base for the clock nodes which are
missing them. This squashes the following warnings of the effect when built
with W=1:
arch/arm/boot/dts/keystone-k2e-evm.dtb: Warning (unit_address_vs_reg): Node /soc at 0/clocks/clkusb1 has a reg or ranges property, but no unit name
arch/arm/boot/dts/keystone-k2e-evm.dtb: Warning (unit_address_vs_reg): Node /soc at 0/clocks/clkhyperlink0 has a reg or ranges property, but no unit name
arch/arm/boot/dts/keystone-k2e-evm.dtb: Warning (unit_address_vs_reg): Node /soc at 0/clocks/clkpcie1 has a reg or ranges property, but no unit name
arch/arm/boot/dts/keystone-k2e-evm.dtb: Warning (unit_address_vs_reg): Node /soc at 0/clocks/clkxge has a reg or ranges property, but no unit name
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/boot/dts/keystone-k2e-clocks.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-clocks.dtsi b/arch/arm/boot/dts/keystone-k2e-clocks.dtsi
index a0fe6eccca8d..e4a01211d9a1 100644
--- a/arch/arm/boot/dts/keystone-k2e-clocks.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e-clocks.dtsi
@@ -32,7 +32,7 @@ clocks {
reg-names = "control";
};
- clkusb1: clkusb1 {
+ clkusb1: clkusb1 at 2350004 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
@@ -42,7 +42,7 @@ clocks {
domain-id = <0>;
};
- clkhyperlink0: clkhyperlink0 {
+ clkhyperlink0: clkhyperlink02350030 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -52,7 +52,7 @@ clocks {
domain-id = <5>;
};
- clkpcie1: clkpcie1 {
+ clkpcie1: clkpcie1 at 235006c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -62,7 +62,7 @@ clocks {
domain-id = <18>;
};
- clkxge: clkxge {
+ clkxge: clkxge at 23500c8 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
--
2.14.1
^ permalink raw reply related
* [PATCH 8/8] ARM: dts: keystone-k2l-clocks: Add missing unit name to clock nodes that have regs
From: Nishanth Menon @ 2017-12-15 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132102.435-1-nm@ti.com>
Add the control register as the base for the clock nodes which are
missing them. This squashes some 22 warnings of the effect when built
with W=1.
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/boot/dts/keystone-k2l-clocks.dtsi | 44 +++++++++++++++---------------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2l-clocks.dtsi b/arch/arm/boot/dts/keystone-k2l-clocks.dtsi
index fc986909d70e..f85289e2431c 100644
--- a/arch/arm/boot/dts/keystone-k2l-clocks.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l-clocks.dtsi
@@ -41,7 +41,7 @@ clocks {
reg-names = "control";
};
- clkdfeiqnsys: clkdfeiqnsys {
+ clkdfeiqnsys: clkdfeiqnsys at 2350004 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -51,7 +51,7 @@ clocks {
domain-id = <0>;
};
- clkpcie1: clkpcie1 {
+ clkpcie1: clkpcie1 at 235002c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk12>;
@@ -61,7 +61,7 @@ clocks {
domain-id = <4>;
};
- clkgem1: clkgem1 {
+ clkgem1: clkgem1 at 2350040 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -71,7 +71,7 @@ clocks {
domain-id = <9>;
};
- clkgem2: clkgem2 {
+ clkgem2: clkgem2 at 2350044 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -81,7 +81,7 @@ clocks {
domain-id = <10>;
};
- clkgem3: clkgem3 {
+ clkgem3: clkgem3 at 2350048 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk1>;
@@ -91,7 +91,7 @@ clocks {
domain-id = <11>;
};
- clktac: clktac {
+ clktac: clktac at 2350064 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -101,7 +101,7 @@ clocks {
domain-id = <17>;
};
- clkrac: clkrac {
+ clkrac: clkrac at 2350068 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -111,7 +111,7 @@ clocks {
domain-id = <17>;
};
- clkdfepd0: clkdfepd0 {
+ clkdfepd0: clkdfepd0 at 235006c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -121,7 +121,7 @@ clocks {
domain-id = <18>;
};
- clkfftc0: clkfftc0 {
+ clkfftc0: clkfftc0 at 2350070 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -131,7 +131,7 @@ clocks {
domain-id = <19>;
};
- clkosr: clkosr {
+ clkosr: clkosr at 2350088 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -141,7 +141,7 @@ clocks {
domain-id = <21>;
};
- clktcp3d0: clktcp3d0 {
+ clktcp3d0: clktcp3d0 at 235008c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -151,7 +151,7 @@ clocks {
domain-id = <22>;
};
- clktcp3d1: clktcp3d1 {
+ clktcp3d1: clktcp3d1 at 2350094 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -161,7 +161,7 @@ clocks {
domain-id = <23>;
};
- clkvcp0: clkvcp0 {
+ clkvcp0: clkvcp0 at 235009c {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -171,7 +171,7 @@ clocks {
domain-id = <24>;
};
- clkvcp1: clkvcp1 {
+ clkvcp1: clkvcp1 at 23500a0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -181,7 +181,7 @@ clocks {
domain-id = <24>;
};
- clkvcp2: clkvcp2 {
+ clkvcp2: clkvcp2 at 23500a4 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -191,7 +191,7 @@ clocks {
domain-id = <24>;
};
- clkvcp3: clkvcp3 {
+ clkvcp3: clkvcp3 at 23500a8 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -201,7 +201,7 @@ clocks {
domain-id = <24>;
};
- clkbcp: clkbcp {
+ clkbcp: clkbcp at 23500bc {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -211,7 +211,7 @@ clocks {
domain-id = <26>;
};
- clkdfepd1: clkdfepd1 {
+ clkdfepd1: clkdfepd1 at 23500c0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -221,7 +221,7 @@ clocks {
domain-id = <27>;
};
- clkfftc1: clkfftc1 {
+ clkfftc1: clkfftc1 at 23500c4 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -231,7 +231,7 @@ clocks {
domain-id = <28>;
};
- clkiqnail: clkiqnail {
+ clkiqnail: clkiqnail at 23500c8 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk13>;
@@ -241,7 +241,7 @@ clocks {
domain-id = <29>;
};
- clkuart2: clkuart2 {
+ clkuart2: clkuart2 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
@@ -251,7 +251,7 @@ clocks {
domain-id = <0>;
};
- clkuart3: clkuart3 {
+ clkuart3: clkuart3 at 2350000 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&clkmodrst0>;
--
2.14.1
^ permalink raw reply related
* [GIT PULL] tee dynamic shm for v4.16
From: Jens Wiklander @ 2017-12-15 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hello arm-soc maintainers,
Please pull these tee driver changes. This implements support for dynamic
shared memory support in OP-TEE. More specifically is enables mapping of
user space memory in secure world to be used as shared memory.
This has been reviewed and refined by the OP-TEE community at various
places on Github during the last year. An earlier version of this pull
request is used in the latest OP-TEE release (2.6.0). This has also been
reviewed recently at the kernel mailing lists, with all comments from
Mark Rutland <mark.rutland@arm.com> and Yury Norov
<ynorov@caviumnetworks.com> addressed as far as I can tell.
This isn't a bugfix so I'm aiming for the next merge window.
Thanks,
Jens
The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
are available in the git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/tee-drv-dynamic-shm-for-v4.16
for you to fetch changes up to ef8e08d24ca84846ce639b835ebd2f15a943f42b:
tee: shm: inline tee_shm_get_id() (2017-12-15 13:36:21 +0100)
----------------------------------------------------------------
This pull request enables dynamic shared memory support in the TEE
subsystem as a whole and in OP-TEE in particular.
Global Platform TEE specification [1] allows client applications
to register part of own memory as a shared buffer between
application and TEE. This allows fast zero-copy communication between
TEE and REE. But current implementation of TEE in Linux does not support
this feature.
Also, current implementation of OP-TEE transport uses fixed size
pre-shared buffer for all communications with OP-TEE OS. This is okay
in the most use cases. But this prevents use of OP-TEE in virtualized
environments, because:
a) We can't share the same buffer between different virtual machines
b) Physically contiguous memory as seen by VM can be non-contiguous
in reality (and as seen by OP-TEE OS) due to second stage of
MMU translation.
c) Size of this pre-shared buffer is limited.
So, first part of this pull request adds generic register/unregister
interface to tee subsystem. The second part adds necessary features into
OP-TEE driver, so it can use not only static pre-shared buffer, but
whole RAM to communicate with OP-TEE OS.
This change is backwards compatible allowing older secure world or
user space to work with newer kernels and vice versa.
[1] https://www.globalplatform.org/specificationsdevice.asp
----------------------------------------------------------------
Jens Wiklander (2):
tee: flexible shared memory pool creation
tee: add register user memory
Volodymyr Babchuk (12):
tee: shm: add accessors for buffer size and page offset
tee: shm: add page accessor functions
tee: optee: Update protocol definitions
tee: optee: add page list manipulation functions
tee: optee: add shared buffer registration functions
tee: optee: add registered shared parameters handling
tee: optee: add registered buffers handling into RPC calls
tee: optee: store OP-TEE capabilities in private data
tee: optee: add optee-specific shared pool implementation
tee: optee: enable dynamic SHM support
tee: use reference counting for tee_context
tee: shm: inline tee_shm_get_id()
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/call.c | 179 +++++++++++++++++++++++++++++-
drivers/tee/optee/core.c | 152 +++++++++++++++++++------
drivers/tee/optee/optee_msg.h | 38 ++++++-
drivers/tee/optee/optee_private.h | 27 ++++-
drivers/tee/optee/optee_smc.h | 7 ++
drivers/tee/optee/rpc.c | 77 +++++++++++--
drivers/tee/optee/shm_pool.c | 75 +++++++++++++
drivers/tee/optee/shm_pool.h | 23 ++++
drivers/tee/tee_core.c | 81 ++++++++++++--
drivers/tee/tee_private.h | 60 +---------
drivers/tee/tee_shm.c | 228 +++++++++++++++++++++++++++++++-------
drivers/tee/tee_shm_pool.c | 165 ++++++++++++++++-----------
include/linux/tee_drv.h | 183 +++++++++++++++++++++++++++++-
include/uapi/linux/tee.h | 30 +++++
15 files changed, 1105 insertions(+), 221 deletions(-)
create mode 100644 drivers/tee/optee/shm_pool.c
create mode 100644 drivers/tee/optee/shm_pool.h
^ permalink raw reply
* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Lorenzo Pieralisi @ 2017-12-15 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171117133831.1300-1-johan@kernel.org>
On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> Fix child-node lookup during initialisation which was using the wrong
> OF-helper and ended up searching the whole device tree depth-first
> starting at the parent rather than just matching on its children.
>
> To make things worse, the parent pci node could end up being prematurely
> freed as of_find_node_by_name() drops a reference to its first argument.
> Any matching child interrupt-controller node was also leaked.
>
> Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> Cc: stable <stable@vger.kernel.org> # 3.18
> Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
Applied to pci/keystone for v4.16.
Thanks,
Lorenzo
> v2
> - amend commit message and mention explicitly that of_find_node_by_name()
> drops a reference to the start node
> - add Murali's and Lorenzo's acks
>
>
> drivers/pci/dwc/pci-keystone.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c
> index 5bee3af47588..39405598b22d 100644
> --- a/drivers/pci/dwc/pci-keystone.c
> +++ b/drivers/pci/dwc/pci-keystone.c
> @@ -178,7 +178,7 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
> }
>
> /* interrupt controller is in a child node */
> - *np_temp = of_find_node_by_name(np_pcie, controller);
> + *np_temp = of_get_child_by_name(np_pcie, controller);
> if (!(*np_temp)) {
> dev_err(dev, "Node for %s is absent\n", controller);
> return -EINVAL;
> @@ -187,6 +187,7 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
> temp = of_irq_count(*np_temp);
> if (!temp) {
> dev_err(dev, "No IRQ entries in %s\n", controller);
> + of_node_put(*np_temp);
> return -EINVAL;
> }
>
> @@ -204,6 +205,8 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
> break;
> }
>
> + of_node_put(*np_temp);
> +
> if (temp) {
> *num_irqs = temp;
> return 0;
> --
> 2.15.0
>
^ permalink raw reply
* [PATCH v9 0/2] media: ov7740: Add a V4L2 sensor-level driver
From: Wenyou.Yang at microchip.com @ 2017-12-15 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211013146.2497-1-wenyou.yang@microchip.com>
Hi Sakari,
Do you have some comments on this version?
Best Regards,
Wenyou Yang
> -----Original Message-----
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kernel.org] On Behalf Of Wenyou Yang
> Sent: 2017?12?11? 9:32
> To: Mauro Carvalho Chehab <mchehab@s-opensource.com>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>
> Cc: linux-kernel at vger.kernel.org; Nicolas Ferre - M43238
> <Nicolas.Ferre@microchip.com>; devicetree at vger.kernel.org; Sakari Ailus
> <sakari.ailus@iki.fi>; Jonathan Corbet <corbet@lwn.net>; Hans Verkuil
> <hverkuil@xs4all.nl>; linux-arm-kernel at lists.infradead.org; Linux Media Mailing List
> <linux-media@vger.kernel.org>; Wenyou Yang - A41535
> <Wenyou.Yang@microchip.com>
> Subject: [PATCH v9 0/2] media: ov7740: Add a V4L2 sensor-level driver
>
> Add a Video4Linux2 sensor-level driver for the OmniVision OV7740 VGA camera
> image sensor.
>
> Changes in v9:
> - Use the new SPDX ids.
>
> Changes in v8:
> - As the registers are written at stream start, remove the written
> code from the set fmt function.
>
> Changes in v7:
> - Add Acked-by tag.
> - Fix the wrong handle of default register configuration.
> - Add the missed assignment of ov7740->frmsize.
>
> Changes in v6:
> - Remove unnecessary #include <linux/init>.
> - Remove unnecessary comments and extra newline.
> - Add const for some structures.
> - Add the check of the return value from regmap_write().
> - Simplify the calling of __v4l2_ctrl_handler_setup().
> - Add the default format initialization function.
> - Integrate the set_power() and enable/disable the clock into
> one function.
>
> Changes in v5:
> - Squash the driver and MAINTAINERS entry patches to one.
> - Precede the driver patch with the bindings patch.
>
> Changes in v4:
> - Assign 'val' a initial value to avoid warning: 'val' may be
> used uninitialized.
> - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.
>
> Changes in v3:
> - Explicitly document the "remote-endpoint" property.
> - Put the MAINTAINERS change to a separate patch.
>
> Changes in v2:
> - Split off the bindings into a separate patch.
> - Add a new entry to the MAINTAINERS file.
>
> Wenyou Yang (2):
> media: ov7740: Document device tree bindings
> media: i2c: Add the ov7740 image sensor driver
>
> .../devicetree/bindings/media/i2c/ov7740.txt | 47 +
> MAINTAINERS | 8 +
> drivers/media/i2c/Kconfig | 8 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/ov7740.c | 1216 ++++++++++++++++++++
> 5 files changed, 1280 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
> create mode 100644 drivers/media/i2c/ov7740.c
>
> --
> 2.15.0
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-15 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215112343.GR22781@e103592.cambridge.arm.com>
Hi Dave,
On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin <Dave.Martin@arm.com> wrote:
> On Thu, Dec 14, 2017 at 07:08:27PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 14, 2017 at 4:24 PM, Dave P Martin <Dave.Martin@arm.com> wrote:
>> > On Thu, Dec 14, 2017 at 02:34:50PM +0000, Geert Uytterhoeven wrote:
>> >> On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
>> >> <geert@linux-m68k.org> wrote:
>> >> > During userspace (Debian jessie NFS root) boot on arm64:
>> >> >
>> >> > rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
>> >> > esr 0x92000004, in dash[aaaaadf77000+1a000]
>> >> > CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>> >> > 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>> >> > Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
>> >>
>> >> This is a quad Cortex A57.
>> >>
>> >> > pstate: 80000000 (Nzcv daif -PAN -UAO)
>> >> > pc : 0xaaaaadf8a51c
>> >> > lr : 0xaaaaadf8ac08
>> >> > sp : 0000ffffcffeac00
>> >> > x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
>> >> > x27: 0000ffffcffebf7c x26: 0000ffffcffead20
>> >> > x25: 0000aaaacea1c5f0 x24: 0000000000000000
>> >> > x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
>> >> > x21: 0000000000000000 x20: 0000000000000008
>> >> > x19: 0000000000000000 x18: 0000ffffcffeb500
>> >> > x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
>> >> > x15: 0000ffffa2363588 x14: ffffffffffffffff
>> >> > x13: 0000000000000020 x12: 0000000000000010
>> >> > x11: 0101010101010101 x10: 0000aaaaadfa1000
>> >> > x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
>> >> > x7 : 0000000000000000 x6 : 0000000000000000
>> >> > x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
>> >> > x3 : 0000aaaaadfa2338 x2 : 0000000000000000
>> >> > x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
>> >> >
>> >> > Sometimes it happens with other processes, but the main address, esr, and
>> >> > pstate values are always the same.
>> >> >
>> >> > I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>> >> > releases, so the last time was two weeks ago), but never saw the issue
>> >> > before until today, so probably v4.15-rc1 is OK.
>> >> > Unfortunately it doesn't happen during every boot, which makes it
>> >> > cumbersome to bisect.
>> >> >
>> >> > My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>> >> > and even without today's arm64/for-next/core merged in, I still managed to
>> >> > reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>> >> > v4.15-rc3.
>> >> >
>> >> > Once, when the kernel message above wasn't shown, I got an error from
>> >> > userspace, which may be related:
>> >> > *** Error in `/bin/sh': free(): invalid pointer: 0x0000aaaadd970988 ***
>> >>
>> >> With more boots (10 instead of 6) to declare a kernel good, I bisected this
>> >> to commit 9de52a755cfb6da5 ("arm64: fpsimd: Fix failure to restore FPSIMD
>> >> state after signals").
>> >>
>> >> Reverting that commit on top of v4.15-rc3 fixed the issue for me.
>> >
>> > Good work on the bisect -- I'll need to have a think about this...
>> >
>> > That patch fixes a genuine problem so we can't just revert it.
>> >
>> > What if you revert _just this function_ back to what it was in v4.14?
>>
>> With fpsimd_update_current_state() reverted to v4.14, and
>>
>> - __this_cpu_write(fpsimd_last_state, st);
>> + __this_cpu_write(fpsimd_last_state.st, st);
>>
>> to make it build, the problem seems to be fixed, too.
> Interesting if I apply that to v4.14 and then flatten the new code for CONFIG_ARM64_SVE=n, I get:
>
> Working:
>
> void fpsimd_update_current_state(struct fpsimd_state *state)
> {
> local_bh_disable();
>
> fpsimd_load_state(state);
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> struct fpsimd_state *st = ¤t->thread.fpsimd_state;
>
> __this_cpu_write(fpsimd_last_state.st, st);
> st->cpu = smp_processor_id();
> }
>
> local_bh_enable();
> }
>
> Broken:
>
> void fpsimd_update_current_state(struct fpsimd_state *state)
> {
> struct fpsimd_last_state_struct *last;
> struct fpsimd_state *st;
>
> local_bh_disable();
>
> current->thread.fpsimd_state = *state;
> fpsimd_load_state(¤t->thread.fpsimd_state);
>
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> last = this_cpu_ptr(&fpsimd_last_state);
> st = ¤t->thread.fpsimd_state;
>
> last->st = st;
> last->sve_in_use = test_thread_flag(TIF_SVE);
> st->cpu = smp_processor_id();
> }
>
> local_bh_enable();
> }
>
> Can you try my flattened "broken" version by itself and see if that does
> reproduce the bug? If not, my flattening may be making bad assumptions...
>
> Assuming the "broken" version reproduces the bug, I can't yet see exactly
> where the breakage comes from.
Correct, above "Working" is working, and "Broken" is broken.
> The two important differences here seem to be
>
> 1) Staging the state via current->thread.fpsimd_state instead of loading
> directly:
>
> - fpsimd_load_state(state);
> + current->thread.fpsimd_state = *state;
> + fpsimd_load_state(¤t->thread.fpsimd_state);
The change above introduces the breakage.
> 2) Using this_cpu_ptr() + assignment instead of __this_cpu_write() when
> reassociating the task's fpsimd context with the cpu:
>
> {
> + struct fpsimd_last_state_struct *last;
> + struct fpsimd_state *st;
>
> [...]
>
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> - struct fpsimd_state *st = ¤t->thread.fpsimd_state;
> -
> - __this_cpu_write(fpsimd_last_state.st, st);
> - st->cpu = smp_processor_id();
> + last = this_cpu_ptr(&fpsimd_last_state);
> + st = ¤t->thread.fpsimd_state;
> +
> + last->st = st;
> + last->sve_in_use = test_thread_flag(TIF_SVE);
> + st->cpu = smp_processor_id();
> }
The change above is fine.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] PCI: xgene: Remove leftover pci_scan_child_bus() call
From: Lorenzo Pieralisi @ 2017-12-15 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAsHzqv_fYOZTHLWSTSXX=2YziMWcNg15qz1mGaRdyWMa7Hntg@mail.gmail.com>
On Fri, Dec 08, 2017 at 10:32:52AM -0800, Khuong Dinh wrote:
> Hi Lorenzo,
>
> On Tue, Nov 21, 2017 at 7:49 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > The changes in commit 9af275be15f7 ("PCI: xgene: Convert PCI scan API to
> > pci_scan_root_bus_bridge()") converted the xgene PCI host driver to
> > the new pci_scan_root_bus_bridge() bus scanning API but erroneously left
> > the existing pci_scan_child_bus() call in place which resulted in duplicate
> > PCI bus enumerations.
> >
> > Remove the leftover pci_scan_child_bus() call to properly complete the API
> > conversion.
> >
> > Fixes: 9af275be15f7 ("PCI: xgene: Convert PCI scan API to pci_scan_root_bus_bridge()")
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Tanmay Inamdar <tinamdar@apm.com>
> > ---
> > drivers/pci/host/pci-xgene.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> > index 465aa2a..e60c457 100644
> > --- a/drivers/pci/host/pci-xgene.c
> > +++ b/drivers/pci/host/pci-xgene.c
> > @@ -668,7 +668,6 @@ static int xgene_pcie_probe(struct platform_device *pdev)
> >
> > bus = bridge->bus;
> >
> > - pci_scan_child_bus(bus);
> > pci_assign_unassigned_bus_resources(bus);
> > list_for_each_entry(child, &bus->children, node)
> > pcie_bus_configure_settings(child);
> > --
> > 2.9.5
> >
>
> It is good with X-Gene
>
> Tested-by: Khuong Dinh <kdinh@apm.com>
Thank you. Bjorn, I will queue this for v4.16 - I would add a stable tag
since we have v4.13+ kernels scanning the bus twice on xgene, I am not
too happy about this.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 07/25] arm: keystone: dts: Remove leading 0x and 0s from bindings notation
From: Nishanth Menon @ 2017-12-15 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124638.30233-1-malat@debian.org>
On 12/15/2017 06:46 AM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/8] ARM: dts: keystone*: Use a single soc0 instance
From: Nishanth Menon @ 2017-12-15 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132102.435-3-nm@ti.com>
Crap.. couple of typos crept in. Apologies - Santosh, if you dont want
to manualy change, I can rebase and repost if you like to any branch
of your choice.
On 12/15/2017 07:20 AM, Nishanth Menon wrote:
> Provide and soc0 node and reference the same to simplify dts. This also
^^ - should have been a
> resolves the following warnings when built with W=1:
> arch/arm/boot/dts/keystone-k2hk-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2l-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2e-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2g-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2g-ice.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
>
> NOTE: Though we can reformat files by reducing 1 level of indent due to
> the use of soc0 phandle, we ommit that change to prevent un-necessary
^^ -> omit
> churn in code base.
>
> Reported-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Apologies once again on my oversight.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v3] firmware: qcom: scm: Fix incorrect of_node_put calls in scm_init
From: Loys Ollivier @ 2017-12-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
When using other platform architectures, in the init of the qcom_scm
driver, of_node_put is called on /firmware if no qcom dt is found.
This results in a kernel error: Bad of_node_put() on /firmware.
These calls to of_node_put from the qcom_scm init are unnecessary as
of_find_matching_node and of_platform_populate are calling it
automatically.
Remove the calls to of_node_put() on fw_np.
Fixes: d0f6fa7ba2d6 ("firmware: qcom: scm: Convert SCM to platform driver")
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
---
drivers/firmware/qcom_scm.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index af4c75217ea6..f6d7b7cffe0c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -632,17 +632,13 @@ static int __init qcom_scm_init(void)
np = of_find_matching_node(fw_np, qcom_scm_dt_match);
- if (!np) {
- of_node_put(fw_np);
+ if (!np)
return -ENODEV;
- }
of_node_put(np);
ret = of_platform_populate(fw_np, qcom_scm_dt_match, NULL, NULL);
- of_node_put(fw_np);
-
if (ret)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH 14/25] arm: stm32: dts: Remove leading 0x and 0s from bindings notation
From: Alexandre Torgue @ 2017-12-15 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124646.30591-1-malat@debian.org>
Hi Mathieu
On 12/15/2017 01:46 PM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
I will merge it in my next pull request for 4.16.
Thanks
Alex
> arch/arm/boot/dts/stm32h743.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
> index bbfcbaca0b36..a559d8b6a4a3 100644
> --- a/arch/arm/boot/dts/stm32h743.dtsi
> +++ b/arch/arm/boot/dts/stm32h743.dtsi
> @@ -304,7 +304,7 @@
> };
> };
>
> - vrefbuf: regulator at 58003C00 {
> + vrefbuf: regulator at 58003c00 {
> compatible = "st,stm32-vrefbuf";
> reg = <0x58003C00 0x8>;
> clocks = <&rcc VREF_CK>;
>
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Philippe Ombredanne @ 2017-12-15 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215114427.32059-1-klaus.goger@theobroma-systems.com>
Klaus,
On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
<klaus.goger@theobroma-systems.com> wrote:
> This patch series replaces all the license text in rockchip devicetree
> files text with a proper SPDX-License-Identifier.
> It follows the guidelines submitted[1] by Thomas Gleixner that are not
> yet merged.
>
> These series also fixes the issue with contradicting statements in most
> licenses. The introduction text claims to be GPL or X11[2] but the
> following verbatim copy of the license is actually a MIT[3] license.
> The X11 license includes a advertise clause and trademark information
> related to the X Consortium. As these X Consortium specfic points are
> irrelevant for us we stick with the actuall license text.
>
> [1] https://patchwork.kernel.org/patch/10091607/
> [2] https://spdx.org/licenses/X11.html
> [3] https://spdx.org/licenses/MIT.html
FWIW, the X11 license name was not always something clearly defined.
SPDX calls it clearly MIT which is the most widely accepted name for
the corresponding text. And this is also what we have in Thomas doc
patches that should be the kernel reference.
Also, as a general note, you want to make sure that such as patch set
is not merged by mistake until you have collected an explicit review
or ack from all the copyright holders involved.
May be calling it an "RFC" could be best until you have these acks?
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] perf probe arm64: Fix symbol fixup issues due to ELF type
From: Arnaldo Carvalho de Melo @ 2017-12-15 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214175242.e30450f17f93ad675d968fa3@arm.com>
Em Thu, Dec 14, 2017 at 05:52:42PM -0600, Kim Phillips escreveu:
> On an arm64 machine running a CONFIG_RANDOMIZE_BASE=y kernel, perf
> kernel symbol resolution fails. Debugging saw symsrc_init calling the
> default elf__needs_adjust_symbols() where checks for an ET_DYN (3)
> ehdr.e_type failed when they should have succeeded.
>
> Fix by adopting powerpc version of the weak elf__needs_adjust_symbols()
> function, as done in commit d2332098331f ("perf probe ppc: Fix symbol
> fixup issues due to ELF type").
>
> Prior to this patch, perf test 1 would fail:
Thanks, applied.
- Arnaldo
^ permalink raw reply
* [PATCH 0/2] KVM: arm/arm64: Fix two problems with the arch timer introduced in v4.15-rc1
From: Christoffer Dall @ 2017-12-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
The first patch solves the problem with the spurious IRQ (which is not a
problem at all and just an artifact of what Jia is writing about), and
it solves the issue of accidentally overwriting the in-memory copy of
the guest state with a disabled timer, leaving the VCPU in the weeds.
The second patch addresses addresses an issue identified when booting
with kvmtool The reason why we didn't see it with QEMU is that QEMU is
so happy to signal its threads in the initial setup phase, that it hides
the bug.
Jia, I'd appreciate your tested-by after having applied both patches on
your platform.
Thanks,
-Christoffer
Christoffer Dall (2):
KVM: arm/arm64: Properly handle arch-timer IRQs after
vtimer_save_state
KVM: arm/arm64: Fix timer enable flow
virt/kvm/arm/arch_timer.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
--
2.14.2
^ permalink raw reply
* [PATCH 1/2] KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state
From: Christoffer Dall @ 2017-12-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-1-christoffer.dall@linaro.org>
The recent timer rework was assuming that once the timer was disabled,
we should no longer see any interrupts from the timer. This assumption
turns out to not be true, and instead we have to handle the case when
the timer ISR runs even after the timer has been disabled.
This requires a couple of changes:
First, we should never overwrite the cached guest state of the timer
control register when the ISR runs, because KVM may have disabled its
timers when doing vcpu_put(), even though the guest still had the timer
enabled.
Second, we shouldn't assume that the timer is actually firing just
because we see an interrupt, but we should check the actual state of the
timer in the timer control register to understand if the hardware timer
is really firing or not.
We also add an ISB to vtimer_save_state() to ensure the timer is
actually disabled once we enable interrupts, which should clarify the
intention of the implementation, and reduce the risk of unwanted
interrupts.
Fixes: b103cc3f10c0 ("KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit")
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Jia He <hejianet@gmail.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index aa9adfafe12b..14c018f990a7 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -92,16 +92,23 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
{
struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
struct arch_timer_context *vtimer;
+ u32 cnt_ctl;
- if (!vcpu) {
- pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
- return IRQ_NONE;
- }
- vtimer = vcpu_vtimer(vcpu);
+ /*
+ * We may see a timer interrupt after vcpu_put() has been called which
+ * sets the CPU's vcpu pointer to NULL, because even though the timer
+ * has been disabled in vtimer_save_state(), the hardware interrupt
+ * signal may not have been retired from the interrupt controller yet.
+ */
+ if (!vcpu)
+ return IRQ_HANDLED;
+ vtimer = vcpu_vtimer(vcpu);
if (!vtimer->irq.level) {
- vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
- if (kvm_timer_irq_can_fire(vtimer))
+ cnt_ctl = read_sysreg_el0(cntv_ctl);
+ cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
+ ARCH_TIMER_CTRL_IT_MASK;
+ if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
kvm_timer_update_irq(vcpu, true, vtimer);
}
@@ -355,6 +362,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
/* Disable the virtual timer */
write_sysreg_el0(0, cntv_ctl);
+ isb();
vtimer->loaded = false;
out:
--
2.14.2
^ permalink raw reply related
* [PATCH 2/2] KVM: arm/arm64: Fix timer enable flow
From: Christoffer Dall @ 2017-12-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-1-christoffer.dall@linaro.org>
When enabling the timer on the first run, we fail to ever restore the
state and mark it as loaded. That means, that in the initial entry to
the VCPU ioctl, unless we exit to userspace for some reason such as a
pending signal, if the guest programs a timer and blocks, we will wait
forever, because we never read back the hardware state (the loaded flag
is not set), and so we think the timer is disabled, and we never
schedule a background soft timer.
The end result? The VCPU blocks forever, and the only solution is to
kill the thread.
Fixes: 4a2c4da1250d ("arm/arm64: KVM: Load the timer state when enabling the timer")
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 14c018f990a7..cc29a8148328 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -846,10 +846,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
no_vgic:
preempt_disable();
timer->enabled = 1;
- if (!irqchip_in_kernel(vcpu->kvm))
- kvm_timer_vcpu_load_user(vcpu);
- else
- kvm_timer_vcpu_load_vgic(vcpu);
+ kvm_timer_vcpu_load(vcpu);
preempt_enable();
return 0;
--
2.14.2
^ permalink raw reply related
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Yixun Lan @ 2017-12-15 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Switch the uart_ao pclk to CLK81 since the clock driver is ready.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
This is a fixup for the previous version
Changes in v8 since [1]
- move clock DT info into soc.dtsi
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005741.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 01beb211f442..d1f8043be426 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -200,7 +201,7 @@
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
- clocks = <&xtal>, <&xtal>, <&xtal>;
+ clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
@@ -209,7 +210,7 @@
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x4000 0x0 0x18>;
interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
- clocks = <&xtal>, <&xtal>, <&xtal>;
+ clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Neil Armstrong @ 2017-12-15 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141741.175985-1-yixun.lan@amlogic.com>
On 15/12/2017 15:17, Yixun Lan wrote:
> Switch the uart_ao pclk to CLK81 since the clock driver is ready.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> ---
> This is a fixup for the previous version
>
> Changes in v8 since [1]
> - move clock DT info into soc.dtsi
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005741.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 01beb211f442..d1f8043be426 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -200,7 +201,7 @@
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
> reg = <0x0 0x3000 0x0 0x18>;
> interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
> - clocks = <&xtal>, <&xtal>, <&xtal>;
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> clock-names = "xtal", "pclk", "baud";
> status = "disabled";
> };
> @@ -209,7 +210,7 @@
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
> reg = <0x0 0x4000 0x0 0x18>;
> interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
> - clocks = <&xtal>, <&xtal>, <&xtal>;
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> clock-names = "xtal", "pclk", "baud";
> status = "disabled";
> };
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH] arch/arm64: elfcorehdr should be the first allocation
From: Poonam Aggrwal @ 2017-12-15 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213104640.GD28046@linaro.org>
Thanks Takahiro and Will,
Please find responses below.
Regards
Poonam
> -----Original Message-----
> From: AKASHI Takahiro [mailto:takahiro.akashi at linaro.org]
> Sent: Wednesday, December 13, 2017 4:17 PM
> To: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Cc: Will Deacon <will.deacon@arm.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; linux-arm-kernel at lists.infradead.org;
> Poonam Aggrwal <poonam.aggrwal@nxp.com>; G.h. Gao
> <guanhua.gao@nxp.com>; james.morse at arm.com
> Subject: Re: [PATCH] arch/arm64: elfcorehdr should be the first allocation
>
> On Mon, Dec 11, 2017 at 02:07:14PM +0000, Will Deacon wrote:
> > On Mon, Dec 11, 2017 at 11:03:32AM +0530, Prabhakar Kushwaha wrote:
> > > From: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > >
> > > elfcorehdr_addr is assigned by kexec-utils and device tree of dump
> > > kernel is fixed in chosen node with parameter "linux,elfcorehdr".
> > > So, memory should be first reserved for elfcorehdr, otherwise
> > > overlaps may happen with other memory allocations which were done
> > > before the allocation of elcorehdr in the crash kernel
> >
> > What happens in that case? Do you have a crash log we can include in
> > the commit message?
>
> In private discussions with Poonam, he said:
> | The overlap here I observed was for the reserved-mem areas in the dtb.
> | And they were specific to NXP device.
Thanks Takahiro for providing this information.
Yes the memory overlap happens because when the dump-capture kernel tries to reserve elfcoreheader at the specific address, it finds that the address has already been reserved for some other use by early_init_fdt_scan_reserved_mem().
Based on the "reserved-memory" node entries in the dts file , the overlap is seen to happen with one of the below alocations:
[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000fb800000, size 4 MiB
[ 0.000000] Reserved memory: initialized node qman-fqd, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000f8000000, size 32 MiB
[ 0.000000] Reserved memory: initialized node qman-pfdr, compatible id shared-dma-pool
>
> Since I have not got any details since then, I'm not sure whether your patch is
> the way to go.
> (I suspect that we might better fix the issue on kexec-tools side.)
>
I may not have full understanding of kexec-tools, but I am not sure how will kexec tools be able to know what addresses will get assigned for the reserved-memory regions in the device tree.
> Thanks,
> -Takahiro AKASHI
>
> > > Signed-off-by: Guanhua <guanhua.gao@nxp.com>
> > > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> > > Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > ---
> >
> > Really? How on Earth did you get three people co-developing this patch?
: )Contribution was from all in terms of reproducing, testing on various platforms including the debug experiments. Just wanted to acknowledge the effort.
> >
> > > arch/arm64/mm/init.c | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index
> > > 5960bef0170d..551048cfcfff 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -453,6 +453,10 @@ void __init arm64_memblock_init(void)
> > > * Register the kernel text, kernel data, initrd, and initial
> > > * pagetables with memblock.
> > > */
> > > +
> > > + /* make this the first reservation so that there are no chances of
> > > + * overlap */
> > > + reserve_elfcorehdr();
> > > memblock_reserve(__pa_symbol(_text), _end - _text); #ifdef
> > > CONFIG_BLK_DEV_INITRD
> > > if (initrd_start) {
> > > @@ -474,8 +478,6 @@ void __init arm64_memblock_init(void)
> > >
> > > reserve_crashkernel();
> > >
> > > - reserve_elfcorehdr();
> >
> > Why isn't this also a problem for reserve_crashkernel() or any other
> > static reservations?
Thanks, for raising this. Yes looking at the code flow this may also cause a problem, definitely when the start address of the crash kernel is specified in the bootargs. We mostly tested with just the size, so it was an allocation without a specific address.
> >
> > Will
^ permalink raw reply
* [PATCH 1/2] KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state
From: Marc Zyngier @ 2017-12-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-2-christoffer.dall@linaro.org>
On Fri, 15 Dec 2017 14:16:55 +0000,
Christoffer Dall wrote:
>
> The recent timer rework was assuming that once the timer was disabled,
> we should no longer see any interrupts from the timer. This assumption
> turns out to not be true, and instead we have to handle the case when
> the timer ISR runs even after the timer has been disabled.
>
> This requires a couple of changes:
>
> First, we should never overwrite the cached guest state of the timer
> control register when the ISR runs, because KVM may have disabled its
> timers when doing vcpu_put(), even though the guest still had the timer
> enabled.
>
> Second, we shouldn't assume that the timer is actually firing just
> because we see an interrupt, but we should check the actual state of the
> timer in the timer control register to understand if the hardware timer
> is really firing or not.
>
> We also add an ISB to vtimer_save_state() to ensure the timer is
> actually disabled once we enable interrupts, which should clarify the
> intention of the implementation, and reduce the risk of unwanted
> interrupts.
>
> Fixes: b103cc3f10c0 ("KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit")
> Reported-by: Marc Zyngier <marc.zyngier@arm.com>
> Reported-by: Jia He <hejianet@gmail.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index aa9adfafe12b..14c018f990a7 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -92,16 +92,23 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> {
> struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
> struct arch_timer_context *vtimer;
> + u32 cnt_ctl;
>
> - if (!vcpu) {
> - pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
> - return IRQ_NONE;
> - }
> - vtimer = vcpu_vtimer(vcpu);
> + /*
> + * We may see a timer interrupt after vcpu_put() has been called which
> + * sets the CPU's vcpu pointer to NULL, because even though the timer
> + * has been disabled in vtimer_save_state(), the hardware interrupt
> + * signal may not have been retired from the interrupt controller yet.
> + */
> + if (!vcpu)
> + return IRQ_HANDLED;
>
> + vtimer = vcpu_vtimer(vcpu);
> if (!vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> + cnt_ctl = read_sysreg_el0(cntv_ctl);
> + cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
> + ARCH_TIMER_CTRL_IT_MASK;
> + if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
> kvm_timer_update_irq(vcpu, true, vtimer);
> }
>
> @@ -355,6 +362,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
> + isb();
>
> vtimer->loaded = false;
> out:
> --
> 2.14.2
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWio0KnJc3DQeQyf-MHpDC=tc3cJLNK7MmaL=MdDz45UQ@mail.gmail.com>
On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin <Dave.Martin@arm.com> wrote:
> > The two important differences here seem to be
> >
> > 1) Staging the state via current->thread.fpsimd_state instead of loading
> > directly:
> >
> > - fpsimd_load_state(state);
> > + current->thread.fpsimd_state = *state;
> > + fpsimd_load_state(¤t->thread.fpsimd_state);
>
> The change above introduces the breakage.
I finally managed to reproduce this, but only by using the exact same
compiler as Geert:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_aarch64-linux.tar.xz
I then reliably see the problem if I run:
# /usr/bin/update-ca-certificates
from Debian Jessie.
Note that my normal toolchain (Linaro 7.1.1 build) works fine and also
if I use the toolchain above but disable CONFIG_ARM64_CRYPTO then things
work too.
So there's some toolchain-specific interaction between this change and the
crypto code...
Will
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stübner @ 2017-12-15 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uHba4kBD81thpxSpDBsDS4Y5m7cN2jfYt_uT5atdSDmqg@mail.gmail.com>
Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
> Klaus,
>
> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>
> <klaus.goger@theobroma-systems.com> wrote:
> > This patch series replaces all the license text in rockchip devicetree
> > files text with a proper SPDX-License-Identifier.
> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> > yet merged.
> >
> > These series also fixes the issue with contradicting statements in most
> > licenses. The introduction text claims to be GPL or X11[2] but the
> > following verbatim copy of the license is actually a MIT[3] license.
> > The X11 license includes a advertise clause and trademark information
> > related to the X Consortium. As these X Consortium specfic points are
> > irrelevant for us we stick with the actuall license text.
> >
> > [1] https://patchwork.kernel.org/patch/10091607/
> > [2] https://spdx.org/licenses/X11.html
> > [3] https://spdx.org/licenses/MIT.html
>
> FWIW, the X11 license name was not always something clearly defined.
> SPDX calls it clearly MIT which is the most widely accepted name for
> the corresponding text. And this is also what we have in Thomas doc
> patches that should be the kernel reference.
>
> Also, as a general note, you want to make sure that such as patch set
> is not merged by mistake until you have collected an explicit review
> or ack from all the copyright holders involved.
Just for my understanding, is it really necessary to get Acks from _all_
previous contributors?
I see that Thomas patches moving license texts into the kernel itself do not
seem to have landed yet, but when the actual license text does _not_ change
and only its location to a common place inside the kernel sources, it feels
a bit overkill trying to get Acks from _everybody_ that contributed to
Rockchip devicetrees for the last 4 years.
If we would actually want to change the license I would definitly feel
differently, but the license text does not change.
Thanks
Heiko
^ permalink raw reply
* [PATCH 2/2] KVM: arm/arm64: Fix timer enable flow
From: Marc Zyngier @ 2017-12-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-3-christoffer.dall@linaro.org>
On Fri, 15 Dec 2017 14:16:56 +0000,
Christoffer Dall wrote:
>
> When enabling the timer on the first run, we fail to ever restore the
> state and mark it as loaded. That means, that in the initial entry to
> the VCPU ioctl, unless we exit to userspace for some reason such as a
> pending signal, if the guest programs a timer and blocks, we will wait
> forever, because we never read back the hardware state (the loaded flag
> is not set), and so we think the timer is disabled, and we never
> schedule a background soft timer.
>
> The end result? The VCPU blocks forever, and the only solution is to
> kill the thread.
>
> Fixes: 4a2c4da1250d ("arm/arm64: KVM: Load the timer state when enabling the timer")
> Reported-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 14c018f990a7..cc29a8148328 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -846,10 +846,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> no_vgic:
> preempt_disable();
> timer->enabled = 1;
> - if (!irqchip_in_kernel(vcpu->kvm))
> - kvm_timer_vcpu_load_user(vcpu);
> - else
> - kvm_timer_vcpu_load_vgic(vcpu);
> + kvm_timer_vcpu_load(vcpu);
> preempt_enable();
>
> return 0;
> --
> 2.14.2
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ 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