* Re: [PATCH v4] arm64: dts: imx8mq: Init rates and parents configs for clocks
From: Leonard Crestez @ 2019-08-21 20:39 UTC (permalink / raw)
To: Daniel Baluta, shawnguo@kernel.org, Abel Vesa
Cc: devicetree@vger.kernel.org, baruch@tkos.co.il, Jacky Bai,
Anson Huang, ccaione@baylibre.com, andrew.smirnov@gmail.com,
s.hauer@pengutronix.de, angus@akkea.ca, Stephen Boyd,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
agx@sigxcpu.org, dl-linux-imx, Peng Fan, festevam@gmail.com,
S.j. Wang, linux-arm-kernel@lists.infradead.org,
l.stach@pengutronix.de
In-Reply-To: <20190728152040.15323-1-daniel.baluta@nxp.com>
On 28.07.2019 18:20, Daniel Baluta wrote:
> From: Abel Vesa <abel.vesa@nxp.com>
>
> Add the initial configuration for clocks that need default parent and rate
> setting. This is based on the vendor tree clock provider parents and rates
> configuration except this is doing the setup in dts rather then using clock
> consumer API in a clock provider driver.
>
> Note that by adding the initial rate setting for audio_pll1/audio_pll
> setting we need to remove it from imx8mq-librem5-devkit.dts
Setting default rates for audio_pll1 and audio_pll2 in soc dtsi makes a
lot of sense to me; the intention is for one to run at a multiple of
44.1k and another at a multiple of 48k.
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 02fbd0625318..a55d72ba2e05 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -494,6 +494,25 @@
> clock-names = "ckil", "osc_25m", "osc_27m",
> "clk_ext1", "clk_ext2",
> "clk_ext3", "clk_ext4";
> + assigned-clocks = <&clk IMX8MQ_VIDEO_PLL1>,
> + <&clk IMX8MQ_AUDIO_PLL1>,
> + <&clk IMX8MQ_AUDIO_PLL2>,
> + <&clk IMX8MQ_CLK_AHB>,
> + <&clk IMX8MQ_CLK_NAND_USDHC_BUS>,
> + <&clk IMX8MQ_CLK_AUDIO_AHB>,
> + <&clk IMX8MQ_VIDEO_PLL1_REF_SEL>,
> + <&clk IMX8MQ_CLK_NOC>;
> + assigned-clock-parents = <0>,
> + <0>,
> + <0> > + <&clk IMX8MQ_SYS1_PLL_133M>,
> + <&clk IMX8MQ_SYS1_PLL_266M>,
> + <&clk IMX8MQ_SYS2_PLL_500M>,
> + <&clk IMX8MQ_CLK_27M>,
> + <&clk IMX8MQ_SYS1_PLL_800M>;
> + assigned-clock-rates = <593999999>,
> + <786432000>,
> + <722534400>;
The audio PLLs should run below 650 mHz so please use 393216000 and
361267200 instead of 786432000 and 722534400. For the 8mm equivalent see
commit 053a4ffe2988 ("clk: imx: imx8mm: fix audio pll setting").
You should also move the unbypassing of AUDIO_PLL1 and AUDIO_PLL2 here
just add two more assigned-clocks and assigned-clock-parents.
--
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: [RESEND PATCH v5 4/4] dt-bindings: devfreq: exynos-bus: remove unused property
From: Rob Herring @ 2019-08-21 20:35 UTC (permalink / raw)
To: Kamil Konieczny
Cc: Mark Rutland, Nishanth Menon, linux-samsung-soc, linux-arm-kernel,
Bartlomiej Zolnierkiewicz, Stephen Boyd, Viresh Kumar, linux-pm,
linux-kernel, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
Kukjin Kim, MyungJoo Ham, devicetree, Marek Szyprowski
In-Reply-To: <20190808090234.12577-5-k.konieczny@partner.samsung.com>
On Thu, Aug 08, 2019 at 11:02:34AM +0200, Kamil Konieczny wrote:
> Remove unused DT property "exynos,voltage-tolerance".
>
> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 2 --
> 1 file changed, 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC,v4,1/4] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Rob Herring @ 2019-08-21 20:17 UTC (permalink / raw)
To: Jungo Lin
Cc: ryan.yu, frankie.chiu, laurent.pinchart, Rynn.Wu, suleiman,
Jerry-ch.Chen, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190807124803.29884-2-jungo.lin@mediatek.com>
On Wed, Aug 07, 2019 at 08:48:00PM +0800, Jungo Lin wrote:
> This patch adds DT binding document for the Pass 1 (P1) unit
> in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> data out from the sensor interface, applies ISP image effects
> from tuning data and outputs the image data or statistics data to DRAM.
>
> Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> ---
> .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> 1 file changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,camisp.txt b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> new file mode 100644
> index 000000000000..fa2713acceca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> @@ -0,0 +1,73 @@
> +* Mediatek Image Signal Processor Pass 1 (ISP P1)
> +
> +The Pass 1 unit of Mediatek's camera ISP system grabs the sensor data out
> +from the sensor interface, applies ISP effects from tuning data and outputs
> +the image data and statistics data to DRAM. Furthermore, Pass 1 unit has
> +the ability to output two different resolutions frames at the same time to
> +increase the performance of the camera application.
> +
> +Required properties:
> +- compatible: Must be "mediatek,mt8183-camisp" for MT8183.
> +- reg: Physical base address of the camera function block register and
> + length of memory mapped region. Must contain an entry for each entry
> + in reg-names.
> +- reg-names: Must include the following entries:
> + "cam_sys": Camera base function block
> + "cam_uni": Camera UNI function block
> + "cam_a": Camera ISP P1 hardware unit A
> + "cam_b": Camera ISP P1 hardware unit B
> + "cam_c": Camera ISP P1 hardware unit C
> +- interrupts: Must contain an entry for each entry in interrupt-names.
> +- interrupt-names : Must include the following entries:
> + "cam_uni": Camera UNI interrupt
> + "cam_a": Camera unit A interrupt
> + "cam_b": Camera unit B interrupt
> + "cam_c": Camera unit C interrupt
> +- iommus: Shall point to the respective IOMMU block with master port
> + as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> + for details.
> +- clocks: A list of phandle and clock specifier pairs as listed
> + in clock-names property, see
> + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: Must be "camsys_cam_cgpdn" and "camsys_camtg_cgpdn".
> +- mediatek,larb: Must contain the local arbiters in the current SoCs, see
> + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> + for details.
> +- power-domains: a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,scp : The node of system control processor (SCP), see
> + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> +
> +Example:
> +SoC specific DT entry:
> +
> + camisp: camisp@1a000000 {
Also, you can remove 2 levels of indentation here.
> + compatible = "mediatek,mt8183-camisp", "syscon";
> + reg = <0 0x1a000000 0 0x1000>,
> + <0 0x1a003000 0 0x1000>,
> + <0 0x1a004000 0 0x2000>,
> + <0 0x1a006000 0 0x2000>,
> + <0 0x1a008000 0 0x2000>;
> + reg-names = "cam_sys",
> + "cam_uni",
> + "cam_a",
> + "cam_b",
> + "cam_c";
> + interrupts = <GIC_SPI 253 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 254 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 255 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 256 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "cam_uni",
> + "cam_a",
> + "cam_b",
> + "cam_c";
> + iommus = <&iommu M4U_PORT_CAM_IMGO>;
> + clocks = <&camsys CLK_CAM_CAM>,
> + <&camsys CLK_CAM_CAMTG>;
> + clock-names = "camsys_cam_cgpdn",
> + "camsys_camtg_cgpdn";
> + mediatek,larb = <&larb3>,
> + <&larb6>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> + mediatek,scp = <&scp>;
> + };
> --
> 2.18.0
>
_______________________________________________
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 v3] arm64: implement KPROBES_ON_FTRACE
From: Naveen N. Rao @ 2019-08-21 20:12 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Jisheng Zhang, Masami Hiramatsu,
Peter Zijlstra, Thomas Gleixner, Will Deacon
Cc: Ingo Molnar, Steven Rostedt, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20190821183501.33588dd8@xhacker.debian>
Jisheng Zhang wrote:
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> Tested on berlin arm64 platform.
>
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
>
> before the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009fe28 k _do_fork+0x0 [DISABLED]
>
> after the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009ff54 k _do_fork+0x4 [DISABLED][FTRACE]
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> Applied after arm64 FTRACE_WITH_REGS:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/674404.html
>
> Changes since v2:
> - remove patch1, make it a single cleanup patch
> - remove "This patch" in the change log
> - implement arm64's kprobe_lookup_name() and arch_kprobe_on_func_entry instead
> patching the common kprobes code
>
> Changes since v1:
> - make the kprobes/x86: use instruction_pointer and instruction_pointer_set
> as patch1
> - add Masami's ACK to patch1
> - add some description about KPROBES_ON_FTRACE and why we need it on
> arm64
> - correct the log before the patch
> - remove the consolidation patch, make it as TODO
> - only adjust kprobe's addr when KPROBE_FLAG_FTRACE is set
> - if KPROBES_ON_FTRACE, ftrace_call_adjust() the kprobe's addr before
> calling ftrace_location()
> - update the kprobes-on-ftrace/arch-support.txt in doc
>
>
> .../debug/kprobes-on-ftrace/arch-support.txt | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/probes/Makefile | 1 +
> arch/arm64/kernel/probes/ftrace.c | 60 +++++++++++++++++++
> arch/arm64/kernel/probes/kprobes.c | 23 +++++++
> 5 files changed, 86 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/kernel/probes/ftrace.c
>
> diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> index 68f266944d5f..e8358a38981c 100644
> --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> @@ -9,7 +9,7 @@
> | alpha: | TODO |
> | arc: | TODO |
> | arm: | TODO |
> - | arm64: | TODO |
> + | arm64: | ok |
> | c6x: | TODO |
> | csky: | TODO |
> | h8300: | TODO |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 663392d1eae2..928700f15e23 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -167,6 +167,7 @@ config ARM64
> select HAVE_STACKPROTECTOR
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_KPROBES
> + select HAVE_KPROBES_ON_FTRACE
> select HAVE_KRETPROBES
> select HAVE_GENERIC_VDSO
> select IOMMU_DMA if IOMMU_SUPPORT
> diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
> index 8e4be92e25b1..4020cfc66564 100644
> --- a/arch/arm64/kernel/probes/Makefile
> +++ b/arch/arm64/kernel/probes/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
> simulate-insn.o
> obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o \
> simulate-insn.o
> +obj-$(CONFIG_KPROBES_ON_FTRACE) += ftrace.o
> diff --git a/arch/arm64/kernel/probes/ftrace.c b/arch/arm64/kernel/probes/ftrace.c
> new file mode 100644
> index 000000000000..1f0c09d02bb8
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/ftrace.c
> @@ -0,0 +1,60 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Dynamic Ftrace based Kprobes Optimization
> + *
> + * Copyright (C) Hitachi Ltd., 2012
> + * Copyright (C) 2019 Jisheng Zhang <jszhang@kernel.org>
> + * Synaptics Incorporated
> + */
> +
> +#include <linux/kprobes.h>
> +
> +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> +void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> + struct ftrace_ops *ops, struct pt_regs *regs)
> +{
> + struct kprobe *p;
> + struct kprobe_ctlblk *kcb;
> +
> + /* Preempt is disabled by ftrace */
> + p = get_kprobe((kprobe_opcode_t *)ip);
> + if (unlikely(!p) || kprobe_disabled(p))
> + return;
> +
> + kcb = get_kprobe_ctlblk();
> + if (kprobe_running()) {
> + kprobes_inc_nmissed_count(p);
> + } else {
> + unsigned long orig_ip = instruction_pointer(regs);
> + /* Kprobe handler expects regs->pc = pc + 4 as breakpoint hit */
> + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> +
> + __this_cpu_write(current_kprobe, p);
> + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> + /*
> + * Emulate singlestep (and also recover regs->pc)
> + * as if there is a nop
> + */
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> + if (unlikely(p->post_handler)) {
> + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> + p->post_handler(p, regs, 0);
> + }
> + instruction_pointer_set(regs, orig_ip);
> + }
> + /*
> + * If pre_handler returns !0, it changes regs->pc. We have to
> + * skip emulating post_handler.
> + */
> + __this_cpu_write(current_kprobe, NULL);
> + }
> +}
> +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> +
> +int arch_prepare_kprobe_ftrace(struct kprobe *p)
> +{
> + p->ainsn.api.insn = NULL;
> + return 0;
> +}
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index c4452827419b..f2bf8c70da79 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -551,6 +551,29 @@ void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
> return (void *)orig_ret_address;
> }
>
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
This should be CONFIG_KPROBES_ON_FTRACE since you only want to choose
the ftrace entry in that case.
> +kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
> +{
> + unsigned long addr = kallsyms_lookup_name(name);
> + unsigned long faddr;
> +
> + /*
> + * with -fpatchable-function-entry=2, the first 4 bytes is the
> + * LR saver, then the actual call insn. So ftrace location is
> + * always on the first 4 bytes offset.
> + */
> + faddr = ftrace_location_range(addr, addr + AARCH64_INSN_SIZE);
> + if (faddr)
> + return (kprobe_opcode_t *)faddr;
You should only return the ftrace location if offset is 0, since the
offset is added to the address returned from here (see _kprobe_addr()).
- Naveen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: allwinner: a64: Add A64 OlinuXino board (with eMMC)
From: Sunil Mohan Adapa @ 2019-08-21 19:52 UTC (permalink / raw)
To: linux-arm-kernel, devicetree
Cc: mark.rutland, maxime.ripard, Sunil Mohan Adapa, Martin Ayotte,
wens, robh+dt
In-Reply-To: <20190821195217.4166-1-sunil@medhas.org>
A64 OLinuXino board from Olimex has three variants with onboard eMMC:
A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
addition, there are two variants without eMMC. One without eMMC and one with SPI
flash. This suggests the need for separate device tree for the three eMMC
variants.
This patch has been tested on A64-OLinuXino-1Ge16GW with Linux 5.0 from Debain.
Basic benchmarks using Flexible IO Tester show reasonable performance from the
eMMC.
eMMC - Random Write: 21.3MiB/s
eMMC - Sequential Write: 68.2MiB/s
SD Card - Random Write: 1690KiB/s
SD Card - Sequential Write: 11.0MiB/s
Changes:
v3: Separate dts for eMMC variants
v2: Fix descriptions for VCC and VCCQ
Link: https://github.com/armbian/build/commit/174953de1eb09e6aa1ef7075066b573dba625398
Signed-off-by: Martin Ayotte <martinayotte@gmail.com>
[sunil@medhas.org Fix descriptions for VCC and VCCQ, separate dts for eMMC]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Tested-by: Sunil Mohan Adapa <sunil@medhas.org>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../allwinner/sun50i-a64-olinuxino-emmc.dts | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 395fe76f6819..d2418021768b 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-oceanic-5205-5inmfd.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino-emmc.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts
new file mode 100644
index 000000000000..96ab0227e82d
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Martin Ayotte <martinayotte@gmail.com>
+ * Copyright (C) 2019 Sunil Mohan Adapa <sunil@medhas.org>
+ */
+
+#include "sun50i-a64-olinuxino.dts"
+
+/ {
+ model = "Olimex A64-Olinuxino-eMMC";
+ compatible = "olimex,a64-olinuxino-emmc", "allwinner,sun50i-a64";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <®_dcdc1>;
+ vqmmc-supply = <®_dcdc1>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
--
2.20.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 v3 1/2] dt-bindings: arm: sunxi: Add compatible for A64 OlinuXino with eMMC
From: Sunil Mohan Adapa @ 2019-08-21 19:52 UTC (permalink / raw)
To: linux-arm-kernel, devicetree
Cc: maxime.ripard, mark.rutland, wens, robh+dt, Sunil Mohan Adapa
In-Reply-To: <20190821195217.4166-1-sunil@medhas.org>
A64 OLinuXino board from Olimex has three variants with onboard eMMC:
A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
addition, there are two variants without eMMC. One without eMMC and one with SPI
flash. This suggests the need for separate device tree for the three eMMC
variants.
Add new compatible string to the bindings documentation for the A64 OlinuXino
board variant with on-board eMMC.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 93dc4c607f07..972b1e9ee804 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -574,6 +574,11 @@ properties:
- const: olimex,a64-olinuxino
- const: allwinner,sun50i-a64
+ - description: Olimex A64-OlinuXino (with eMMC)
+ items:
+ - const: olimex,a64-olinuxino-emmc
+ - const: allwinner,sun50i-a64
+
- description: Olimex A64 Teres-I
items:
- const: olimex,a64-teres-i
--
2.20.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 v3 0/2] arm64: dts: allwinner: a64: Add A64 OlinuXino board (with eMMC)
From: Sunil Mohan Adapa @ 2019-08-21 19:52 UTC (permalink / raw)
To: linux-arm-kernel, devicetree
Cc: maxime.ripard, mark.rutland, wens, robh+dt, Sunil Mohan Adapa
A64 OLinuXino board from Olimex has three variants with onboard eMMC:
A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
addition, there are two variants without eMMC. One without eMMC and one with SPI
flash. This suggests the need for separate device tree for the three eMMC
variants.
Changes:
v3: Separate dts for eMMC variants
v2: Fix descriptions for VCC and VCCQ
Version 2 of this series already committed in linux-sunxi tree as
8d3071f3e85894be35a1b35bcf6fdef970c81018 must be reverted before applying this.
Sunil Mohan Adapa (2):
dt-bindings: arm: sunxi: Add compatible for A64 OlinuXino with eMMC
arm64: dts: allwinner: a64: Add A64 OlinuXino board (with eMMC)
.../devicetree/bindings/arm/sunxi.yaml | 5 ++++
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../allwinner/sun50i-a64-olinuxino-emmc.dts | 23 +++++++++++++++++++
3 files changed, 29 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino-emmc.dts
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC,v4,1/4] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Rob Herring @ 2019-08-21 19:47 UTC (permalink / raw)
To: Jungo Lin
Cc: ryan.yu, frankie.chiu, laurent.pinchart, Rynn.Wu, suleiman,
Jerry-ch.Chen, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190807124803.29884-2-jungo.lin@mediatek.com>
On Wed, Aug 07, 2019 at 08:48:00PM +0800, Jungo Lin wrote:
> This patch adds DT binding document for the Pass 1 (P1) unit
> in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> data out from the sensor interface, applies ISP image effects
> from tuning data and outputs the image data or statistics data to DRAM.
>
> Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> ---
> .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> 1 file changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,camisp.txt b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> new file mode 100644
> index 000000000000..fa2713acceca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> @@ -0,0 +1,73 @@
> +* Mediatek Image Signal Processor Pass 1 (ISP P1)
> +
> +The Pass 1 unit of Mediatek's camera ISP system grabs the sensor data out
> +from the sensor interface, applies ISP effects from tuning data and outputs
> +the image data and statistics data to DRAM. Furthermore, Pass 1 unit has
> +the ability to output two different resolutions frames at the same time to
> +increase the performance of the camera application.
> +
> +Required properties:
> +- compatible: Must be "mediatek,mt8183-camisp" for MT8183.
> +- reg: Physical base address of the camera function block register and
> + length of memory mapped region. Must contain an entry for each entry
> + in reg-names.
> +- reg-names: Must include the following entries:
> + "cam_sys": Camera base function block
> + "cam_uni": Camera UNI function block
> + "cam_a": Camera ISP P1 hardware unit A
> + "cam_b": Camera ISP P1 hardware unit B
> + "cam_c": Camera ISP P1 hardware unit C
> +- interrupts: Must contain an entry for each entry in interrupt-names.
> +- interrupt-names : Must include the following entries:
> + "cam_uni": Camera UNI interrupt
> + "cam_a": Camera unit A interrupt
> + "cam_b": Camera unit B interrupt
> + "cam_c": Camera unit C interrupt
> +- iommus: Shall point to the respective IOMMU block with master port
> + as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> + for details.
> +- clocks: A list of phandle and clock specifier pairs as listed
> + in clock-names property, see
> + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: Must be "camsys_cam_cgpdn" and "camsys_camtg_cgpdn".
> +- mediatek,larb: Must contain the local arbiters in the current SoCs, see
> + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> + for details.
> +- power-domains: a phandle to the power domain, see
> + Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- mediatek,scp : The node of system control processor (SCP), see
> + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> +
> +Example:
> +SoC specific DT entry:
> +
> + camisp: camisp@1a000000 {
> + compatible = "mediatek,mt8183-camisp", "syscon";
syscon doesn't seem appropriate nor is it documented.
> + reg = <0 0x1a000000 0 0x1000>,
> + <0 0x1a003000 0 0x1000>,
> + <0 0x1a004000 0 0x2000>,
> + <0 0x1a006000 0 0x2000>,
> + <0 0x1a008000 0 0x2000>;
> + reg-names = "cam_sys",
> + "cam_uni",
> + "cam_a",
> + "cam_b",
> + "cam_c";
> + interrupts = <GIC_SPI 253 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 254 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 255 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 256 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "cam_uni",
> + "cam_a",
> + "cam_b",
> + "cam_c";
> + iommus = <&iommu M4U_PORT_CAM_IMGO>;
> + clocks = <&camsys CLK_CAM_CAM>,
> + <&camsys CLK_CAM_CAMTG>;
> + clock-names = "camsys_cam_cgpdn",
> + "camsys_camtg_cgpdn";
> + mediatek,larb = <&larb3>,
> + <&larb6>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> + mediatek,scp = <&scp>;
> + };
> --
> 2.18.0
>
_______________________________________________
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 16/20] dt-bindings: marvell: Declare the CN913x SoC compatibles
From: Rob Herring @ 2019-08-21 19:37 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Yan Markman, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Maxime Chevallier,
Nadav Haklai, Thomas Petazzoni, Stefan Chulski, Marcin Wojtas,
linux-arm-kernel
In-Reply-To: <20190806145500.24109-17-miquel.raynal@bootlin.com>
On Tue, Aug 06, 2019 at 04:54:56PM +0200, Miquel Raynal wrote:
> From: Grzegorz Jaszczyk <jaz@semihalf.com>
>
> Describe the compatible properties for the new Marvell SoCs:
> * CN9130: 1x AP807-quad + 1x CP115 (1x embedded)
> * CN9131: 1x AP807-quad + 2x CP115 (1x embedded + 1x modular)
> * CN9132: 1x AP807-quad + 3x CP115 (1x embedded + 2x modular)
>
> CP115 are similar to CP110 in terms of features.
>
> There are three development boards based on these SoCs:
> * CN9130-DB: comes as a single mother board (with the CP115 bundled)
> * CN9131-DB: same as CN9130-DB with one additional modular CP115
> * CN9132-DB: same as CN9130-DB with two additional modular CP115
>
> Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../bindings/arm/marvell/armada-7k-8k.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
Please convert this to DT schema first.
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> index df98a9c82a8c..8eb34ca4c4f0 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> @@ -1,7 +1,7 @@
> Marvell Armada 7K/8K Platforms Device Tree Bindings
> ---------------------------------------------------
>
> -Boards using a SoC of the Marvell Armada 7K or 8K families must carry
> +Boards using a SoC of the Marvell Armada 7K/8K or CN913x families must carry
> the following root node property:
>
> - compatible, with one of the following values:
> @@ -18,6 +18,17 @@ the following root node property:
> - "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
> when the SoC being used is the Armada 8040
>
> + - "marvell,cn9130", "marvell,armada-ap807-quad", "marvell,armada-ap807"
> + when the SoC being used is the Armada CN9130 with no external CP.
> +
> + - "marvell,cn9131", "marvell,cn9130",
> + "marvell,armada-ap807-quad", "marvell,armada-ap807"
> + when the SoC being used is the Armada CN9130 with one external CP.
> +
> + - "marvell,cn9132", "marvell,cn9131", "marvell,cn9130",
> + "marvell,armada-ap807-quad", "marvell,armada-ap807"
It's generally not all that useful to have all these compatibles.
> + when the SoC being used is the Armada CN9130 with two external CPs.
Is the number of external CPs not discoverable somewhere else in the DT?
> +
> Example:
>
> compatible = "marvell,armada7040-db", "marvell,armada7040",
> --
> 2.20.1
>
_______________________________________________
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 03/20] dt-bindings: ap80x: replace AP806 with AP80x
From: Rob Herring @ 2019-08-21 19:32 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Yan Markman, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Maxime Chevallier,
Nadav Haklai, Thomas Petazzoni, Miquel Raynal, Stefan Chulski,
Marcin Wojtas, Ben Peled, linux-arm-kernel
In-Reply-To: <20190806145500.24109-4-miquel.raynal@bootlin.com>
On Tue, 6 Aug 2019 16:54:43 +0200, Miquel Raynal wrote:
> From: Ben Peled <bpeled@marvell.com>
>
> Rename the text file and update "AP806" into "AP806/AP807" where
> relevant.
>
> Signed-off-by: Ben Peled <bpeled@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> ...-controller.txt => ap80x-system-controller.txt} | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
> rename Documentation/devicetree/bindings/arm/marvell/{ap806-system-controller.txt => ap80x-system-controller.txt} (91%)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v3 1/6] dt-bindings: thermal: Add DT bindings documentation for Amlogic Thermal
From: Rob Herring @ 2019-08-21 19:31 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20190806130506.8753-2-glaroque@baylibre.com>
On Tue, Aug 06, 2019 at 03:05:01PM +0200, Guillaume La Roque wrote:
> Adding the devicetree binding documentation for the Amlogic temperature
> sensor found in the Amlogic Meson G12 SoCs.
> the G12A and G12B SoCs are supported.
>
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> ---
> .../bindings/thermal/amlogic,thermal.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>
> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> new file mode 100644
> index 000000000000..d25e59113398
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/amlogic,thermal.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Amlogic Thermal
> +
> +maintainers:
> + - Guillaume La Roque <glaroque@baylibre.com>
> +
> +description: Binding for Amlogic Thermal Driver
Bindings are for h/w blocks, not drivers.
Other than that nit,
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 0/2] Coresight: Fix for v5.3-rc5
From: Mathieu Poirier @ 2019-08-21 19:28 UTC (permalink / raw)
To: Greg KH; +Cc: linux-arm-kernel
In-Reply-To: <20190820194155.28992-1-mathieu.poirier@linaro.org>
On Tue, 20 Aug 2019 at 13:41, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
>
> Good day,
>
> Please see if you can add the following fix to the current cycle. If
> you think it is a little late I'll simply lump them with the set I
> have for v5.4.
I found an issue with a corner case - please ignore this request.
>
> Applies cleanly to your char-misc-linus (d1abaeb3be7b) branch.
>
> Thanks,
> Mathieu
>
>
> Yabin Cui (2):
> coresight: tmc-etr: Fix updating buffer in not-snapshot mode
> coresight: tmc-etr: Fix perf_data check
>
> .../hwtracing/coresight/coresight-tmc-etr.c | 26 +++++++++++--------
> drivers/hwtracing/coresight/coresight-tmc.h | 6 ++---
> 2 files changed, 18 insertions(+), 14 deletions(-)
>
> --
> 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
* Re: [PATCHv3 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1028a-pcie"
From: Rob Herring @ 2019-08-21 19:26 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, kstewart, linux-pci, shawn.lin, minghuan.Lian,
shawnguo, lorenzo.pieralisi, kishon, mingkai.hu, devicetree, arnd,
Hou Zhiqiang, robh+dt, bhelgaas, linux-arm-kernel, roy.zang,
Xiaowei Bao, gregkh, linux-kernel, leoyang.li, pombredanne,
linuxppc-dev
In-Reply-To: <20190806061553.19934-1-xiaowei.bao@nxp.com>
On Tue, 6 Aug 2019 14:15:51 +0800, Xiaowei Bao wrote:
> Add the PCIe compatible string for LS1028A
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> ---
> v2:
> - no change.
> v3:
> - no change.
>
> Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: CPUfreq fail on rk3399-firefly (was: next/master boot: 285 boots: 16 failed, 264 passed with 3 offline, 1 untried/unknown, 1 conflict (next-20190718))
From: Kevin Hilman @ 2019-08-21 18:59 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip, Mark Brown, linux-next, linux-arm-kernel,
kernel-build-reports
In-Reply-To: <2314814.WbdfqDVNqK@phil>
Hi Heiko,
Heiko Stuebner <heiko@sntech.de> writes:
> Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
>> [ resent with correct addr for linux-rockchip list ]
>>
>> Mark Brown <broonie@kernel.org> writes:
>>
>> > On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
>> >
>> > Today's -next started failing to boot defconfig on rk3399-firefly:
>> >
>> >> arm64:
>> >
>> >> defconfig:
>> >> gcc-8:
>> >> rk3399-firefly: 1 failed lab
>> >
>> > It hits a BUG() trying to set up cpufreq:
>> >
>> > [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
>> > [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
>> > [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
>> > [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
>> > [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
>> > [ 87.495335] ------------[ cut here ]------------
>> > [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
>> > [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>> >
>> > I'm struggling to see anything relevant in the diff from yesterday, the
>> > unlisted frequency warnings were there in the logs yesterday but no oops
>> > and I'm not seeing any changes in cpufreq, clk or anything relevant
>> > looking.
>> >
>> > Full bootlog and other info can be found here:
>> >
>> > https://kernelci.org/boot/id/5d302d8359b51498d049e983/
>>
>> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
>> makes the firefly board start working again.
>>
>> Note that the default defconfig enables the "performance" CPUfreq
>> governor as the default governor, so during kernel boot, it will always
>> switch to the max frequency.
>>
>> For fun, I set the default governor to "userspace" so the kernel
>> wouldn't make any OPP changes, and that leads to a slightly more
>> informative splat[1]
>>
>> There is still an OPP change happening because the detected OPP is not
>> one that's listed in the table, so it tries to change to a listed OPP
>> and fails in the bowels of clk_set_rate()
>
> Though I think that might only be a symptom as well.
> Both the PLL setting code as well as the actual cpu-clock implementation
> is unchanged since 2017 (and runs just fine on all boards in my farm).
>
> One source for these issues is often the regulator supplying the cpu
> going haywire - aka the voltage not matching the opp.
>
> As in this error-case it's CPU4 being set, this would mean it might
> be the big cluster supplied by the external syr825 (fan5355 clone)
> that might act up. In the Firefly-rk3399 case this is even stranger.
>
> There is a discrepancy between the "fcs,suspend-voltage-selector"
> between different bootloader versions (how the selection-pin is set up),
> so the kernel might actually write his requested voltage to the wrong
> register (not the one for actual voltage, but the second set used for
> the suspend voltage).
>
> Did you by chance swap bootloaders at some point in recent past?
No, haven't touched bootloader since I initially setup the board.
> I'd assume [2] might actually be the same issue last year, though
> the CI-logs are not available anymore it seems.
>
> Could you try to set the vdd_cpu_b regulator to disabled, so that
> cpufreq for this cluster defers and see what happens?
Yes, this change[1] definitely makes things boot reliably again, so
there's defintiely something a bit unstable with this regulator, at
least on this firefly.
Kevin
[1]
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index c706db0ee9ec..6b70bdcc3328 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -454,6 +454,7 @@
vdd_cpu_b: regulator@40 {
compatible = "silergy,syr827";
+ status = "disabled";
reg = <0x40>;
fcs,suspend-voltage-selector = <0>;
regulator-name = "vdd_cpu_b";
_______________________________________________
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] dt-bindings: rng: mtk-rng: Add documentation for MT8516
From: Rob Herring @ 2019-08-21 18:55 UTC (permalink / raw)
To: Fabien Parent
Cc: devicetree, linux-kernel, Fabien Parent, robh+dt, linux-mediatek,
linux-crypto, matthias.bgg, linux-arm-kernel
In-Reply-To: <20190805130215.20499-1-fparent@baylibre.com>
On Mon, 5 Aug 2019 15:02:15 +0200, Fabien Parent wrote:
> This commit adds the device-tree documentation for the RNG IP on the
> MediaTek MT8516 SoC.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks.
Rob
_______________________________________________
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 1/2] dt-bindings: pwm: pwm-mediatek: Add documentation for MT8516
From: Rob Herring @ 2019-08-21 18:53 UTC (permalink / raw)
To: Fabien Parent
Cc: mark.rutland, devicetree, linux-pwm, linux-kernel, robh+dt,
Fabien Parent, thierry.reding, linux-mediatek, matthias.bgg,
linux-arm-kernel
In-Reply-To: <20190805125848.15751-1-fparent@baylibre.com>
On Mon, 5 Aug 2019 14:58:47 +0200, Fabien Parent wrote:
> Add the device-tree documentation for the PWM IP on the MediaTek
> MT8516 SoCs.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 2/3] dt-bindings: cp110: document the new CP115 pinctrl compatible
From: Rob Herring @ 2019-08-21 18:53 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Yan Markman, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Maxime Chevallier,
Nadav Haklai, linux-gpio, Thomas Petazzoni, Miquel Raynal,
Stefan Chulski, Marcin Wojtas, Linus Walleij, linux-arm-kernel
In-Reply-To: <20190805101607.29811-3-miquel.raynal@bootlin.com>
On Mon, 5 Aug 2019 12:16:06 +0200, Miquel Raynal wrote:
> From: Grzegorz Jaszczyk <jaz@semihalf.com>
>
> A new compatible is going to be used for Armada CP115 pinctrl block,
> document it.
>
> Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
> [<miquel.raynal@bootlin.com>: split the documentation out of the
> driver commit]
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../bindings/arm/marvell/cp110-system-controller.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v9 3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Dave Martin @ 2019-08-21 18:46 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, linux-doc, Szabolcs Nagy, Catalin Marinas,
Kevin Brodsky, Will Deacon, linux-mm, Dave Hansen,
Andrey Konovalov, Andrew Morton, Vincenzo Frascino,
linux-arm-kernel
In-Reply-To: <20190821173352.yqfgaozi7nfhcofg@willie-the-truck>
On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > From: Vincenzo Frascino <vincenzo.frascino@arm.com>
> >
> > On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> > (EL0) to perform memory accesses through 64-bit pointers with a non-zero
> > top byte. However, such pointers were not allowed at the user-kernel
> > syscall ABI boundary.
> >
> > With the Tagged Address ABI patchset, it is now possible to pass tagged
> > pointers to the syscalls. Relax the requirements described in
> > tagged-pointers.rst to be compliant with the behaviours guaranteed by
> > the AArch64 Tagged Address ABI.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> > Acked-by: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> > Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > Documentation/arm64/tagged-pointers.rst | 23 ++++++++++++++++-------
> > 1 file changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
> > index 2acdec3ebbeb..04f2ba9b779e 100644
> > --- a/Documentation/arm64/tagged-pointers.rst
> > +++ b/Documentation/arm64/tagged-pointers.rst
> > @@ -20,7 +20,9 @@ Passing tagged addresses to the kernel
> > --------------------------------------
> >
> > All interpretation of userspace memory addresses by the kernel assumes
> > -an address tag of 0x00.
> > +an address tag of 0x00, unless the application enables the AArch64
> > +Tagged Address ABI explicitly
> > +(Documentation/arm64/tagged-address-abi.rst).
> >
> > This includes, but is not limited to, addresses found in:
> >
> > @@ -33,13 +35,15 @@ This includes, but is not limited to, addresses found in:
> > - the frame pointer (x29) and frame records, e.g. when interpreting
> > them to generate a backtrace or call graph.
> >
> > -Using non-zero address tags in any of these locations may result in an
> > -error code being returned, a (fatal) signal being raised, or other modes
> > -of failure.
> > +Using non-zero address tags in any of these locations when the
> > +userspace application did not enable the AArch64 Tagged Address ABI may
> > +result in an error code being returned, a (fatal) signal being raised,
> > +or other modes of failure.
> >
> > -For these reasons, passing non-zero address tags to the kernel via
> > -system calls is forbidden, and using a non-zero address tag for sp is
> > -strongly discouraged.
> > +For these reasons, when the AArch64 Tagged Address ABI is disabled,
> > +passing non-zero address tags to the kernel via system calls is
> > +forbidden, and using a non-zero address tag for sp is strongly
> > +discouraged.
> >
> > Programs maintaining a frame pointer and frame records that use non-zero
> > address tags may suffer impaired or inaccurate debug and profiling
> > @@ -59,6 +63,11 @@ be preserved.
> > The architecture prevents the use of a tagged PC, so the upper byte will
> > be set to a sign-extension of bit 55 on exception return.
> >
> > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > +enabled. In addition, with the exceptions above, the kernel will
> > +preserve any non-zero tags passed by the user via syscalls and stored in
> > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
sigaltstack() is interesting, since we don't support tagged stacks.
Do we keep the ss_sp tag in the kernel, but squash it when delivering
a signal to the alternate stack?
(I can't remember whether this would be compatible with the
architectural tag checking semantics...)
> Hmm. I can see the need to provide this guarantee for things like
> set_robust_list(), but the problem is that the statement above is too broad
> and isn't strictly true: for example, mmap() doesn't propagate the tag of
> its address parameter into the VMA.
>
> So I think we need to nail this down a bit more, but I'm having a really
> hard time coming up with some wording :(
Time for some creative vagueness?
We can write a statement of our overall intent, along with examples of
a few cases where the tag should and should not be expected to emerge
intact.
There is no foolproof rule, unless we can rewrite history...
Cheers
---Dave
_______________________________________________
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 05/12] irqchip/gic: Prepare for more than 16 PPIs
From: Zenghui Yu @ 2019-08-21 18:40 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner, Jason Cooper, Julien Thierry,
Rob Herring
Cc: Lokesh Vutla, John Garry, linux-kernel, Shameerali Kolothum Thodi,
linux-arm-kernel
In-Reply-To: <20190806100121.240767-6-maz@kernel.org>
On 2019/8/6 18:01, Marc Zyngier wrote:
> GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs),
^^^^^^
legacy?
Zenghui
> meaning we can't just leave the old 16 hardcoded everywhere.
>
> We also need to add the infrastructure to discover the number of PPIs
> on a per redistributor basis, although we still pretend there is only
> 16 of them for now.
>
> No functional change.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
_______________________________________________
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] mm: consolidate pgtable_cache_init() and pgd_cache_init()
From: Thomas Gleixner @ 2019-08-21 18:36 UTC (permalink / raw)
To: Mike Rapoport
Cc: Catalin Marinas, x86, linux-kernel, linux-mm, Ingo Molnar,
Borislav Petkov, Andrew Morton, Will Deacon, linux-arm-kernel
In-Reply-To: <1566400018-15607-1-git-send-email-rppt@linux.ibm.com>
On Wed, 21 Aug 2019, Mike Rapoport wrote:
> diff --git a/arch/x86/include/asm/pgtable_32.h b/arch/x86/include/asm/pgtable_32.h
> index b9b9f8a..0dca7f7 100644
> --- a/arch/x86/include/asm/pgtable_32.h
> +++ b/arch/x86/include/asm/pgtable_32.h
> @@ -29,7 +29,6 @@ extern pgd_t swapper_pg_dir[1024];
> extern pgd_t initial_page_table[1024];
> extern pmd_t initial_pg_pmd[];
>
> -static inline void pgtable_cache_init(void) { }
> void paging_init(void);
> void sync_initial_page_table(void);
>
> diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
> index a26d2d5..0b6c4042 100644
> --- a/arch/x86/include/asm/pgtable_64.h
> +++ b/arch/x86/include/asm/pgtable_64.h
> @@ -241,8 +241,6 @@ extern void cleanup_highmap(void);
> #define HAVE_ARCH_UNMAPPED_AREA
> #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>
> -#define pgtable_cache_init() do { } while (0)
> -
> #define PAGE_AGP PAGE_KERNEL_NOCACHE
> #define HAVE_PAGE_AGP 1
>
> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> index 73757bc..3e4b903 100644
> --- a/arch/x86/mm/pgtable.c
> +++ b/arch/x86/mm/pgtable.c
> @@ -357,7 +357,7 @@ static void pgd_prepopulate_user_pmd(struct mm_struct *mm,
>
> static struct kmem_cache *pgd_cache;
>
> -void __init pgd_cache_init(void)
> +void __init pgtable_cache_init(void)
> {
> /*
> * When PAE kernel is running as a Xen domain, it does not use
> @@ -402,10 +402,6 @@ static inline void _pgd_free(pgd_t *pgd)
> }
> #else
>
> -void __init pgd_cache_init(void)
> -{
> -}
Acked-by: Thomas Gleixner <tglx@linutronix.de>
_______________________________________________
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 1/3] dt-bindings: fsl: dspi: Add fsl,ls1088a-dspi compatible string
From: Rob Herring @ 2019-08-21 18:34 UTC (permalink / raw)
To: Chuanhua Han
Cc: mark.rutland, devicetree, linux-kernel, robh+dt, linux-spi,
broonie, Chuanhua Han, leoyang.li, shawnguo, linux-arm-kernel
In-Reply-To: <20190801083105.30102-1-chuanhua.han@nxp.com>
On Thu, 1 Aug 2019 16:31:03 +0800, Chuanhua Han wrote:
> new compatible string: "fsl,ls1088a-dspi".
>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
> ---
> Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 17/17] arm64, kexec: enable MMU during kexec relocation
From: Pavel Tatashin @ 2019-08-21 18:32 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, matthias.bgg, bhsharma, linux-mm,
mark.rutland
In-Reply-To: <20190821183204.23576-1-pasha.tatashin@soleen.com>
Now, that we have transitional page tables configured, temporarily enable
MMU to allow faster relocation of segments to final destination.
The performance data: for a moderate size kernel + initramfs: 25M the
relocation was taking 0.382s, with enabled MMU it now takes
0.019s only or x20 improvement.
The time is proportional to the size of relocation, therefore if initramfs
is larger, 100M it could take over a second.
Also, remove reloc_arg->head, as it is not needed anymore once MMU is
enabled.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
arch/arm64/include/asm/kexec.h | 2 -
arch/arm64/kernel/asm-offsets.c | 1 -
arch/arm64/kernel/machine_kexec.c | 1 -
arch/arm64/kernel/relocate_kernel.S | 136 +++++++++++++++++-----------
4 files changed, 84 insertions(+), 56 deletions(-)
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 450d8440f597..ad81ed3e5751 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -109,7 +109,6 @@ extern const unsigned long kexec_el1_sync_size;
((UL(0xffffffffffffffff) - PAGE_OFFSET) >> 1) + 1)
/*
* kern_reloc_arg is passed to kernel relocation function as an argument.
- * head kimage->head, allows to traverse through relocation segments.
* entry_addr kimage->start, where to jump from relocation function (new
* kernel, or purgatory entry address).
* kern_arg0 first argument to kernel is its dtb address. The other
@@ -125,7 +124,6 @@ extern const unsigned long kexec_el1_sync_size;
* copy_len Number of bytes that need to be copied
*/
struct kern_reloc_arg {
- unsigned long head;
unsigned long entry_addr;
unsigned long kern_arg0;
unsigned long kern_arg1;
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7c2ba09a8ceb..13ad00b1b90f 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -129,7 +129,6 @@ int main(void)
DEFINE(SDEI_EVENT_PRIORITY, offsetof(struct sdei_registered_event, priority));
#endif
#ifdef CONFIG_KEXEC_CORE
- DEFINE(KRELOC_HEAD, offsetof(struct kern_reloc_arg, head));
DEFINE(KRELOC_ENTRY_ADDR, offsetof(struct kern_reloc_arg, entry_addr));
DEFINE(KRELOC_KERN_ARG0, offsetof(struct kern_reloc_arg, kern_arg0));
DEFINE(KRELOC_KERN_ARG1, offsetof(struct kern_reloc_arg, kern_arg1));
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 235cf2a5f007..41427c553f2b 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -199,7 +199,6 @@ int machine_kexec_post_load(struct kimage *kimage)
kimage->arch.kern_reloc = kern_reloc;
kimage->arch.kern_reloc_arg = __pa(kern_reloc_arg);
- kern_reloc_arg->head = kimage->head;
kern_reloc_arg->entry_addr = kimage->start;
kern_reloc_arg->el2_vector = el2_vector;
kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index 14243a678277..96ff6760bd9c 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -4,6 +4,8 @@
*
* Copyright (C) Linaro.
* Copyright (C) Huawei Futurewei Technologies.
+ * Copyright (c) 2019, Microsoft Corporation.
+ * Pavel Tatashin <patatash@linux.microsoft.com>
*/
#include <linux/kexec.h>
@@ -14,6 +16,49 @@
#include <asm/page.h>
#include <asm/sysreg.h>
+/* Invalidae TLB */
+.macro tlb_invalidate
+ dsb sy
+ dsb ish
+ tlbi vmalle1
+ dsb ish
+ isb
+.endm
+
+/* Turn-off mmu at level specified by sctlr */
+.macro turn_off_mmu sctlr, tmp1, tmp2
+ mrs \tmp1, \sctlr
+ ldr \tmp2, =SCTLR_ELx_FLAGS
+ bic \tmp1, \tmp1, \tmp2
+ pre_disable_mmu_workaround
+ msr \sctlr, \tmp1
+ isb
+.endm
+
+/* Turn-on mmu at level specified by sctlr */
+.macro turn_on_mmu sctlr, tmp1, tmp2
+ mrs \tmp1, \sctlr
+ ldr \tmp2, =SCTLR_ELx_FLAGS
+ orr \tmp1, \tmp1, \tmp2
+ msr \sctlr, \tmp1
+ ic iallu
+ dsb nsh
+ isb
+.endm
+
+/*
+ * Set ttbr0 and ttbr1, called while MMU is disabled, so no need to temporarily
+ * set zero_page table. Invalidate TLB after new tables are set.
+ */
+.macro set_ttbr arg, tmp
+ ldr \tmp, [\arg, #KRELOC_TRANS_TTBR0]
+ msr ttbr0_el1, \tmp
+ ldr \tmp, [\arg, #KRELOC_TRANS_TTBR1]
+ offset_ttbr1 \tmp
+ msr ttbr1_el1, \tmp
+ isb
+.endm
+
/*
* arm64_relocate_new_kernel - Put a 2nd stage image in place and boot it.
*
@@ -24,65 +69,52 @@
* symbols arm64_relocate_new_kernel and arm64_relocate_new_kernel_end. The
* machine_kexec() routine will copy arm64_relocate_new_kernel to the kexec
* safe memory that has been set up to be preserved during the copy operation.
+ *
+ * This function temporarily enables MMU if kernel relocation is needed.
+ * Also, if we enter this function at EL2 on non-VHE kernel, we temporarily go
+ * to EL1 to enable MMU, and escalate back to EL2 at the end to do the jump to
+ * the new kernel. This is determined by presence of el2_vector.
*/
ENTRY(arm64_relocate_new_kernel)
- /* Clear the sctlr_el2 flags. */
- mrs x2, CurrentEL
- cmp x2, #CurrentEL_EL2
+ mrs x1, CurrentEL
+ cmp x1, #CurrentEL_EL2
b.ne 1f
- mrs x2, sctlr_el2
- ldr x1, =SCTLR_ELx_FLAGS
- bic x2, x2, x1
- pre_disable_mmu_workaround
- msr sctlr_el2, x2
- isb
-1: /* Check if the new image needs relocation. */
- ldr x16, [x0, #KRELOC_HEAD] /* x16 = kimage_head */
- tbnz x16, IND_DONE_BIT, .Ldone
- raw_dcache_line_size x15, x1 /* x15 = dcache line size */
-.Lloop:
- and x12, x16, PAGE_MASK /* x12 = addr */
- /* Test the entry flags. */
-.Ltest_source:
- tbz x16, IND_SOURCE_BIT, .Ltest_indirection
-
- /* Invalidate dest page to PoC. */
- mov x2, x13
- add x20, x2, #PAGE_SIZE
- sub x1, x15, #1
- bic x2, x2, x1
-2: dc ivac, x2
- add x2, x2, x15
- cmp x2, x20
- b.lo 2b
- dsb sy
-
- copy_page x13, x12, x1, x2, x3, x4, x5, x6, x7, x8
- b .Lnext
-.Ltest_indirection:
- tbz x16, IND_INDIRECTION_BIT, .Ltest_destination
- mov x14, x12 /* ptr = addr */
- b .Lnext
-.Ltest_destination:
- tbz x16, IND_DESTINATION_BIT, .Lnext
- mov x13, x12 /* dest = addr */
-.Lnext:
- ldr x16, [x14], #8 /* entry = *ptr++ */
- tbz x16, IND_DONE_BIT, .Lloop /* while (!(entry & DONE)) */
-.Ldone:
- /* wait for writes from copy_page to finish */
- dsb nsh
- ic iallu
- dsb nsh
- isb
-
- /* Start new image. */
- ldr x4, [x0, #KRELOC_ENTRY_ADDR] /* x4 = kimage_start */
+ turn_off_mmu sctlr_el2, x1, x2 /* Turn off MMU at EL2 */
+1: mov x20, xzr /* x20 will hold vector value */
+ ldr x11, [x0, #KRELOC_COPY_LEN]
+ cbz x11, 5f /* Check if need to relocate */
+ ldr x20, [x0, #KRELOC_EL2_VECTOR]
+ cbz x20, 2f /* need to reduce to EL1? */
+ msr vbar_el2, x20 /* el2_vector present, means */
+ adr x1, 2f /* we will do copy in el1 but */
+ msr elr_el2, x1 /* do final jump from el2 */
+ eret /* Reduce to EL1 */
+2: set_ttbr x0, x1 /* Set our page tables */
+ tlb_invalidate
+ turn_on_mmu sctlr_el1, x1, x2 /* Turn MMU back on */
+ ldr x1, [x0, #KRELOC_DST_ADDR];
+ ldr x2, [x0, #KRELOC_SRC_ADDR];
+ mov x12, x1 /* x12 dst backup */
+3: copy_page x1, x2, x3, x4, x5, x6, x7, x8, x9, x10
+ sub x11, x11, #PAGE_SIZE
+ cbnz x11, 3b /* page copy loop */
+ raw_dcache_line_size x2, x3 /* x2 = dcache line size */
+ sub x3, x2, #1 /* x3 = dcache_size - 1 */
+ bic x12, x12, x3
+4: dc cvau, x12 /* Flush D-cache */
+ add x12, x12, x2
+ cmp x12, x1 /* Compare to dst + len */
+ b.ne 4b /* D-cache flush loop */
+ turn_off_mmu sctlr_el1, x1, x2 /* Turn off MMU */
+ tlb_invalidate /* Invalidate TLB */
+5: ldr x4, [x0, #KRELOC_ENTRY_ADDR] /* x4 = kimage_start */
ldr x3, [x0, #KRELOC_KERN_ARG3]
ldr x2, [x0, #KRELOC_KERN_ARG2]
ldr x1, [x0, #KRELOC_KERN_ARG1]
ldr x0, [x0, #KRELOC_KERN_ARG0] /* x0 = dtb address */
- br x4
+ cbnz x20, 6f /* need to escalate to el2? */
+ br x4 /* Jump to new world */
+6: hvc #0 /* enters kexec_el1_sync */
.ltorg
.Larm64_relocate_new_kernel_end:
END(arm64_relocate_new_kernel)
--
2.23.0
_______________________________________________
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 v3 16/17] arm64, kexec: configure trans_pgd page table for kexec
From: Pavel Tatashin @ 2019-08-21 18:32 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, matthias.bgg, bhsharma, linux-mm,
mark.rutland
In-Reply-To: <20190821183204.23576-1-pasha.tatashin@soleen.com>
Configure a page table located in kexec-safe memory that has
the following mappings:
1. identity mapping for text of relocation function with executable
permission.
2. identity mapping for argument for relocation function.
3. linear mappings for all source ranges
4. linear mappings for all destination ranges.
Also, configure el2_vector, that is used to jump to new kernel from EL2 on
non-VHE kernels.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
arch/arm64/include/asm/kexec.h | 32 +++++++
arch/arm64/kernel/asm-offsets.c | 6 ++
arch/arm64/kernel/machine_kexec.c | 129 ++++++++++++++++++++++++++--
arch/arm64/kernel/relocate_kernel.S | 16 +++-
4 files changed, 174 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index d5b79d4c7fae..450d8440f597 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -90,6 +90,23 @@ static inline void crash_prepare_suspend(void) {}
static inline void crash_post_resume(void) {}
#endif
+#if defined(CONFIG_KEXEC_CORE)
+/* Global variables for the arm64_relocate_new_kernel routine. */
+extern const unsigned char arm64_relocate_new_kernel[];
+extern const unsigned long arm64_relocate_new_kernel_size;
+
+/* Body of the vector for escalating to EL2 from relocation routine */
+extern const unsigned char kexec_el1_sync[];
+extern const unsigned long kexec_el1_sync_size;
+
+#define KEXEC_EL2_VECTOR_TABLE_SIZE 2048
+#define KEXEC_EL2_SYNC_OFFSET (KEXEC_EL2_VECTOR_TABLE_SIZE / 2)
+
+#endif
+
+#define KEXEC_SRC_START PAGE_OFFSET
+#define KEXEC_DST_START (PAGE_OFFSET + \
+ ((UL(0xffffffffffffffff) - PAGE_OFFSET) >> 1) + 1)
/*
* kern_reloc_arg is passed to kernel relocation function as an argument.
* head kimage->head, allows to traverse through relocation segments.
@@ -97,6 +114,15 @@ static inline void crash_post_resume(void) {}
* kernel, or purgatory entry address).
* kern_arg0 first argument to kernel is its dtb address. The other
* arguments are currently unused, and must be set to 0
+ * trans_ttbr0 idmap for relocation function and its argument
+ * trans_ttbr1 linear map for source/destination addresses.
+ * el2_vector If present means that relocation routine will go to EL1
+ * from EL2 to do the copy, and then back to EL2 to do the jump
+ * to new world. This vector contains only the final jump
+ * instruction at KEXEC_EL2_SYNC_OFFSET.
+ * src_addr linear map for source pages.
+ * dst_addr linear map for destination pages.
+ * copy_len Number of bytes that need to be copied
*/
struct kern_reloc_arg {
unsigned long head;
@@ -105,6 +131,12 @@ struct kern_reloc_arg {
unsigned long kern_arg1;
unsigned long kern_arg2;
unsigned long kern_arg3;
+ unsigned long trans_ttbr0;
+ unsigned long trans_ttbr1;
+ unsigned long el2_vector;
+ unsigned long src_addr;
+ unsigned long dst_addr;
+ unsigned long copy_len;
};
#define ARCH_HAS_KIMAGE_ARCH
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 900394907fd8..7c2ba09a8ceb 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -135,6 +135,12 @@ int main(void)
DEFINE(KRELOC_KERN_ARG1, offsetof(struct kern_reloc_arg, kern_arg1));
DEFINE(KRELOC_KERN_ARG2, offsetof(struct kern_reloc_arg, kern_arg2));
DEFINE(KRELOC_KERN_ARG3, offsetof(struct kern_reloc_arg, kern_arg3));
+ DEFINE(KRELOC_TRANS_TTBR0, offsetof(struct kern_reloc_arg, trans_ttbr0));
+ DEFINE(KRELOC_TRANS_TTBR1, offsetof(struct kern_reloc_arg, trans_ttbr1));
+ DEFINE(KRELOC_EL2_VECTOR, offsetof(struct kern_reloc_arg, el2_vector));
+ DEFINE(KRELOC_SRC_ADDR, offsetof(struct kern_reloc_arg, src_addr));
+ DEFINE(KRELOC_DST_ADDR, offsetof(struct kern_reloc_arg, dst_addr));
+ DEFINE(KRELOC_COPY_LEN, offsetof(struct kern_reloc_arg, copy_len));
#endif
return 0;
}
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index d745ea2051df..235cf2a5f007 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -20,13 +20,10 @@
#include <asm/mmu.h>
#include <asm/mmu_context.h>
#include <asm/page.h>
+#include <asm/trans_pgd.h>
#include "cpu-reset.h"
-/* Global variables for the arm64_relocate_new_kernel routine. */
-extern const unsigned char arm64_relocate_new_kernel[];
-extern const unsigned long arm64_relocate_new_kernel_size;
-
/**
* kexec_image_info - For debugging output.
*/
@@ -72,15 +69,128 @@ static void *kexec_page_alloc(void *arg)
return page_address(page);
}
+/*
+ * Map source segments starting from KEXEC_SRC_START, and map destination
+ * segments starting from KEXEC_DST_START, and return size of copy in
+ * *copy_len argument.
+ * Relocation function essentially needs to do:
+ * memcpy(KEXEC_DST_START, KEXEC_SRC_START, copy_len);
+ */
+static int map_segments(struct kimage *kimage, pgd_t *pgdp,
+ struct trans_pgd_info *info,
+ unsigned long *copy_len)
+{
+ unsigned long *ptr = 0;
+ unsigned long dest = 0;
+ unsigned long src_va = KEXEC_SRC_START;
+ unsigned long dst_va = KEXEC_DST_START;
+ unsigned long len = 0;
+ unsigned long entry, addr;
+ int rc;
+
+ for (entry = kimage->head; !(entry & IND_DONE); entry = *ptr++) {
+ addr = entry & PAGE_MASK;
+
+ switch (entry & IND_FLAGS) {
+ case IND_DESTINATION:
+ dest = addr;
+ break;
+ case IND_INDIRECTION:
+ ptr = __va(addr);
+ if (rc)
+ return rc;
+ break;
+ case IND_SOURCE:
+ rc = trans_pgd_map_page(info, pgdp, __va(addr),
+ src_va, PAGE_KERNEL);
+ if (rc)
+ return rc;
+ rc = trans_pgd_map_page(info, pgdp, __va(dest),
+ dst_va, PAGE_KERNEL);
+ if (rc)
+ return rc;
+ dest += PAGE_SIZE;
+ src_va += PAGE_SIZE;
+ dst_va += PAGE_SIZE;
+ len += PAGE_SIZE;
+ }
+ }
+ *copy_len = len;
+
+ return 0;
+}
+
+static int mmu_relocate_setup(struct kimage *kimage, unsigned long kern_reloc,
+ struct kern_reloc_arg *kern_reloc_arg)
+{
+ struct trans_pgd_info info = {
+ .trans_alloc_page = kexec_page_alloc,
+ .trans_alloc_arg = kimage,
+ .trans_flags = 0,
+ };
+ pgd_t *trans_ttbr0, *trans_ttbr1;
+ int rc;
+
+ rc = trans_pgd_create_empty(&info, &trans_ttbr0);
+ if (rc)
+ return rc;
+
+ rc = trans_pgd_create_empty(&info, &trans_ttbr1);
+ if (rc)
+ return rc;
+
+ rc = map_segments(kimage, trans_ttbr1, &info,
+ &kern_reloc_arg->copy_len);
+ if (rc)
+ return rc;
+
+ /* Map relocation function va == pa */
+ rc = trans_pgd_map_page(&info, trans_ttbr0, __va(kern_reloc),
+ kern_reloc, PAGE_KERNEL_EXEC);
+ if (rc)
+ return rc;
+
+ /* Map relocation function argument va == pa */
+ rc = trans_pgd_map_page(&info, trans_ttbr0, kern_reloc_arg,
+ __pa(kern_reloc_arg), PAGE_KERNEL);
+ if (rc)
+ return rc;
+
+ kern_reloc_arg->trans_ttbr0 = phys_to_ttbr(__pa(trans_ttbr0));
+ kern_reloc_arg->trans_ttbr1 = phys_to_ttbr(__pa(trans_ttbr1));
+ kern_reloc_arg->src_addr = KEXEC_SRC_START;
+ kern_reloc_arg->dst_addr = KEXEC_DST_START;
+
+ return 0;
+}
+
int machine_kexec_post_load(struct kimage *kimage)
{
+ unsigned long el2_vector = 0;
unsigned long kern_reloc;
struct kern_reloc_arg *kern_reloc_arg;
+ int rc = 0;
+
+ /*
+ * Sanity check that relocation function + el2_vector fit into one
+ * page.
+ */
+ if (arm64_relocate_new_kernel_size > KEXEC_EL2_VECTOR_TABLE_SIZE) {
+ pr_err("can't fit relocation function and el2_vector in one page");
+ return -ENOMEM;
+ }
kern_reloc = page_to_phys(kimage->control_code_page);
memcpy(__va(kern_reloc), arm64_relocate_new_kernel,
arm64_relocate_new_kernel_size);
+ /* Setup vector table only when EL2 is available, but no VHE */
+ if (is_hyp_mode_available() && !is_kernel_in_hyp_mode()) {
+ el2_vector = kern_reloc + KEXEC_EL2_VECTOR_TABLE_SIZE;
+ memcpy(__va(el2_vector + KEXEC_EL2_SYNC_OFFSET), kexec_el1_sync,
+ kexec_el1_sync_size);
+ }
+
kern_reloc_arg = kexec_page_alloc(kimage);
if (!kern_reloc_arg)
return -ENOMEM;
@@ -91,10 +201,19 @@ int machine_kexec_post_load(struct kimage *kimage)
kern_reloc_arg->head = kimage->head;
kern_reloc_arg->entry_addr = kimage->start;
+ kern_reloc_arg->el2_vector = el2_vector;
kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
+ /*
+ * If relocation is not needed, we do not need to enable MMU in
+ * relocation routine, therefore do not create page tables for
+ * scenarios such as crash kernel
+ */
+ if (!(kimage->head & IND_DONE))
+ rc = mmu_relocate_setup(kimage, kern_reloc, kern_reloc_arg);
+
kexec_image_info(kimage);
- return 0;
+ return rc;
}
/**
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index d352faf7cbe6..14243a678277 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -83,17 +83,25 @@ ENTRY(arm64_relocate_new_kernel)
ldr x1, [x0, #KRELOC_KERN_ARG1]
ldr x0, [x0, #KRELOC_KERN_ARG0] /* x0 = dtb address */
br x4
+.ltorg
+.Larm64_relocate_new_kernel_end:
END(arm64_relocate_new_kernel)
-.ltorg
+ENTRY(kexec_el1_sync)
+ br x4 /* Jump to new world from el2 */
+.Lkexec_el1_sync_end:
+END(kexec_el1_sync)
+
.align 3 /* To keep the 64-bit values below naturally aligned. */
-.Lcopy_end:
.org KEXEC_CONTROL_PAGE_SIZE
-
/*
* arm64_relocate_new_kernel_size - Number of bytes to copy to the
* control_code_page.
*/
.globl arm64_relocate_new_kernel_size
arm64_relocate_new_kernel_size:
- .quad .Lcopy_end - arm64_relocate_new_kernel
+ .quad .Larm64_relocate_new_kernel_end - arm64_relocate_new_kernel
+
+.globl kexec_el1_sync_size
+kexec_el1_sync_size:
+ .quad .Lkexec_el1_sync_end - kexec_el1_sync
--
2.23.0
_______________________________________________
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 v3 15/17] arm64, kexec: add expandable argument to relocation function
From: Pavel Tatashin @ 2019-08-21 18:32 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, matthias.bgg, bhsharma, linux-mm,
mark.rutland
In-Reply-To: <20190821183204.23576-1-pasha.tatashin@soleen.com>
Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
the following arguments:
head: start of array that contains relocation information.
entry: entry point for new kernel or purgatory.
dtb_mem: first and only argument to entry.
The number of arguments cannot be easily expended, because this
function is also called from HVC_SOFT_RESTART, which preserves only
three arguments. And, also arm64_relocate_new_kernel is written in
assembly but called without stack, thus no place to move extra
arguments to free registers.
Soon, we will need to pass more arguments: once we enable MMU we
will need to pass information about page tables.
Another benefit of allowing this function to accept more arguments, is that
kernel can actually accept up to 4 arguments (x0-x3), however currently
only one is used, but if in the future we will need for more (for example,
pass information about when previous kernel exited to have a precise
measurement in time spent in purgatory), we won't be easilty do that
if arm64_relocate_new_kernel can't accept more arguments.
So, add a new struct: kern_reloc_arg, and place it in kexec safe page (i.e
memory that is not overwritten during relocation).
Thus, make arm64_relocate_new_kernel to only take one argument, that
contains all the needed information.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
arch/arm64/include/asm/kexec.h | 18 ++++++
arch/arm64/kernel/asm-offsets.c | 9 +++
arch/arm64/kernel/cpu-reset.S | 4 +-
arch/arm64/kernel/cpu-reset.h | 8 +--
arch/arm64/kernel/machine_kexec.c | 28 ++++++++-
arch/arm64/kernel/relocate_kernel.S | 88 ++++++++++-------------------
6 files changed, 86 insertions(+), 69 deletions(-)
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index d15ca1ca1e83..d5b79d4c7fae 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -90,12 +90,30 @@ static inline void crash_prepare_suspend(void) {}
static inline void crash_post_resume(void) {}
#endif
+/*
+ * kern_reloc_arg is passed to kernel relocation function as an argument.
+ * head kimage->head, allows to traverse through relocation segments.
+ * entry_addr kimage->start, where to jump from relocation function (new
+ * kernel, or purgatory entry address).
+ * kern_arg0 first argument to kernel is its dtb address. The other
+ * arguments are currently unused, and must be set to 0
+ */
+struct kern_reloc_arg {
+ unsigned long head;
+ unsigned long entry_addr;
+ unsigned long kern_arg0;
+ unsigned long kern_arg1;
+ unsigned long kern_arg2;
+ unsigned long kern_arg3;
+};
+
#define ARCH_HAS_KIMAGE_ARCH
struct kimage_arch {
void *dtb;
unsigned long dtb_mem;
unsigned long kern_reloc;
+ unsigned long kern_reloc_arg;
};
#ifdef CONFIG_KEXEC_FILE
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 214685760e1c..900394907fd8 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -23,6 +23,7 @@
#include <asm/suspend.h>
#include <linux/kbuild.h>
#include <linux/arm-smccc.h>
+#include <linux/kexec.h>
int main(void)
{
@@ -126,6 +127,14 @@ int main(void)
#ifdef CONFIG_ARM_SDE_INTERFACE
DEFINE(SDEI_EVENT_INTREGS, offsetof(struct sdei_registered_event, interrupted_regs));
DEFINE(SDEI_EVENT_PRIORITY, offsetof(struct sdei_registered_event, priority));
+#endif
+#ifdef CONFIG_KEXEC_CORE
+ DEFINE(KRELOC_HEAD, offsetof(struct kern_reloc_arg, head));
+ DEFINE(KRELOC_ENTRY_ADDR, offsetof(struct kern_reloc_arg, entry_addr));
+ DEFINE(KRELOC_KERN_ARG0, offsetof(struct kern_reloc_arg, kern_arg0));
+ DEFINE(KRELOC_KERN_ARG1, offsetof(struct kern_reloc_arg, kern_arg1));
+ DEFINE(KRELOC_KERN_ARG2, offsetof(struct kern_reloc_arg, kern_arg2));
+ DEFINE(KRELOC_KERN_ARG3, offsetof(struct kern_reloc_arg, kern_arg3));
#endif
return 0;
}
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 6ea337d464c4..64c78a42919f 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -43,9 +43,7 @@ ENTRY(__cpu_soft_restart)
hvc #0 // no return
1: mov x18, x1 // entry
- mov x0, x2 // arg0
- mov x1, x3 // arg1
- mov x2, x4 // arg2
+ mov x0, x2 // arg
br x18
ENDPROC(__cpu_soft_restart)
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index ed50e9587ad8..7a8720ff186f 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -11,12 +11,10 @@
#include <asm/virt.h>
void __cpu_soft_restart(unsigned long el2_switch, unsigned long entry,
- unsigned long arg0, unsigned long arg1, unsigned long arg2);
+ unsigned long arg);
static inline void __noreturn cpu_soft_restart(unsigned long entry,
- unsigned long arg0,
- unsigned long arg1,
- unsigned long arg2)
+ unsigned long arg)
{
typeof(__cpu_soft_restart) *restart;
@@ -25,7 +23,7 @@ static inline void __noreturn cpu_soft_restart(unsigned long entry,
restart = (void *)__pa_symbol(__cpu_soft_restart);
cpu_install_idmap();
- restart(el2_switch, entry, arg0, arg1, arg2);
+ restart(el2_switch, entry, arg);
unreachable();
}
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 9b41da50e6f7..d745ea2051df 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -43,6 +43,7 @@ static void _kexec_image_info(const char *func, int line,
pr_debug(" head: %lx\n", kimage->head);
pr_debug(" nr_segments: %lu\n", kimage->nr_segments);
pr_debug(" kern_reloc: %pa\n", &kimage->arch.kern_reloc);
+ pr_debug(" kern_reloc_arg: %pa\n", &kimage->arch.kern_reloc_arg);
for (i = 0; i < kimage->nr_segments; i++) {
pr_debug(" segment[%lu]: %016lx - %016lx, 0x%lx bytes, %lu pages\n",
@@ -59,14 +60,38 @@ void machine_kexec_cleanup(struct kimage *kimage)
/* Empty routine needed to avoid build errors. */
}
+/* Allocates pages for kexec page table */
+static void *kexec_page_alloc(void *arg)
+{
+ struct kimage *kimage = (struct kimage *)arg;
+ struct page *page = kimage_alloc_control_pages(kimage, 0);
+
+ if (!page)
+ return NULL;
+
+ return page_address(page);
+}
+
int machine_kexec_post_load(struct kimage *kimage)
{
unsigned long kern_reloc;
+ struct kern_reloc_arg *kern_reloc_arg;
kern_reloc = page_to_phys(kimage->control_code_page);
memcpy(__va(kern_reloc), arm64_relocate_new_kernel,
arm64_relocate_new_kernel_size);
+
+ kern_reloc_arg = kexec_page_alloc(kimage);
+ if (!kern_reloc_arg)
+ return -ENOMEM;
+ memset(kern_reloc_arg, 0, sizeof(struct kern_reloc_arg));
+
kimage->arch.kern_reloc = kern_reloc;
+ kimage->arch.kern_reloc_arg = __pa(kern_reloc_arg);
+
+ kern_reloc_arg->head = kimage->head;
+ kern_reloc_arg->entry_addr = kimage->start;
+ kern_reloc_arg->kern_arg0 = kimage->arch.dtb_mem;
kexec_image_info(kimage);
return 0;
@@ -203,8 +228,7 @@ void machine_kexec(struct kimage *kimage)
* userspace (kexec-tools).
* In kexec_file case, the kernel starts directly without purgatory.
*/
- cpu_soft_restart(kimage->arch.kern_reloc, kimage->head, kimage->start,
- kimage->arch.dtb_mem);
+ cpu_soft_restart(kimage->arch.kern_reloc, kimage->arch.kern_reloc_arg);
BUG(); /* Should never get here. */
}
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index c1d7db71a726..d352faf7cbe6 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -8,7 +8,7 @@
#include <linux/kexec.h>
#include <linux/linkage.h>
-
+#include <asm/asm-offsets.h>
#include <asm/assembler.h>
#include <asm/kexec.h>
#include <asm/page.h>
@@ -17,86 +17,58 @@
/*
* arm64_relocate_new_kernel - Put a 2nd stage image in place and boot it.
*
- * The memory that the old kernel occupies may be overwritten when coping the
+ * The memory that the old kernel occupies may be overwritten when copying the
* new image to its final location. To assure that the
* arm64_relocate_new_kernel routine which does that copy is not overwritten,
* all code and data needed by arm64_relocate_new_kernel must be between the
* symbols arm64_relocate_new_kernel and arm64_relocate_new_kernel_end. The
* machine_kexec() routine will copy arm64_relocate_new_kernel to the kexec
- * control_code_page, a special page which has been set up to be preserved
- * during the copy operation.
+ * safe memory that has been set up to be preserved during the copy operation.
*/
ENTRY(arm64_relocate_new_kernel)
-
- /* Setup the list loop variables. */
- mov x18, x2 /* x18 = dtb address */
- mov x17, x1 /* x17 = kimage_start */
- mov x16, x0 /* x16 = kimage_head */
- raw_dcache_line_size x15, x0 /* x15 = dcache line size */
- mov x14, xzr /* x14 = entry ptr */
- mov x13, xzr /* x13 = copy dest */
-
/* Clear the sctlr_el2 flags. */
- mrs x0, CurrentEL
- cmp x0, #CurrentEL_EL2
+ mrs x2, CurrentEL
+ cmp x2, #CurrentEL_EL2
b.ne 1f
- mrs x0, sctlr_el2
+ mrs x2, sctlr_el2
ldr x1, =SCTLR_ELx_FLAGS
- bic x0, x0, x1
+ bic x2, x2, x1
pre_disable_mmu_workaround
- msr sctlr_el2, x0
+ msr sctlr_el2, x2
isb
-1:
-
- /* Check if the new image needs relocation. */
+1: /* Check if the new image needs relocation. */
+ ldr x16, [x0, #KRELOC_HEAD] /* x16 = kimage_head */
tbnz x16, IND_DONE_BIT, .Ldone
-
+ raw_dcache_line_size x15, x1 /* x15 = dcache line size */
.Lloop:
and x12, x16, PAGE_MASK /* x12 = addr */
-
/* Test the entry flags. */
.Ltest_source:
tbz x16, IND_SOURCE_BIT, .Ltest_indirection
/* Invalidate dest page to PoC. */
- mov x0, x13
- add x20, x0, #PAGE_SIZE
+ mov x2, x13
+ add x20, x2, #PAGE_SIZE
sub x1, x15, #1
- bic x0, x0, x1
-2: dc ivac, x0
- add x0, x0, x15
- cmp x0, x20
+ bic x2, x2, x1
+2: dc ivac, x2
+ add x2, x2, x15
+ cmp x2, x20
b.lo 2b
dsb sy
- mov x20, x13
- mov x21, x12
- copy_page x20, x21, x0, x1, x2, x3, x4, x5, x6, x7
-
- /* dest += PAGE_SIZE */
- add x13, x13, PAGE_SIZE
+ copy_page x13, x12, x1, x2, x3, x4, x5, x6, x7, x8
b .Lnext
-
.Ltest_indirection:
tbz x16, IND_INDIRECTION_BIT, .Ltest_destination
-
- /* ptr = addr */
- mov x14, x12
+ mov x14, x12 /* ptr = addr */
b .Lnext
-
.Ltest_destination:
tbz x16, IND_DESTINATION_BIT, .Lnext
-
- /* dest = addr */
- mov x13, x12
-
+ mov x13, x12 /* dest = addr */
.Lnext:
- /* entry = *ptr++ */
- ldr x16, [x14], #8
-
- /* while (!(entry & DONE)) */
- tbz x16, IND_DONE_BIT, .Lloop
-
+ ldr x16, [x14], #8 /* entry = *ptr++ */
+ tbz x16, IND_DONE_BIT, .Lloop /* while (!(entry & DONE)) */
.Ldone:
/* wait for writes from copy_page to finish */
dsb nsh
@@ -105,18 +77,16 @@ ENTRY(arm64_relocate_new_kernel)
isb
/* Start new image. */
- mov x0, x18
- mov x1, xzr
- mov x2, xzr
- mov x3, xzr
- br x17
-
-ENDPROC(arm64_relocate_new_kernel)
+ ldr x4, [x0, #KRELOC_ENTRY_ADDR] /* x4 = kimage_start */
+ ldr x3, [x0, #KRELOC_KERN_ARG3]
+ ldr x2, [x0, #KRELOC_KERN_ARG2]
+ ldr x1, [x0, #KRELOC_KERN_ARG1]
+ ldr x0, [x0, #KRELOC_KERN_ARG0] /* x0 = dtb address */
+ br x4
+END(arm64_relocate_new_kernel)
.ltorg
-
.align 3 /* To keep the 64-bit values below naturally aligned. */
-
.Lcopy_end:
.org KEXEC_CONTROL_PAGE_SIZE
--
2.23.0
_______________________________________________
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 v3 14/17] arm64, kexec: move relocation function setup and clean up
From: Pavel Tatashin @ 2019-08-21 18:32 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, matthias.bgg, bhsharma, linux-mm,
mark.rutland
In-Reply-To: <20190821183204.23576-1-pasha.tatashin@soleen.com>
Currently, kernel relocation function is configured in machine_kexec()
at the time of kexec reboot by using control_code_page.
This operation, however, is more logical to be done during kexec_load,
and thus remove from reboot time. Move, setup of this function to
newly added machine_kexec_post_load().
In addition, do some cleanup: add infor about reloction function to
kexec_image_info(), and remove extra messages from machine_kexec().
Make dtb_mem, always available, if CONFIG_KEXEC_FILE is not configured
dtb_mem is set to zero anyway.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
arch/arm64/include/asm/kexec.h | 3 +-
arch/arm64/kernel/machine_kexec.c | 49 +++++++++++--------------------
2 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 12a561a54128..d15ca1ca1e83 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -90,14 +90,15 @@ static inline void crash_prepare_suspend(void) {}
static inline void crash_post_resume(void) {}
#endif
-#ifdef CONFIG_KEXEC_FILE
#define ARCH_HAS_KIMAGE_ARCH
struct kimage_arch {
void *dtb;
unsigned long dtb_mem;
+ unsigned long kern_reloc;
};
+#ifdef CONFIG_KEXEC_FILE
extern const struct kexec_file_ops kexec_image_ops;
struct kimage;
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 0df8493624e0..9b41da50e6f7 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -42,6 +42,7 @@ static void _kexec_image_info(const char *func, int line,
pr_debug(" start: %lx\n", kimage->start);
pr_debug(" head: %lx\n", kimage->head);
pr_debug(" nr_segments: %lu\n", kimage->nr_segments);
+ pr_debug(" kern_reloc: %pa\n", &kimage->arch.kern_reloc);
for (i = 0; i < kimage->nr_segments; i++) {
pr_debug(" segment[%lu]: %016lx - %016lx, 0x%lx bytes, %lu pages\n",
@@ -58,6 +59,19 @@ void machine_kexec_cleanup(struct kimage *kimage)
/* Empty routine needed to avoid build errors. */
}
+int machine_kexec_post_load(struct kimage *kimage)
+{
+ unsigned long kern_reloc;
+
+ kern_reloc = page_to_phys(kimage->control_code_page);
+ memcpy(__va(kern_reloc), arm64_relocate_new_kernel,
+ arm64_relocate_new_kernel_size);
+ kimage->arch.kern_reloc = kern_reloc;
+
+ kexec_image_info(kimage);
+ return 0;
+}
+
/**
* machine_kexec_prepare - Prepare for a kexec reboot.
*
@@ -67,8 +81,6 @@ void machine_kexec_cleanup(struct kimage *kimage)
*/
int machine_kexec_prepare(struct kimage *kimage)
{
- kexec_image_info(kimage);
-
if (kimage->type != KEXEC_TYPE_CRASH && cpus_are_stuck_in_kernel()) {
pr_err("Can't kexec: CPUs are stuck in the kernel.\n");
return -EBUSY;
@@ -143,8 +155,7 @@ static void kexec_segment_flush(const struct kimage *kimage)
*/
void machine_kexec(struct kimage *kimage)
{
- phys_addr_t reboot_code_buffer_phys;
- void *reboot_code_buffer;
+ void *reboot_code_buffer = phys_to_virt(kimage->arch.kern_reloc);
bool in_kexec_crash = (kimage == kexec_crash_image);
bool stuck_cpus = cpus_are_stuck_in_kernel();
@@ -155,30 +166,8 @@ void machine_kexec(struct kimage *kimage)
WARN(in_kexec_crash && (stuck_cpus || smp_crash_stop_failed()),
"Some CPUs may be stale, kdump will be unreliable.\n");
- reboot_code_buffer_phys = page_to_phys(kimage->control_code_page);
- reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys);
-
kexec_image_info(kimage);
- pr_debug("%s:%d: control_code_page: %p\n", __func__, __LINE__,
- kimage->control_code_page);
- pr_debug("%s:%d: reboot_code_buffer_phys: %pa\n", __func__, __LINE__,
- &reboot_code_buffer_phys);
- pr_debug("%s:%d: reboot_code_buffer: %p\n", __func__, __LINE__,
- reboot_code_buffer);
- pr_debug("%s:%d: relocate_new_kernel: %p\n", __func__, __LINE__,
- arm64_relocate_new_kernel);
- pr_debug("%s:%d: relocate_new_kernel_size: 0x%lx(%lu) bytes\n",
- __func__, __LINE__, arm64_relocate_new_kernel_size,
- arm64_relocate_new_kernel_size);
-
- /*
- * Copy arm64_relocate_new_kernel to the reboot_code_buffer for use
- * after the kernel is shut down.
- */
- memcpy(reboot_code_buffer, arm64_relocate_new_kernel,
- arm64_relocate_new_kernel_size);
-
/* Flush the reboot_code_buffer in preparation for its execution. */
__flush_dcache_area(reboot_code_buffer, arm64_relocate_new_kernel_size);
@@ -214,12 +203,8 @@ void machine_kexec(struct kimage *kimage)
* userspace (kexec-tools).
* In kexec_file case, the kernel starts directly without purgatory.
*/
- cpu_soft_restart(reboot_code_buffer_phys, kimage->head, kimage->start,
-#ifdef CONFIG_KEXEC_FILE
- kimage->arch.dtb_mem);
-#else
- 0);
-#endif
+ cpu_soft_restart(kimage->arch.kern_reloc, kimage->head, kimage->start,
+ kimage->arch.dtb_mem);
BUG(); /* Should never get here. */
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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