Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 1/8] dt-bindings: timer: Convert Exynos MCT bindings to json-schema
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki

Convert Samsung Exynos Soc Multi Core Timer bindings to DT schema format
using json-schema.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Changes since v3:
1. Use interrupts-extended instead of interrupts-map.

Changes since v1:
1. Indent example with four spaces (more readable),
2. Rename nodes in example to timer,
3. Remove mct-map subnode.
---
 .../bindings/timer/samsung,exynos4210-mct.txt |  88 ------------
 .../timer/samsung,exynos4210-mct.yaml         | 125 ++++++++++++++++++
 2 files changed, 125 insertions(+), 88 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
 create mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml

diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
deleted file mode 100644
index 8f78640ad64c..000000000000
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Samsung's Multi Core Timer (MCT)
-
-The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
-global timer and CPU local timers. The global timer is a 64-bit free running
-up-counter and can generate 4 interrupts when the counter reaches one of the
-four preset counter values. The CPU local timers are 32-bit free running
-down-counters and generate an interrupt when the counter expires. There is
-one CPU local timer instantiated in MCT for every CPU in the system.
-
-Required properties:
-
-- compatible: should be "samsung,exynos4210-mct".
-  (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
-  (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
-
-- reg: base address of the mct controller and length of the address space
-  it occupies.
-
-- interrupts: the list of interrupts generated by the controller. The following
-  should be the order of the interrupts specified. The local timer interrupts
-  should be specified after the four global timer interrupts have been
-  specified.
-
-	0: Global Timer Interrupt 0
-	1: Global Timer Interrupt 1
-	2: Global Timer Interrupt 2
-	3: Global Timer Interrupt 3
-	4: Local Timer Interrupt 0
-	5: Local Timer Interrupt 1
-	6: ..
-	7: ..
-	i: Local Timer Interrupt n
-
-  For MCT block that uses a per-processor interrupt for local timers, such
-  as ones compatible with "samsung,exynos4412-mct", only one local timer
-  interrupt might be specified, meaning that all local timers use the same
-  per processor interrupt.
-
-Example 1: In this example, the IP contains two local timers, using separate
-	   interrupts, so two local timer interrupts have been specified,
-	   in addition to four global timer interrupts.
-
-	mct@10050000 {
-		compatible = "samsung,exynos4210-mct";
-		reg = <0x10050000 0x800>;
-		interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-			     <0 42 0>, <0 48 0>;
-	};
-
-Example 2: In this example, the timer interrupts are connected to two separate
-	   interrupt controllers. Hence, an interrupt-map is created to map
-	   the interrupts to the respective interrupt controllers.
-
-	mct@101c0000 {
-		compatible = "samsung,exynos4210-mct";
-		reg = <0x101C0000 0x800>;
-		interrupt-parent = <&mct_map>;
-		interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
-
-		mct_map: mct-map {
-			#interrupt-cells = <1>;
-			#address-cells = <0>;
-			#size-cells = <0>;
-			interrupt-map = <0 &gic 0 57 0>,
-					<1 &gic 0 69 0>,
-					<2 &combiner 12 6>,
-					<3 &combiner 12 7>,
-					<4 &gic 0 42 0>,
-					<5 &gic 0 48 0>;
-		};
-	};
-
-Example 3: In this example, the IP contains four local timers, but using
-	   a per-processor interrupt to handle them. Either all the local
-	   timer interrupts can be specified, with the same interrupt specifier
-	   value or just the first one.
-
-	mct@10050000 {
-		compatible = "samsung,exynos4412-mct";
-		reg = <0x10050000 0x800>;
-
-		/* Both ways are possible in this case. Either: */
-		interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-			     <0 42 0>;
-		/* or: */
-		interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-			     <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
-	};
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
new file mode 100644
index 000000000000..bff3f54a398f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/samsung,exynos4210-mct.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC Multi Core Timer (MCT)
+
+maintainers:
+  - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |+
+  The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
+  global timer and CPU local timers. The global timer is a 64-bit free running
+  up-counter and can generate 4 interrupts when the counter reaches one of the
+  four preset counter values. The CPU local timers are 32-bit free running
+  down-counters and generate an interrupt when the counter expires. There is
+  one CPU local timer instantiated in MCT for every CPU in the system.
+
+properties:
+  compatible:
+    enum:
+      - samsung,exynos4210-mct
+      - samsung,exynos4412-mct
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    description: |
+      Interrupts should be put in specific order. This is, the local timer
+      interrupts should be specified after the four global timer interrupts
+      have been specified:
+      0: Global Timer Interrupt 0
+      1: Global Timer Interrupt 1
+      2: Global Timer Interrupt 2
+      3: Global Timer Interrupt 3
+      4: Local Timer Interrupt 0
+      5: Local Timer Interrupt 1
+      6: ..
+      7: ..
+      i: Local Timer Interrupt n
+      For MCT block that uses a per-processor interrupt for local timers, such
+      as ones compatible with "samsung,exynos4412-mct", only one local timer
+      interrupt might be specified, meaning that all local timers use the same
+      per processor interrupt.
+    minItems: 5               # 4 Global + 1 local
+    maxItems: 20              # 4 Global + 16 local
+
+  interrupts-extended:
+    description: |
+      If interrupts are coming from different controllers, this property
+      can be used instead of regular "interrupts" property.
+      The format is exactly the same as with "interrupts".
+      Interrupts should be put in specific order. This is, the local timer
+    minItems: 5               # 4 Global + 1 local
+    maxItems: 20              # 4 Global + 16 local
+
+required:
+  - compatible
+  - interrupts
+  - reg
+
+allOf:
+  - if:
+      not:
+        required:
+          - interrupts
+    then:
+      required:
+        - interrupts-extended
+
+examples:
+  - |
+    // In this example, the IP contains two local timers, using separate
+    // interrupts, so two local timer interrupts have been specified,
+    // in addition to four global timer interrupts.
+
+    timer@10050000 {
+        compatible = "samsung,exynos4210-mct";
+        reg = <0x10050000 0x800>;
+        interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
+                     <0 42 0>, <0 48 0>;
+    };
+
+  - |
+    // In this example, the timer interrupts are connected to two separate
+    // interrupt controllers. Hence, an interrupts-extended is needed.
+
+    timer@101c0000 {
+        compatible = "samsung,exynos4210-mct";
+        reg = <0x101C0000 0x800>;
+        interrupts-extended = <&gic 0 57 0>,
+                              <&gic 0 69 0>,
+                              <&combiner 12 6>,
+                              <&combiner 12 7>,
+                              <&gic 0 42 0>,
+                              <&gic 0 48 0>;
+    };
+
+  - |
+    // In this example, the IP contains four local timers, but using
+    // a per-processor interrupt to handle them. Only one first local
+    // interrupt is specified.
+
+    timer@10050000 {
+        compatible = "samsung,exynos4412-mct";
+        reg = <0x10050000 0x800>;
+
+        interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
+                     <0 42 0>;
+    };
+
+  - |
+    // In this example, the IP contains four local timers, but using
+    // a per-processor interrupt to handle them. All the local timer
+    // interrupts are specified.
+
+    timer@10050000 {
+        compatible = "samsung,exynos4412-mct";
+        reg = <0x10050000 0x800>;
+
+        interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
+                     <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
+    };
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 2/8] ARM: dts: exynos: Rename Multi Core Timer node to "timer"
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer".  This will be also in
sync with upcoming DT schema.  No functional change.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 arch/arm/boot/dts/exynos3250.dtsi | 2 +-
 arch/arm/boot/dts/exynos4210.dtsi | 2 +-
 arch/arm/boot/dts/exynos4412.dtsi | 2 +-
 arch/arm/boot/dts/exynos5250.dtsi | 2 +-
 arch/arm/boot/dts/exynos5260.dtsi | 2 +-
 arch/arm/boot/dts/exynos54xx.dtsi | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 784818490376..d122fb52d3d4 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -265,7 +265,7 @@
 					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
 
-		mct@10050000 {
+		timer@10050000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x10050000 0x800>;
 			interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index f220716239db..6d3f19562aab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -106,7 +106,7 @@
 			arm,data-latency = <2 2 1>;
 		};
 
-		mct: mct@10050000 {
+		mct: timer@10050000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x10050000 0x800>;
 			interrupt-parent = <&mct_map>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index d20db2dfe8e2..8b6d5875c75d 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -243,7 +243,7 @@
 			clock-names = "aclk200", "aclk400_mcuisp";
 		};
 
-		mct@10050000 {
+		timer@10050000 {
 			compatible = "samsung,exynos4412-mct";
 			reg = <0x10050000 0x800>;
 			interrupt-parent = <&mct_map>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index fc966c10cf49..7a01349317a3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -233,7 +233,7 @@
 			power-domains = <&pd_mau>;
 		};
 
-		mct@101c0000 {
+		timer@101c0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101C0000 0x800>;
 			interrupt-controller;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 3581b57fbbf7..b0811dbbb362 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -180,7 +180,7 @@
 			reg = <0x10000000 0x100>;
 		};
 
-		mct: mct@100b0000 {
+		mct: timer@100b0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x100B0000 0x1000>;
 			clocks = <&fin_pll>, <&clock_peri PERI_CLK_MCT>;
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index 9c3b63b7cac6..247d23872384 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -64,7 +64,7 @@
 			};
 		};
 
-		mct: mct@101c0000 {
+		mct: timer@101c0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101c0000 0xb00>;
 			interrupt-parent = <&mct_map>;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 3/8] arm64: dts: exynos: Rename Multi Core Timer node to "timer"
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer".  This will be also in
sync with upcoming DT schema.  No functional change.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index a76f620f7f35..8baf3c645eae 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -754,7 +754,7 @@
 			status = "disabled";
 		};
 
-		mct@101c0000 {
+		timer@101c0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101c0000 0x800>;
 			interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [RFT v4 4/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4210
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner.  This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Not tested.

Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
 arch/arm/boot/dts/exynos4210.dtsi | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 6d3f19562aab..5fa33d43821e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -109,23 +109,14 @@
 		mct: timer@10050000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x10050000 0x800>;
-			interrupt-parent = <&mct_map>;
-			interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
 			clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
 			clock-names = "fin_pll", "mct";
-
-			mct_map: mct-map {
-				#interrupt-cells = <1>;
-				#address-cells = <0>;
-				#size-cells = <0>;
-				interrupt-map =
-					<0 &gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
-					<1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
-					<2 &combiner 12 6>,
-					<3 &combiner 12 7>,
-					<4 &gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
-					<5 &gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
-			};
+			interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
+					      <&combiner 12 6>,
+					      <&combiner 12 7>,
+					      <&gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		watchdog: watchdog@10060000 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
From: Russell King - ARM Linux admin @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Yu Chen; +Cc: yu.chen3, linux-kernel, linux-arm-kernel
In-Reply-To: <1569253374-3631-1-git-send-email-33988979@163.com>

On Mon, Sep 23, 2019 at 11:42:54PM +0800, Yu Chen wrote:
> From: Yu Chen <yu.chen3@zte.com.cn>
> 
> On Sat, 21 Sep 2019 15:51:38, Russell King - ARM Linux admin wrote:
> > On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote:
> > > From: Yu Chen <yu.chen3@zte.com.cn> 
> > >  
> > > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
> > > user-space doesn't know about memblock_reserve()d regions and thus
> > > possible for kexec to overwrite with the new kernel or initrd.
> > 
> > Many reserved regions come from the kernel allocating memory during
> > boot.  We don't want to prevent kexec re-using those regions.
> > 
> > > [    0.000000] Booting Linux on physical CPU 0xf00
> > > [    0.000000] Linux version 4.9.115-rt93-dirty (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2
> > > 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
> > > [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> > > [    0.000000] CPU: div instructions available: patching division code
> > > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > > [    0.000000] OF: fdt:Machine model: LS1021A TWR Board
> > > [    0.000000] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - disabling initrd
> > 
> > Is the overlapping region one that is marked as reserved in DT?
> 
> the overlapping region is not reserved in DT.
> 
> > Where is the reserved region that overlaps the initrd coming from?
> 
> I found the reserved region that overlaps the initrd is kernel code & data, 
> with memblock=debug cmdline start new kerne:
> 
> / # kexec -l uImage-ls1021a --ramdisk=ramdisk-ls1021a --dtb=fdt --append="root=/
> dev/ram0 rw console=ttyS0,115200 earlyprintk memblock=debug" -d
> Try gzip decompression.
> Try LZMA decompression.
> lzma_decompress_file: read on uImage-ls1021a of 65536 bytes failed
> kernel: 0xb6c71008 kernel_size: 0x317ab8
> MEMORY RANGES
> 0000000080000000-00000000bfffffff (0)
> 0000000080003000-0000000080007fff (1)
> 0000000080e00000-0000000080ffffff (1)
> 00000000810c45a4-00000000810c4fff (1)
> 0000000081ac4000-0000000085159fff (1)
> 000000008515a000-000000008515ffff (1)
> 0000000088000000-000000008b695fff (1)
> 000000008f000000-000000008f004fff (1)
> 00000000af709000-00000000af7eafff (1)
> 00000000af7ed000-00000000afffbfff (1)
> 00000000afffc000-00000000afffcfff (1)
> 00000000afffd000-00000000afffffff (1)
> 00000000bc000000-00000000bfffffff (1)
> zImage header: 0x016f2818 0x00000000 0x00317a78
> zImage size 0x317a78, file size 0x317a78

I see nothing here that suggests either a new kexec or a sufficiently
new kernel.  Hence, kexec lacks all the information to correctly layout
the images in physical memory.

The kernel was augmented with additional information around the
v4.15 time.  See commits:

c772568788b5 ARM: add additional table to compressed kernel
429f7a062e3b ARM: decompressor: fix BSS size calculation
99cf8f903148 ARM: better diagnostics with missing/corrupt dtb

There may be some others also needed, but I forget now, it was two
years ago.

For kexec, you need at least 2.0.17 (2.0.16 merged the wrong version
of one of my patches.)

> kexec_load: entry = 0x80008000 flags = 0x280000
> nr_segments = 3
> segment[0].buf   = 0xb6c71048
> segment[0].bufsz = 0x317a78
> segment[0].mem   = 0x80008000
> segment[0].memsz = 0x318000
> segment[1].buf   = 0xb35db048
> segment[1].bufsz = 0x3695e40
> segment[1].mem   = 0x80f7f000
> segment[1].memsz = 0x3696000
> segment[2].buf   = 0x100b108
> segment[2].bufsz = 0x5090
> segment[2].mem   = 0x84615000
> segment[2].memsz = 0x6000
> / # kexec -e
> [  126.583598] kexec_core: Starting new kernel
> [  126.587815] Disabling non-boot CPUs ...
> [  126.626917] CPU1: shutdown
> [  126.656344] Retrying again to check for CPU kill
> [  126.660947] CPU1 killed.
> [  126.687585] Bye!
> [    0.000000] Booting Linux on physical CPU 0xf00
> [    0.000000] Linux version 4.9.115-rt93-CGEL-V6.02.10.R4-dirty (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.20) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
> [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] OF: fdt:Machine model: LS1021A TWR Board
> [    0.000000] memblock_reserve: [0x00000080200000-0x000000810c45a3] flags 0x0 arm_memblock_init+0x44/0x23c
> [    0.000000] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - disabling initrd
> [    0.000000] memblock_reserve: [0x00000080003000-0x00000080007fff] flags 0x0 arm_mm_memblock_reserve+0x2c/0x30
> [    0.000000] memblock_reserve: [0x00000084615000-0x0000008461a08f] flags 0x0 early_init_dt_reserve_memory_arch+0x24/0x28
> [    0.000000] memblock_reserve: [0x0000008f000000-0x0000008f004fff] flags 0x0 early_init_dt_reserve_memory_arch+0x24/0x28
> [    0.000000] memblock_reserve: [0x00000088000040-0x0000008b695e3f] flags 0x0 early_init_dt_reserve_memory_arch+0x24/0x28
> [    0.000000] memblock_reserve: [0x000000bc000000-0x000000bfffffff] flags 0x0 memblock_alloc_range_nid+0x78/0x90
>  ... 
>  ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> 
> this overlay region is [0x00000080200000-0x000000810c45a3]
> 
> Corresponding kernel source code:
> 264 void __init arm_memblock_init(const struct machine_desc *mdesc)
> 265 {
> 266         /* Register the kernel text, kernel data and initrd with memblock. */
> 267         memblock_reserve(__pa(KERNEL_START), KERNEL_END - KERNEL_START);
> 
> > 
> > Thanks.
> > 
> > --  
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > According to speedtest.net: 11.9Mbps down 500kbps up
> 
> And Sorry, I sent the wrong arm64 patch. if possible, I will resend the second version of the patch.
> 
> Yu Chen
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [RFT v4 5/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4412
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner.  This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.

Tested on Odroid U3 (Exynos4412).

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
 arch/arm/boot/dts/exynos4412.dtsi | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 8b6d5875c75d..9b5fb4e54d7c 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -246,22 +246,13 @@
 		timer@10050000 {
 			compatible = "samsung,exynos4412-mct";
 			reg = <0x10050000 0x800>;
-			interrupt-parent = <&mct_map>;
-			interrupts = <0>, <1>, <2>, <3>, <4>;
 			clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
 			clock-names = "fin_pll", "mct";
-
-			mct_map: mct-map {
-				#interrupt-cells = <1>;
-				#address-cells = <0>;
-				#size-cells = <0>;
-				interrupt-map =
-					<0 &gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
-					<1 &combiner 12 5>,
-					<2 &combiner 12 6>,
-					<3 &combiner 12 7>,
-					<4 &gic 1 12 IRQ_TYPE_LEVEL_HIGH>;
-			};
+			interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
+					      <&combiner 12 5>,
+					      <&combiner 12 6>,
+					      <&combiner 12 7>,
+					      <&gic 1 12 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		watchdog: watchdog@10060000 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [RFT v4 6/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos5250
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner.  This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Not tested.

Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
 arch/arm/boot/dts/exynos5250.dtsi | 23 ++++++-----------------
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 7a01349317a3..a549eafd2c64 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -236,25 +236,14 @@
 		timer@101c0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101C0000 0x800>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-			interrupt-parent = <&mct_map>;
-			interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
-				     <4 0>, <5 0>;
 			clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
 			clock-names = "fin_pll", "mct";
-
-			mct_map: mct-map {
-				#interrupt-cells = <2>;
-				#address-cells = <0>;
-				#size-cells = <0>;
-				interrupt-map = <0x0 0 &combiner 23 3>,
-						<0x1 0 &combiner 23 4>,
-						<0x2 0 &combiner 25 2>,
-						<0x3 0 &combiner 25 3>,
-						<0x4 0 &gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
-						<0x5 0 &gic 0 121 IRQ_TYPE_LEVEL_HIGH>;
-			};
+			interrupts-extended = <&combiner 23 3>,
+					      <&combiner 23 4>,
+					      <&combiner 25 2>,
+					      <&combiner 25 3>,
+					      <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		pinctrl_0: pinctrl@11400000 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 7/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos54xx
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner.  This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.

Tested on Odroid XU (Exynos5410), Odroid HC1 (Exynos5422) and Arndale
Octa (Exynos5420).

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
 arch/arm/boot/dts/exynos54xx.dtsi | 33 +++++++++++--------------------
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index 247d23872384..aca1b4831e38 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -67,27 +67,18 @@
 		mct: timer@101c0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101c0000 0xb00>;
-			interrupt-parent = <&mct_map>;
-			interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>,
-					<8>, <9>, <10>, <11>;
-
-			mct_map: mct-map {
-				#interrupt-cells = <1>;
-				#address-cells = <0>;
-				#size-cells = <0>;
-				interrupt-map = <0 &combiner 23 3>,
-						<1 &combiner 23 4>,
-						<2 &combiner 25 2>,
-						<3 &combiner 25 3>,
-						<4 &gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
-						<5 &gic 0 121 IRQ_TYPE_LEVEL_HIGH>,
-						<6 &gic 0 122 IRQ_TYPE_LEVEL_HIGH>,
-						<7 &gic 0 123 IRQ_TYPE_LEVEL_HIGH>,
-						<8 &gic 0 128 IRQ_TYPE_LEVEL_HIGH>,
-						<9 &gic 0 129 IRQ_TYPE_LEVEL_HIGH>,
-						<10 &gic 0 130 IRQ_TYPE_LEVEL_HIGH>,
-						<11 &gic 0 131 IRQ_TYPE_LEVEL_HIGH>;
-			};
+			interrupts-extended = <&combiner 23 3>,
+					      <&combiner 23 4>,
+					      <&combiner 25 2>,
+					      <&combiner 25 3>,
+					      <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 122 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 123 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 128 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 129 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 130 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic 0 131 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		watchdog: watchdog@101d0000 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 8/8] ARM: dts: exynos: Use defines for MCT interrupt GIC SPI/PPI specifier
From: Krzysztof Kozlowski @ 2019-09-23 16:14 UTC (permalink / raw)
  To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
	Kukjin Kim, Krzysztof Kozlowski, Marek Szyprowski, Andrzej Hajda,
	linux-kernel, devicetree, linux-arm-kernel, linux-samsung-soc
  Cc: Sylwester Nawrocki
In-Reply-To: <20190923161411.9236-1-krzk@kernel.org>

Replace hard-coded number with appropriate define for GIC SPI or PPI
specifier in interrupt.  This makes code easier to read.  No expected
functionality change.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
 arch/arm/boot/dts/exynos4210.dtsi |  8 ++++----
 arch/arm/boot/dts/exynos4412.dtsi |  4 ++--
 arch/arm/boot/dts/exynos5250.dtsi |  4 ++--
 arch/arm/boot/dts/exynos54xx.dtsi | 16 ++++++++--------
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 5fa33d43821e..aac3b7a20a37 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -111,12 +111,12 @@
 			reg = <0x10050000 0x800>;
 			clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
 			clock-names = "fin_pll", "mct";
-			interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
+			interrupts-extended = <&gic GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
 					      <&combiner 12 6>,
 					      <&combiner 12 7>,
-					      <&gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
+					      <&gic GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		watchdog: watchdog@10060000 {
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 9b5fb4e54d7c..96a5ef3a2864 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -248,11 +248,11 @@
 			reg = <0x10050000 0x800>;
 			clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
 			clock-names = "fin_pll", "mct";
-			interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
+			interrupts-extended = <&gic GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
 					      <&combiner 12 5>,
 					      <&combiner 12 6>,
 					      <&combiner 12 7>,
-					      <&gic 1 12 IRQ_TYPE_LEVEL_HIGH>;
+					      <&gic GIC_PPI 12 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		watchdog: watchdog@10060000 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index a549eafd2c64..f01e3156191d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -242,8 +242,8 @@
 					      <&combiner 23 4>,
 					      <&combiner 25 2>,
 					      <&combiner 25 3>,
-					      <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>;
+					      <&gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		pinctrl_0: pinctrl@11400000 {
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index aca1b4831e38..06ae40a2f1e9 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -71,14 +71,14 @@
 					      <&combiner 23 4>,
 					      <&combiner 25 2>,
 					      <&combiner 25 3>,
-					      <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 122 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 123 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 128 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 129 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 130 IRQ_TYPE_LEVEL_HIGH>,
-					      <&gic 0 131 IRQ_TYPE_LEVEL_HIGH>;
+					      <&gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+					      <&gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
 		watchdog: watchdog@101d0000 {
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v8 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
From: Catalin Marinas @ 2019-09-23 16:18 UTC (permalink / raw)
  To: Jia He
  Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
	Suzuki Poulose, Marc Zyngier, Anshuman Khandual, linux-kernel,
	Matthew Wilcox, linux-mm, Jérôme Glisse, James Morse,
	linux-arm-kernel, Punit Agrawal, hejianet, Thomas Gleixner, nd,
	Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190921135054.142360-3-justin.he@arm.com>

On Sat, Sep 21, 2019 at 09:50:53PM +0800, Jia He wrote:
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e09760ece844..4a9939615e41 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>  #define phys_to_ttbr(addr)	(addr)
>  #endif
>  
> +/*
> + * On arm64 without hardware Access Flag, copying fromuser will fail because
                                                     ^^^^^^^^
						     from user

> + * the pte is old and cannot be marked young. So we always end up with zeroed
> + * page after fork() + CoW for pfn mappings. we don't always have a
                                                ^^
						We

> + * hardware-managed access flag on arm64.
> + */
> +static inline bool arch_faults_on_old_pte(void)
> +{
> +	return !cpu_has_hw_af();

I saw an early incarnation of your patch having a
WARN_ON(preemptible()). I think we need this back just in case this
function will be used elsewhere in the future.

> +}
> +#define arch_faults_on_old_pte arch_faults_on_old_pte

Otherwise,

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 3/5] drm/imx: Add initial support for DCSS on iMX8MQ
From: kbuild test robot @ 2019-09-23 16:24 UTC (permalink / raw)
  To: Laurentiu Palcu
  Cc: Laurentiu Palcu, Philipp Zabel, Shawn Guo, Sascha Hauer,
	linux-kernel, dri-devel, kbuild-all, Pengutronix Kernel Team,
	l.stach, Fabio Estevam, agx, linux-arm-kernel, NXP Linux Team
In-Reply-To: <1569248002-2485-4-git-send-email-laurentiu.palcu@nxp.com>

[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]

Hi Laurentiu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Laurentiu-Palcu/Add-support-for-iMX8MQ-Display-Controller-Subsystem/20190923-230115
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=c6x 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/gpu/drm/imx/dcss/dcss-blkctl.c: In function 'dcss_blkctl_init':
>> drivers/gpu/drm/imx/dcss/dcss-blkctl.c:50:58: error: 'SZ_4K' undeclared (first use in this function)
     blkctl->base_reg = devm_ioremap(dcss->dev, blkctl_base, SZ_4K);
                                                             ^~~~~
   drivers/gpu/drm/imx/dcss/dcss-blkctl.c:50:58: note: each undeclared identifier is reported only once for each function it appears in
--
   drivers/gpu/drm/imx/dcss/dcss-dtg.c: In function 'dcss_dtg_init':
>> drivers/gpu/drm/imx/dcss/dcss-dtg.c:174:52: error: 'SZ_4K' undeclared (first use in this function)
     dtg->base_reg = devm_ioremap(dcss->dev, dtg_base, SZ_4K);
                                                       ^~~~~
   drivers/gpu/drm/imx/dcss/dcss-dtg.c:174:52: note: each undeclared identifier is reported only once for each function it appears in
--
   drivers/gpu/drm/imx/dcss/dcss-ss.c: In function 'dcss_ss_init':
>> drivers/gpu/drm/imx/dcss/dcss-ss.c:93:50: error: 'SZ_4K' undeclared (first use in this function)
     ss->base_reg = devm_ioremap(dcss->dev, ss_base, SZ_4K);
                                                     ^~~~~
   drivers/gpu/drm/imx/dcss/dcss-ss.c:93:50: note: each undeclared identifier is reported only once for each function it appears in
--
   drivers/gpu/drm/imx/dcss/dcss-dpr.c: In function 'dcss_dpr_ch_init_all':
>> drivers/gpu/drm/imx/dcss/dcss-dpr.c:125:55: error: 'SZ_4K' undeclared (first use in this function)
      ch->base_reg = devm_ioremap(dpr->dev, ch->base_ofs, SZ_4K);
                                                          ^~~~~
   drivers/gpu/drm/imx/dcss/dcss-dpr.c:125:55: note: each undeclared identifier is reported only once for each function it appears in
--
   drivers/gpu/drm/imx/dcss/dcss-scaler.c: In function 'dcss_scaler_ch_init_all':
>> drivers/gpu/drm/imx/dcss/dcss-scaler.c:287:55: error: 'SZ_4K' undeclared (first use in this function)
      ch->base_reg = devm_ioremap(scl->dev, ch->base_ofs, SZ_4K);
                                                          ^~~~~
   drivers/gpu/drm/imx/dcss/dcss-scaler.c:287:55: note: each undeclared identifier is reported only once for each function it appears in

vim +/SZ_4K +50 drivers/gpu/drm/imx/dcss/dcss-blkctl.c

    41	
    42	int dcss_blkctl_init(struct dcss_dev *dcss, unsigned long blkctl_base)
    43	{
    44		struct dcss_blkctl *blkctl;
    45	
    46		blkctl = devm_kzalloc(dcss->dev, sizeof(*blkctl), GFP_KERNEL);
    47		if (!blkctl)
    48			return -ENOMEM;
    49	
  > 50		blkctl->base_reg = devm_ioremap(dcss->dev, blkctl_base, SZ_4K);
    51		if (!blkctl->base_reg) {
    52			dev_err(dcss->dev, "unable to remap BLK CTRL base\n");
    53			devm_kfree(dcss->dev, blkctl);
    54			return -ENOMEM;
    55		}
    56	
    57		dcss->blkctl = blkctl;
    58		blkctl->dev = dcss->dev;
    59		blkctl->hdmi_output = dcss->hdmi_output;
    60	
    61		dcss_blkctl_cfg(blkctl);
    62	
    63		return 0;
    64	}
    65	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50075 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] PM / devfreq: Lock devfreq in trans_stat_show
From: Leonard Crestez @ 2019-09-23 16:27 UTC (permalink / raw)
  To: Matthias Kaehlcke, MyungJoo Ham, Kyungmin Park
  Cc: Artur Świgoń, linux-pm, Krzysztof Kozlowski,
	Lukasz Luba, Chanwoo Choi, NXP Linux Team, Georgi Djakov,
	linux-arm-kernel

There is no locking in this sysfs show function so stats printing can
race with a devfreq_update_status called as part of freq switching or
with initialization.

Also add an assert in devfreq_update_status to make it clear that lock
must be held by caller.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/devfreq/devfreq.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

Changes since v1:
* Split from series: low-priority bugfix not strictly required for PM QoS
* Only keep lock during update, release before sprintf
Link to v1: https://patchwork.kernel.org/patch/11149493/

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 4c58fbf7d4e4..00fc23fea5b2 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -206,10 +206,11 @@ int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
 {
 	int lev, prev_lev, ret = 0;
 	unsigned long cur_time;
 
 	cur_time = jiffies;
+	lockdep_assert_held(&devfreq->lock);
 
 	/* Immediately exit if previous_freq is not initialized yet. */
 	if (!devfreq->previous_freq)
 		goto out;
 
@@ -1507,16 +1508,22 @@ static ssize_t trans_stat_show(struct device *dev,
 	struct devfreq *devfreq = to_devfreq(dev);
 	ssize_t len;
 	int i, j;
 	unsigned int max_state = devfreq->profile->max_state;
 
-	if (!devfreq->stop_polling &&
-			devfreq_update_status(devfreq, devfreq->previous_freq))
-		return 0;
 	if (max_state == 0)
 		return sprintf(buf, "Not Supported.\n");
 
+	/* lock and update */
+	mutex_lock(&devfreq->lock);
+	if (!devfreq->stop_polling &&
+			devfreq_update_status(devfreq, devfreq->previous_freq)) {
+		mutex_unlock(&devfreq->lock);
+		return 0;
+	}
+	mutex_unlock(&devfreq->lock);
+
 	len = sprintf(buf, "     From  :   To\n");
 	len += sprintf(buf + len, "           :");
 	for (i = 0; i < max_state; i++)
 		len += sprintf(buf + len, "%10lu",
 				devfreq->profile->freq_table[i]);
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH] PM / devfreq: Check NULL governor in available_governors_show
From: Leonard Crestez @ 2019-09-23 16:34 UTC (permalink / raw)
  To: Matthias Kaehlcke, MyungJoo Ham, Kyungmin Park
  Cc: Artur Świgoń, linux-pm, Krzysztof Kozlowski,
	Lukasz Luba, Chanwoo Choi, linux-arm-kernel

The governor is initialized after sysfs attributes become visible so in
theory the governor field can be NULL here.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/devfreq/devfreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Found this by hacking device core to call attribute "show" functions
from inside device_add.

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 00fc23fea5b2..896fb2312f2f 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1322,11 +1322,11 @@ static ssize_t available_governors_show(struct device *d,
 
 	/*
 	 * The devfreq with immutable governor (e.g., passive) shows
 	 * only own governor.
 	 */
-	if (df->governor->immutable) {
+	if (df->governor && df->governor->immutable) {
 		count = scnprintf(&buf[count], DEVFREQ_NAME_LEN,
 				  "%s ", df->governor_name);
 	/*
 	 * The devfreq device shows the registered governor except for
 	 * immutable governors such as passive governor .
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v10 3/6] mm: Introduce Reported pages
From: Alexander Duyck @ 2019-09-23 16:39 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
	Michal Hocko, linux-mm, Alexander Duyck, Andrea Arcangeli,
	virtio-dev, Konrad Rzeszutek Wilk, Matthew Wilcox, Wang, Wei W,
	Vlastimil Babka, Rik van Riel, Dan Williams, lcapitulino,
	linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
	LKML, Paolo Bonzini, Andrew Morton, Mel Gorman
In-Reply-To: <baf3dd5c-9368-d621-a83a-114bb5ae8291@redhat.com>

On Mon, Sep 23, 2019 at 8:46 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 23.09.19 17:37, Michael S. Tsirkin wrote:
> > On Mon, Sep 23, 2019 at 08:28:00AM -0700, Alexander Duyck wrote:
> >> On Mon, Sep 23, 2019 at 8:00 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>
> >>> On Mon, Sep 23, 2019 at 07:50:15AM -0700, Alexander Duyck wrote:
> >>>>>> +static inline void
> >>>>>> +page_reporting_reset_boundary(struct zone *zone, unsigned int order, int mt)
> >>>>>> +{
> >>>>>> +     int index;
> >>>>>> +
> >>>>>> +     if (order < PAGE_REPORTING_MIN_ORDER)
> >>>>>> +             return;
> >>>>>> +     if (!test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> >>>>>> +             return;
> >>>>>> +
> >>>>>> +     index = get_reporting_index(order, mt);
> >>>>>> +     reported_boundary[index] = &zone->free_area[order].free_list[mt];
> >>>>>> +}
> >>>>>
> >>>>> So this seems to be costly.
> >>>>> I'm guessing it's the access to flags:
> >>>>>
> >>>>>
> >>>>>         /* zone flags, see below */
> >>>>>         unsigned long           flags;
> >>>>>
> >>>>>         /* Primarily protects free_area */
> >>>>>         spinlock_t              lock;
> >>>>>
> >>>>>
> >>>>>
> >>>>> which is in the same cache line as the lock.
> >>>>
> >>>> I'm not sure what you mean by this being costly?
> >>>
> >>> I've just been wondering why does will it scale report a 1.5% regression
> >>> with this patch.
> >>
> >> Are you talking about data you have collected from a test you have
> >> run, or the data I have run?
> >
> > About the kernel test robot auto report that was sent recently.
>
> https://lkml.org/lkml/2019/9/21/112
>
> And if I'm correct, that regression is observable in case reporting is
> not enabled. (so with this patch applied only, e.g., on a bare-metal system)

Thanks. For whatever reason it looks like my gmail decided to pop it
out of the thread so I hadn't seen it yet this morning.

I'll have to look into it. It doesn't make much sense to me why this
would have this much impact since especially in the disabled case the
changes should be quite small.

- Alex

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 1/5] perf cs-etm: Refactor instruction size handling
From: Suzuki K Poulose @ 2019-09-23 16:51 UTC (permalink / raw)
  To: Leo Yan, Arnaldo Carvalho de Melo, Mathieu Poirier,
	Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin,
	Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
	Mike Leach, Coresight ML
In-Reply-To: <20190923160759.14866-2-leo.yan@linaro.org>

Hi Leo,

On 23/09/2019 17:07, Leo Yan wrote:
> In cs-etm.c there have several functions need to know instruction size
> based on address, e.g. cs_etm__instr_addr() and cs_etm__copy_insn()
> these two functions both calculate the instruction size separately.
> Furthermore, if we consider to add new features later which also might
> require to calculate instruction size.
> 
> For this reason, this patch refactors the code to introduce a new
> function cs_etm__instr_size(), it will be a central place to calculate
> the instruction size based on ISA type and instruction address.
> 
> For a neat implementation, cs_etm__instr_addr() will always execute the
> loop without checking ISA type, this allows cs_etm__instr_size() and
> cs_etm__instr_addr() have no any duplicate code with each other and both
> functions can be changed independently later without breaking anything.
> As a side effect, cs_etm__instr_addr() will do a few more iterations for
> A32/A64 instructions, this would be fine if consider perf tool runs in
> the user space.
> 
> Signed-off-by: Leo Yan <leo.yan@linaro.org>

Your changes look fine to me. However, please see my comment below.

> ---
>   tools/perf/util/cs-etm.c | 48 +++++++++++++++++++++++-----------------
>   1 file changed, 28 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index f87b9c1c9f9a..1de3f9361193 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -917,6 +917,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
>   	return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
>   }
>   
> +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> +				     u8 trace_chan_id,
> +				     enum cs_etm_isa isa,
> +				     u64 addr)
> +{
> +	int insn_len;
> +
> +	/*
> +	 * T32 instruction size might be 32-bit or 16-bit, decide by calling
> +	 * cs_etm__t32_instr_size().
> +	 */
> +	if (isa == CS_ETM_ISA_T32)
> +		insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> +	/* Otherwise, A64 and A32 instruction size are always 32-bit. */
> +	else
> +		insn_len = 4;
> +
> +	return insn_len;
> +}
> +
>   static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
>   {
>   	/* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> @@ -941,19 +961,15 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
>   				     const struct cs_etm_packet *packet,
>   				     u64 offset)
>   {
> -	if (packet->isa == CS_ETM_ISA_T32) {
> -		u64 addr = packet->start_addr;
> +	u64 addr = packet->start_addr;
>   
> -		while (offset > 0) {
> -			addr += cs_etm__t32_instr_size(etmq,
> -						       trace_chan_id, addr);
> -			offset--;
> -		}
> -		return addr;
> +	while (offset > 0) {

Given that offset is u64, the check above is not appropriate. You could either
change it to :
	while (offset) // if you are sure (s64)offset always is a postive
integer and we always reduce it by 1.

Otherwise you may switch the offset to a signed type. I understand that this
is not introduced by your changes. But you may fix that up in a separate patch.


Kind regards
Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
From: Stephen Boyd @ 2019-09-23 16:54 UTC (permalink / raw)
  To: Fabio Estevam, Laurentiu Palcu, NXP Linux Team,
	Pengutronix Kernel Team, Sascha Hauer, Shawn Guo
  Cc: devicetree, agx, linux-kernel, Laurentiu Palcu, linux-arm-kernel,
	l.stach
In-Reply-To: <1569248002-2485-6-git-send-email-laurentiu.palcu@nxp.com>

Quoting Laurentiu Palcu (2019-09-23 07:13:19)
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 52aae34..d4aa778 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -871,6 +871,31 @@
>                                 interrupt-controller;
>                                 #interrupt-cells = <1>;
>                         };
> +
> +                       dcss: dcss@0x32e00000 {

Drop the 0x prefix on node names.

> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +                               compatible = "nxp,imx8mq-dcss";
> +                               reg = <0x32e00000 0x2D000>, <0x32e2f000 0x1000>;
> +                               interrupts = <6>, <8>, <9>;
> +                               interrupt-names = "ctx_ld", "ctxld_kick", "vblank";
> +                               interrupt-parent = <&irqsteer>;
> +                               clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>,
> +                                        <&clk IMX8MQ_CLK_DISP_AXI_ROOT>,
> +                                        <&clk IMX8MQ_CLK_DISP_RTRM_ROOT>,
> +                                        <&clk IMX8MQ_VIDEO2_PLL_OUT>,
> +                                        <&clk IMX8MQ_CLK_DISP_DTRC>;
> +                               clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
> +                               assigned-clocks = <&clk IMX8MQ_CLK_DISP_AXI>,
> +                                                 <&clk IMX8MQ_CLK_DISP_RTRM>,
> +                                                 <&clk IMX8MQ_VIDEO2_PLL1_REF_SEL>;
> +                               assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_800M>,
> +                                                        <&clk IMX8MQ_SYS1_PLL_800M>,
> +                                                        <&clk IMX8MQ_CLK_27M>;
> +                               assigned-clock-rates = <800000000>,
> +                                                          <400000000>;
> +                               status = "disabled";
> +                       };


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] clk: at91: avoid sleeping early
From: Stephen Boyd @ 2019-09-23 16:58 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Alexandre Belloni, Michael Turquette, linux-kernel,
	Uwe Kleine-König, Claudiu Beznea, linux-clk,
	linux-arm-kernel
In-Reply-To: <20190920153906.20887-1-alexandre.belloni@bootlin.com>

Quoting Alexandre Belloni (2019-09-20 08:39:06)
> It is not allowed to sleep to early in the boot process and this may lead
> to kernel issues if the bootloader didn't prepare the slow clock and main
> clock.
> 
> This results in the following error and dump stack on the AriettaG25:
>    bad: scheduling from the idle thread!
> 
> Ensure it is possible to sleep, else simply have a delay.
> 
> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> 
> Note that this was already discussed a while ago and Arnd said this approach was
> reasonable:
>   https://lore.kernel.org/lkml/6120818.MyeJZ74hYa@wuerfel/

Does this need a Fixes: tag?


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
From: Lucas Stach @ 2019-09-23 17:00 UTC (permalink / raw)
  To: Fabio Estevam, Laurentiu Palcu
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Sascha Hauer, linux-kernel, NXP Linux Team,
	Pengutronix Kernel Team, Shawn Guo, Guido Günther,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5AOVfBpz2Azh65iT_W3CBZUxf9KnqA=kdow7XWd4j--Qg@mail.gmail.com>

Am Montag, den 23.09.2019, 13:12 -0300 schrieb Fabio Estevam:
> Hi Laurentiu,
> 
> On Mon, Sep 23, 2019 at 11:14 AM Laurentiu Palcu
> <laurentiu.palcu@nxp.com> wrote:
> 
> > +
> > +                       dcss: dcss@0x32e00000 {
> 
> Node names should be generic, so:
> 
> dcss: display-controller@32e00000
> 
> > +                               #address-cells = <1>;
> > +                               #size-cells = <0>;
> > +                               compatible = "nxp,imx8mq-dcss";
> > +                               reg = <0x32e00000 0x2D000>,
> > <0x32e2f000 0x1000>;
> 
> 0x2d000 for consistency.
> 
> > +                               interrupts = <6>, <8>, <9>;
> 
> The interrupts are passed in the <GIC_SPI xxx IRQ_TYPE_LEVEL_HIGH>
> format.

No, they are not. Those are imx-irqsteer IRQs, this controller has 0
irq cells, so the description in this patch is correct.

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v8 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Catalin Marinas @ 2019-09-23 17:04 UTC (permalink / raw)
  To: Jia He
  Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
	Suzuki Poulose, Marc Zyngier, Anshuman Khandual, linux-kernel,
	Matthew Wilcox, linux-mm, Jérôme Glisse, James Morse,
	linux-arm-kernel, Punit Agrawal, hejianet, Thomas Gleixner, nd,
	Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190921135054.142360-4-justin.he@arm.com>

On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote:
> @@ -2151,21 +2163,53 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
>  	 * fails, we just zero-fill it. Live with it.
>  	 */
>  	if (unlikely(!src)) {
> -		void *kaddr = kmap_atomic(dst);
> -		void __user *uaddr = (void __user *)(va & PAGE_MASK);
> +		void *kaddr;
> +		pte_t entry;
> +		void __user *uaddr = (void __user *)(addr & PAGE_MASK);
>  
> +		/* On architectures with software "accessed" bits, we would
> +		 * take a double page fault, so mark it accessed here.
> +		 */

Nitpick: please follow the kernel coding style for multi-line comments
(above and the for the rest of the patch):

		/*
		 * Your multi-line comment.
		 */

> +		if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> +			vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
> +						       &vmf->ptl);
> +			if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> +				entry = pte_mkyoung(vmf->orig_pte);
> +				if (ptep_set_access_flags(vma, addr,
> +							  vmf->pte, entry, 0))
> +					update_mmu_cache(vma, addr, vmf->pte);
> +			} else {
> +				/* Other thread has already handled the fault
> +				 * and we don't need to do anything. If it's
> +				 * not the case, the fault will be triggered
> +				 * again on the same address.
> +				 */
> +				pte_unmap_unlock(vmf->pte, vmf->ptl);
> +				return false;
> +			}
> +			pte_unmap_unlock(vmf->pte, vmf->ptl);
> +		}

Another nit, you could rewrite this block slightly to avoid too much
indentation. Something like (untested):

		if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
			vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
						       &vmf->ptl);
			if (unlikely(!pte_same(*vmf->pte, vmf->orig_pte))) {
				/*
				 * Other thread has already handled the fault
				 * and we don't need to do anything. If it's
				 * not the case, the fault will be triggered
				 * again on the same address.
				 */
				pte_unmap_unlock(vmf->pte, vmf->ptl);
				return false;
			}
			entry = pte_mkyoung(vmf->orig_pte);
			if (ptep_set_access_flags(vma, addr,
						  vmf->pte, entry, 0))
				update_mmu_cache(vma, addr, vmf->pte);
			pte_unmap_unlock(vmf->pte, vmf->ptl);
		}

> +
> +		kaddr = kmap_atomic(dst);

Since you moved the kmap_atomic() here, could the above
arch_faults_on_old_pte() run in a preemptible context? I suggested to
add a WARN_ON in patch 2 to be sure.

>  		/*
>  		 * This really shouldn't fail, because the page is there
>  		 * in the page tables. But it might just be unreadable,
>  		 * in which case we just give up and fill the result with
>  		 * zeroes.
>  		 */
> -		if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> +		if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> +			/* Give a warn in case there can be some obscure
> +			 * use-case
> +			 */
> +			WARN_ON_ONCE(1);

That's more of a question for the mm guys: at this point we do the
copying with the ptl released; is there anything else that could have
made the pte old in the meantime? I think unuse_pte() is only called on
anonymous vmas, so it shouldn't be the case here.

>  			clear_page(kaddr);
> +		}
>  		kunmap_atomic(kaddr);
>  		flush_dcache_page(dst);
>  	} else
> -		copy_user_highpage(dst, src, va, vma);
> +		copy_user_highpage(dst, src, addr, vma);
> +
> +	return true;
>  }

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 1/5] perf cs-etm: Refactor instruction size handling
From: Leo Yan @ 2019-09-23 17:13 UTC (permalink / raw)
  To: Suzuki K Poulose
  Cc: Mark Rutland, Mathieu Poirier, Peter Zijlstra, Coresight ML,
	linux-kernel, Arnaldo Carvalho de Melo, Alexander Shishkin,
	Ingo Molnar, Namhyung Kim, Jiri Olsa, linux-arm-kernel,
	Mike Leach
In-Reply-To: <2b675e24-8b06-fbd6-ab73-214a6afb2a07@arm.com>

Hi Suzuki,

On Mon, Sep 23, 2019 at 05:51:04PM +0100, Suzuki K Poulose wrote:
> Hi Leo,
> 
> On 23/09/2019 17:07, Leo Yan wrote:
> > In cs-etm.c there have several functions need to know instruction size
> > based on address, e.g. cs_etm__instr_addr() and cs_etm__copy_insn()
> > these two functions both calculate the instruction size separately.
> > Furthermore, if we consider to add new features later which also might
> > require to calculate instruction size.
> > 
> > For this reason, this patch refactors the code to introduce a new
> > function cs_etm__instr_size(), it will be a central place to calculate
> > the instruction size based on ISA type and instruction address.
> > 
> > For a neat implementation, cs_etm__instr_addr() will always execute the
> > loop without checking ISA type, this allows cs_etm__instr_size() and
> > cs_etm__instr_addr() have no any duplicate code with each other and both
> > functions can be changed independently later without breaking anything.
> > As a side effect, cs_etm__instr_addr() will do a few more iterations for
> > A32/A64 instructions, this would be fine if consider perf tool runs in
> > the user space.
> > 
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> 
> Your changes look fine to me. However, please see my comment below.
> 
> > ---
> >   tools/perf/util/cs-etm.c | 48 +++++++++++++++++++++++-----------------
> >   1 file changed, 28 insertions(+), 20 deletions(-)
> > 
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index f87b9c1c9f9a..1de3f9361193 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -917,6 +917,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
> >   	return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> >   }
> > +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> > +				     u8 trace_chan_id,
> > +				     enum cs_etm_isa isa,
> > +				     u64 addr)
> > +{
> > +	int insn_len;
> > +
> > +	/*
> > +	 * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > +	 * cs_etm__t32_instr_size().
> > +	 */
> > +	if (isa == CS_ETM_ISA_T32)
> > +		insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> > +	/* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > +	else
> > +		insn_len = 4;
> > +
> > +	return insn_len;
> > +}
> > +
> >   static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> >   {
> >   	/* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> > @@ -941,19 +961,15 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
> >   				     const struct cs_etm_packet *packet,
> >   				     u64 offset)
> >   {
> > -	if (packet->isa == CS_ETM_ISA_T32) {
> > -		u64 addr = packet->start_addr;
> > +	u64 addr = packet->start_addr;
> > -		while (offset > 0) {
> > -			addr += cs_etm__t32_instr_size(etmq,
> > -						       trace_chan_id, addr);
> > -			offset--;
> > -		}
> > -		return addr;
> > +	while (offset > 0) {
> 
> Given that offset is u64, the check above is not appropriate. You could either
> change it to :
> 	while (offset) // if you are sure (s64)offset always is a postive
> integer and we always reduce it by 1.
> 
> Otherwise you may switch the offset to a signed type. I understand that this
> is not introduced by your changes. But you may fix that up in a separate patch.

Thanks a lot for the review.  Seems to me the reliable fix is to change
to a signed type.  Will add this fix in next spin.

Thanks,
Leo Yan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 22/36] drm/atmel-hlcdc: use bpp instead of cpp for drm_format_info
From: Sam Ravnborg @ 2019-09-23 17:31 UTC (permalink / raw)
  To: Sandy Huang
  Cc: Alexandre Belloni, Boris Brezillon, David Airlie, dri-devel,
	linux-kernel, Ludovic Desroches, Daniel Vetter, linux-arm-kernel
In-Reply-To: <1569243119-183293-2-git-send-email-hjc@rock-chips.com>

Hi Sandy.

Thanks for taking care of this, but...

On Mon, Sep 23, 2019 at 08:51:45PM +0800, Sandy Huang wrote:
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
> 
> Signed-off-by: Sandy Huang <hjc@rock-chips.com>
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 89f5a75..ab7d423 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -644,7 +644,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane *p,
>  		int xdiv = i ? fb->format->hsub : 1;
>  		int ydiv = i ? fb->format->vsub : 1;
>  
> -		state->bpp[i] = fb->format->cpp[i];
> +		state->bpp[i] = fb->format->bpp[i] / 8;
>  		if (!state->bpp[i])
>  			return -EINVAL;

Awaiting conclusion on Daniels comment on PATCH 1 and has dropped this
patch for now.
And please address the concerns Rob has about bisectability in your
cover letter for v2.

	Sam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V8 2/2] arm64/mm: Enable memory hot remove
From: kbuild test robot @ 2019-09-23 17:39 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: mark.rutland, mhocko, david, catalin.marinas, linux-mm, arunks,
	cpandya, will, ira.weiny, steven.price, valentin.schneider,
	suzuki.poulose, Robin.Murphy, broonie, cai, ard.biesheuvel,
	dan.j.williams, linux-arm-kernel, osalvador, steve.capper, logang,
	linux-kernel, kbuild-all, akpm, mgorman
In-Reply-To: <1569217425-23777-3-git-send-email-anshuman.khandual@arm.com>

[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]

Hi Anshuman,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Anshuman-Khandual/arm64-mm-Hold-memory-hotplug-lock-while-walking-for-kernel-page-table-dump/20190923-134733
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> mm/memremap.c:16:0: warning: "SECTION_MASK" redefined
    #define SECTION_MASK ~((1UL << PA_SECTION_SHIFT) - 1)
    
   In file included from arch/arm64/include/asm/processor.h:34:0,
                    from include/linux/mutex.h:19,
                    from include/linux/kernfs.h:12,
                    from include/linux/sysfs.h:16,
                    from include/linux/kobject.h:20,
                    from include/linux/device.h:16,
                    from mm/memremap.c:3:
   arch/arm64/include/asm/pgtable-hwdef.h:79:0: note: this is the location of the previous definition
    #define SECTION_MASK  (~(SECTION_SIZE-1))
    
>> mm/memremap.c:17:0: warning: "SECTION_SIZE" redefined
    #define SECTION_SIZE (1UL << PA_SECTION_SHIFT)
    
   In file included from arch/arm64/include/asm/processor.h:34:0,
                    from include/linux/mutex.h:19,
                    from include/linux/kernfs.h:12,
                    from include/linux/sysfs.h:16,
                    from include/linux/kobject.h:20,
                    from include/linux/device.h:16,
                    from mm/memremap.c:3:
   arch/arm64/include/asm/pgtable-hwdef.h:78:0: note: this is the location of the previous definition
    #define SECTION_SIZE  (_AC(1, UL) << SECTION_SHIFT)
    

vim +/SECTION_MASK +16 mm/memremap.c

7d3dcf26a6559f kernel/memremap.c Christoph Hellwig 2015-08-10  @3  #include <linux/device.h>
92281dee825f6d kernel/memremap.c Dan Williams      2015-08-10   4  #include <linux/io.h>
0207df4fa1a869 kernel/memremap.c Andrey Ryabinin   2018-08-17   5  #include <linux/kasan.h>
41e94a851304f7 kernel/memremap.c Christoph Hellwig 2015-08-17   6  #include <linux/memory_hotplug.h>
bcfa4b72111c9a kernel/memremap.c Matthew Wilcox    2018-08-15   7  #include <linux/mm.h>
bcfa4b72111c9a kernel/memremap.c Matthew Wilcox    2018-08-15   8  #include <linux/pfn_t.h>
5042db43cc26f5 kernel/memremap.c Jérôme Glisse     2017-09-08   9  #include <linux/swap.h>
5042db43cc26f5 kernel/memremap.c Jérôme Glisse     2017-09-08  10  #include <linux/swapops.h>
bcfa4b72111c9a kernel/memremap.c Matthew Wilcox    2018-08-15  11  #include <linux/types.h>
e7638488434415 kernel/memremap.c Dan Williams      2018-05-16  12  #include <linux/wait_bit.h>
bcfa4b72111c9a kernel/memremap.c Matthew Wilcox    2018-08-15  13  #include <linux/xarray.h>
92281dee825f6d kernel/memremap.c Dan Williams      2015-08-10  14  
bcfa4b72111c9a kernel/memremap.c Matthew Wilcox    2018-08-15  15  static DEFINE_XARRAY(pgmap_array);
9476df7d80dfc4 kernel/memremap.c Dan Williams      2016-01-15 @16  #define SECTION_MASK ~((1UL << PA_SECTION_SHIFT) - 1)
9476df7d80dfc4 kernel/memremap.c Dan Williams      2016-01-15 @17  #define SECTION_SIZE (1UL << PA_SECTION_SHIFT)
9476df7d80dfc4 kernel/memremap.c Dan Williams      2016-01-15  18  

:::::: The code at line 16 was first introduced by commit
:::::: 9476df7d80dfc425b37bfecf1d89edf8ec81fcb6 mm: introduce find_dev_pagemap()

:::::: TO: Dan Williams <dan.j.williams@intel.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 67082 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFCv4 3/7] dt-bindings: devfreq: imx: Describe interconnect properties
From: Leonard Crestez @ 2019-09-23 17:42 UTC (permalink / raw)
  To: Rob Herring, Georgi Djakov
  Cc: Mark Rutland, Artur Świgoń,
	linux-arm-kernel@lists.infradead.org, Saravana Kannan,
	linux-pm@vger.kernel.org, Stephen Boyd, Viresh Kumar,
	Michael Turquette, Krzysztof Kozlowski, Chanwoo Choi,
	Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
	kernel@pengutronix.de, Fabio Estevam, Shawn Guo, Aisheng Dong,
	devicetree@vger.kernel.org, dl-linux-imx
In-Reply-To: <20190917201956.GA10780@bogus>

On 17.09.2019 23:20, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 05:36:56PM +0300, Leonard Crestez wrote:
>> The interconnect-node-id property is parsed by the imx interconnect
>> driver to find nodes on which frequencies can be adjusted.
>>
>> Add #interconnect-cells so that device drivers can request paths from
>> bus nodes instead of requiring a separate "virtual" node to represent
>> the interconnect itself.
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> ---
>>   Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml | 5 +++++
>>   Documentation/devicetree/bindings/devfreq/imx.yaml      | 5 +++++
>>   2 files changed, 10 insertions(+)
> 
> Please combine this with the other series for devfreq support.

I understand that having two series which add to the same bindings file 
is odd but the devfreq and interconnect parts are independent to a very 
large degree and devfreq can be useful on it's own.

The only reason devfreq bindings are updated is to avoid adding a 
"virtual" node for interconnect. Since DT is a big source of confusion 
here can you read https://patchwork.kernel.org/cover/11111865/#22883457 
and maybe offer some advice?

--
Regards,
Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
From: Tony Lindgren @ 2019-09-23 17:47 UTC (permalink / raw)
  To: santosh.shilimkar
  Cc: devicetree, Tero Kristo, robh+dt, p.zabel, ssantosh, linux-omap,
	linux-arm-kernel
In-Reply-To: <13a77bd8-72bd-6a44-9141-d5492be82d82@oracle.com>

* santosh.shilimkar@oracle.com <santosh.shilimkar@oracle.com> [190920 19:20]:
> On 9/20/19 7:28 AM, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [190912 04:39]:
> > > Hi,
> > > 
> > > V5 of the series, re-sent the whole series as one patch was dropped.
> > > Changes compared to v3/v4:
> > > 
> > > - removed dependency towards clock driver (patch #5 was completely
> > >    dropped compared to v3/v4)
> > > - dropped clocks property from dt binding
> > > - re-added the pdata patch which was accidentally dropped out (it has
> > >    dependency towards this series.)
> > > 
> > > The new implementation (without clock driver dependency) relies on the
> > > bus driver to sequence events properly, otherwise some timeouts will
> > > occur either at clock driver or reset driver end.
> > 
> > With the two updated patches seems like we're done with this
> > series?
> > 
> > If so, I suggest either Santosh or me sets up an immutable
> > branch against v5.3 or v5.4-rc1 that we all can merge in.
> > I will need it for the related dts changes at least.
> > 
> I will pick this up Tony and apply it once v5.4-rc1 is out.

OK thanks.

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
From: Fabio Estevam @ 2019-09-23 17:53 UTC (permalink / raw)
  To: Lucas Stach
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Laurentiu Palcu, Sascha Hauer, linux-kernel, NXP Linux Team,
	Pengutronix Kernel Team, Shawn Guo, Guido Günther,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <45ad0ec1bfd5af4f46efd7d24c627822ac17fdbf.camel@pengutronix.de>

On Mon, Sep 23, 2019 at 2:01 PM Lucas Stach <l.stach@pengutronix.de> wrote:

> No, they are not. Those are imx-irqsteer IRQs, this controller has 0
> irq cells, so the description in this patch is correct.

Good point, thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox