* Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
From: Miguel Ojeda @ 2019-08-23 19:35 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Will Deacon,
Daniel Borkmann, clang-built-linux, Allison Randal, Yonghong Song,
Masayoshi Mizuma, Suzuki K Poulose, Andrey Konovalov,
Shaokun Zhang, Alexios Zavras, Josh Poimboeuf, Sedat Dilek,
Thomas Gleixner, bpf, Linux ARM, Greg Kroah-Hartman, linux-kernel,
Network Development, Andrew Morton, Enrico Weigelt,
Martin KaFai Lau
In-Reply-To: <CANiq72nUyT-q3A9mTrYzPZ+J9Ya7Lns5MyTK7W7-7yXgFWc2xA@mail.gmail.com>
On Thu, Aug 15, 2019 at 11:12 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Btw, I guess that is the Oops you were mentioning in the cover letter?
Pinging about this...
Cheers,
Miguel
_______________________________________________
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/3] net: qca: update MODULE_AUTHOR() email address
From: Stefan Wahren @ 2019-08-23 19:16 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, David S. Miller, Srinivas Kandagatla,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: linux-hwmon, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1565720249-6549-3-git-send-email-wahrenst@gmx.net>
Am 13.08.19 um 20:17 schrieb Stefan Wahren:
> I2SE has been acquired by in-tech. So the email address listed in
> MODULE_AUTHOR() will be disabled in the near future. I only have access
> to QCA7000 boards at in-tech, so use my new company address.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Gentle ping ...
_______________________________________________
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 7/7] arm64: defconfig: Enable configs for S32V234
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
jslaby@suse.com, Cosmin Stefan Stoica,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
From: Mihaela Martinas <Mihaela.Martinas@freescale.com>
Enable support for the S32V234 SoC, including the previously added UART
driver.
Signed-off-by: Mihaela Martinas <Mihaela.Martinas@freescale.com>
Signed-off-by: Adrian.Nitu <adrian.nitu@freescale.com>
Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..bb5aa95a8455 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -48,6 +48,7 @@ CONFIG_ARCH_MXC=y
CONFIG_ARCH_QCOM=y
CONFIG_ARCH_RENESAS=y
CONFIG_ARCH_ROCKCHIP=y
+CONFIG_ARCH_S32=y
CONFIG_ARCH_SEATTLE=y
CONFIG_ARCH_STRATIX10=y
CONFIG_ARCH_SYNQUACER=y
@@ -347,6 +348,8 @@ CONFIG_SERIAL_XILINX_PS_UART=y
CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_SERIAL_FSL_LPUART=y
CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+CONFIG_SERIAL_FSL_LINFLEXUART=y
+CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE=y
CONFIG_SERIAL_MVEBU_UART=y
CONFIG_SERIAL_DEV_BUS=y
CONFIG_VIRTIO_CONSOLE=y
--
2.22.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 6/7] dt-bindings: serial: Document Freescale LINFlexD UART
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
Larisa Ileana Grigore, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, jslaby@suse.com,
Cosmin Stefan Stoica, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
From: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
Add documentation for the serial communication interface module (LINFlexD),
found in two instances on S32V234.
Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
Signed-off-by: Larisa Grigore <Larisa.Grigore@nxp.com>
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
---
.../bindings/serial/fsl,s32-linflexuart.txt | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt
diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt
new file mode 100644
index 000000000000..f1bbe0826be5
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt
@@ -0,0 +1,22 @@
+* Freescale LINFlexD UART
+
+The LINFlexD controller implements several LIN protocol versions, as well as
+support for full-duplex UART communication through 8-bit and 9-bit frames.
+
+See chapter 47 ("LINFlexD") in the reference manual[1].
+
+Required properties:
+- compatible :
+ - "fsl,s32v234-linflexuart" for LINFlexD configured in UART mode, which
+ is compatible with the one integrated on S32V234 SoC
+- reg : Address and length of the register set for the device
+- interrupts : Should contain uart interrupt
+
+Example:
+uart0: serial@40053000 {
+ compatible = "fsl,s32v234-linflexuart";
+ reg = <0x0 0x40053000 0x0 0x1000>;
+ interrupts = <0 59 4>;
+};
+
+[1] https://www.nxp.com/webapp/Download?colCode=S32V234RM
--
2.22.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 5/7] arm64: dts: fsl: Add device tree for S32V234-EVB
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
Larisa Ileana Grigore, linux-kernel@vger.kernel.org, Dan Nica,
linux-serial@vger.kernel.org, jslaby@suse.com,
Cosmin Stefan Stoica, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
From: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
Add initial version of device tree for S32V234-EVB, including nodes for the
4 Cortex-A53 cores, AIPS bus with UART modules, ARM architected timer and
Generic Interrupt Controller (GIC).
Keep SoC level separate from board level to let future boards with this SoC
share common properties, while the dts files will keep board-dependent
properties.
Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
Signed-off-by: Mihaela Martinas <Mihaela.Martinas@freescale.com>
Signed-off-by: Dan Nica <dan.nica@nxp.com>
Signed-off-by: Larisa Grigore <Larisa.Grigore@nxp.com>
Signed-off-by: Phu Luu An <phu.luuan@nxp.com>
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/s32v234-evb.dts | 25 ++++
arch/arm64/boot/dts/freescale/s32v234.dtsi | 139 ++++++++++++++++++
3 files changed, 166 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/s32v234-evb.dts
create mode 100644 arch/arm64/boot/dts/freescale/s32v234.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c043aca66572..9aff21324146 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -26,3 +26,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
+
+dtb-$(CONFIG_ARCH_S32) += s32v234-evb.dtb
diff --git a/arch/arm64/boot/dts/freescale/s32v234-evb.dts b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
new file mode 100644
index 000000000000..4b802518cefc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234-evb.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2017 NXP
+ */
+
+/dts-v1/;
+#include "s32v234.dtsi"
+
+/ {
+ model = "NXP S32V234-EVB2 Board";
+ compatible = "fsl,s32v234-evb", "fsl,s32v234";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/s32v234.dtsi b/arch/arm64/boot/dts/freescale/s32v234.dtsi
new file mode 100644
index 000000000000..37225191ccbf
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/s32v234.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2016-2018 NXP
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/memreserve/ 0x80000000 0x00010000;
+
+/ {
+ compatible = "fsl,s32v234";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80000000>;
+ next-level-cache = <&cluster0_l2_cache>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80000000>;
+ next-level-cache = <&cluster0_l2_cache>;
+ };
+
+ cpu2: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x100>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80000000>;
+ next-level-cache = <&cluster1_l2_cache>;
+ };
+
+ cpu3: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x101>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x0 0x80000000>;
+ next-level-cache = <&cluster1_l2_cache>;
+ };
+
+ cluster0_l2_cache: l2-cache0 {
+ compatible = "cache";
+ };
+
+ cluster1_l2_cache: l2-cache1 {
+ compatible = "cache";
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ /* clock-frequency might be modified by u-boot, depending on the
+ * chip version.
+ */
+ clock-frequency = <10000000>;
+ };
+
+ gic: interrupt-controller@7d001000 {
+ compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0x7d001000 0 0x1000>,
+ <0 0x7d002000 0 0x2000>,
+ <0 0x7d004000 0 0x2000>,
+ <0 0x7d006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ aips0: aips-bus@40000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&gic>;
+ reg = <0x0 0x40000000 0x0 0x7D000>;
+ ranges;
+
+ uart0: serial@40053000 {
+ compatible = "fsl,s32v234-linflexuart";
+ reg = <0x0 0x40053000 0x0 0x1000>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+ };
+
+ aips1: aips-bus@40080000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&gic>;
+ reg = <0x0 0x40080000 0x0 0x70000>;
+ ranges;
+
+ uart1: serial@400bc000 {
+ compatible = "fsl,s32v234-linflexuart";
+ reg = <0x0 0x400bc000 0x0 0x1000>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_EDGE_RISING>;
+ status = "disabled";
+ };
+ };
+ };
+};
--
2.22.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 4/7] serial: fsl_linflexuart: Be consistent with the name
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
jslaby@suse.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
For consistency reasons, spell the controller name as "LINFlexD" in
comments and documentation.
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
drivers/tty/serial/Kconfig | 8 ++++----
drivers/tty/serial/fsl_linflexuart.c | 4 ++--
include/uapi/linux/serial_core.h | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4d545732aadc..81773425fb31 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1091,7 +1091,7 @@
mapped with the correct attributes.
linflex,<addr>
- Use early console provided by Freescale LinFlex UART
+ Use early console provided by Freescale LINFlexD UART
serial driver for NXP S32V234 SoCs. A valid base
address must be provided, and the serial port must
already be setup and configured.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b4fa2f7c96bd..3039c1ff68a9 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1453,18 +1453,18 @@ config SERIAL_FSL_LPUART_CONSOLE
you can make it the console by answering Y to this option.
config SERIAL_FSL_LINFLEXUART
- tristate "Freescale linflexuart serial port support"
+ tristate "Freescale LINFlexD UART serial port support"
select SERIAL_CORE
help
- Support for the on-chip linflexuart on some Freescale SOCs.
+ Support for the on-chip LINFlexD UART on some Freescale SOCs.
config SERIAL_FSL_LINFLEXUART_CONSOLE
- bool "Console on Freescale linflexuart serial port"
+ bool "Console on Freescale LINFlexD UART serial port"
depends on SERIAL_FSL_LINFLEXUART=y
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
help
- If you have enabled the linflexuart serial port on the Freescale
+ If you have enabled the LINFlexD UART serial port on the Freescale
SoCs, you can make it the console by answering Y to this option.
config SERIAL_CONEXANT_DIGICOLOR
diff --git a/drivers/tty/serial/fsl_linflexuart.c b/drivers/tty/serial/fsl_linflexuart.c
index e54c65830e5e..b5889f8d80cb 100644
--- a/drivers/tty/serial/fsl_linflexuart.c
+++ b/drivers/tty/serial/fsl_linflexuart.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Freescale linflexuart serial port driver
+ * Freescale LINFlexD UART serial port driver
*
* Copyright 2012-2016 Freescale Semiconductor, Inc.
* Copyright 2017-2018 NXP
@@ -938,5 +938,5 @@ static void __exit linflex_serial_exit(void)
module_init(linflex_serial_init);
module_exit(linflex_serial_exit);
-MODULE_DESCRIPTION("Freescale linflex serial port driver");
+MODULE_DESCRIPTION("Freescale LINFlexD serial port driver");
MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index f9e829416dcc..33bd9c411a31 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -296,7 +296,7 @@
/* Sunix UART */
#define PORT_SUNIX 121
-/* Freescale Linflex UART */
-#define PORT_LINFLEXUART 121
+/* Freescale LINFlexD UART */
+#define PORT_LINFLEXUART 122
#endif /* _UAPILINUX_SERIAL_CORE_H */
--
2.22.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 3/7] serial: fsl_linflexuart: Update compatible string
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
jslaby@suse.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
The "fsl,s32-linflexuart" compatible string is too generic. Make it SoC
specific.
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
---
drivers/tty/serial/fsl_linflexuart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/fsl_linflexuart.c b/drivers/tty/serial/fsl_linflexuart.c
index 26b9601a0952..e54c65830e5e 100644
--- a/drivers/tty/serial/fsl_linflexuart.c
+++ b/drivers/tty/serial/fsl_linflexuart.c
@@ -127,7 +127,7 @@
static const struct of_device_id linflex_dt_ids[] = {
{
- .compatible = "fsl,s32-linflexuart",
+ .compatible = "fsl,s32v234-linflexuart",
},
{ /* sentinel */ }
};
@@ -801,7 +801,7 @@ static int __init linflex_early_console_setup(struct earlycon_device *device,
return 0;
}
-OF_EARLYCON_DECLARE(linflex, "fsl,s32-linflexuart",
+OF_EARLYCON_DECLARE(linflex, "fsl,s32v234-linflexuart",
linflex_early_console_setup);
#define LINFLEX_CONSOLE (&linflex_console)
--
2.22.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 2/7] arm64: Introduce config for S32
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
jslaby@suse.com, Cosmin Stefan Stoica,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
From: Mihaela Martinas <Mihaela.Martinas@freescale.com>
Add configuration option for the NXP S32 platform family in
Kconfig.platforms. For starters, the only SoC supported will be Treerunner
(S32V234), with a single execution target: the S32V234-EVB (rev 29288)
board.
Signed-off-by: Mihaela Martinas <Mihaela.Martinas@freescale.com>
Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
---
arch/arm64/Kconfig.platforms | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4778c775de1b..64bbe2d0b04f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -210,6 +210,11 @@ config ARCH_ROCKCHIP
This enables support for the ARMv8 based Rockchip chipsets,
like the RK3368.
+config ARCH_S32
+ bool "NXP S32 SoC Family"
+ help
+ This enables support for the NXP S32 family of processors.
+
config ARCH_SEATTLE
bool "AMD Seattle SoC Family"
help
--
2.22.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 1/7] dt-bindings: arm: fsl: Add the S32V234-EVB board
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, Eddy Petrisor,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, jslaby@suse.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823191115.18490-1-stefan-gabriel.mirea@nxp.com>
From: Eddy Petrișor <eddy.petrisor@nxp.com>
Add entry for the NXP S32V234 Customer Evaluation Board to the board/SoC
bindings.
Signed-off-by: Eddy Petrișor <eddy.petrisor@nxp.com>
Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..597c563bdec9 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -309,4 +309,10 @@ properties:
- fsl,ls2088a-rdb
- const: fsl,ls2088a
+ - description: S32V234 based Boards
+ items:
+ - enum:
+ - fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board
+ - const: fsl,s32v234
+
...
--
2.22.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 0/7] Add initial support for S32V234-EVB
From: Stefan-gabriel Mirea @ 2019-08-23 19:11 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
will@kernel.org, shawnguo@kernel.org, Leo Li
Cc: devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
jslaby@suse.com, linux-arm-kernel@lists.infradead.org
Hello,
NXP's S32V234[1] ("Treerunner") vision microprocessors are targeted for
high-performance, computationally intensive vision and sensor fusion
applications that require automotive safety levels. They include leading
edge Camera Vision modules like APEX-2, ISP and GPU. The S32V234-EVB and
S32V234-SBC boards are available for customer evaluation.
The following patch series introduces minimal enablement support for the
NXP S32V234-EVB2[2] board, which leverages most of the SoC capabilities.
Up to v2, this series also included the fsl_linflexuart driver, which has
been included in Greg Kroah-Hartman's tty git tree[3].
In the future, we aim to submit multiple drivers upstream, which can be
found in the kernel of our Auto Linux BSP[4] ("ALB"), starting with basic
pinmuxing, clock and uSDHC drivers.
For validation, you can use the U-Boot bootloader in the ALB[5], which we
build and test with our patched version of the Linaro GCC 6.3.1 2017.05
toolchain for ARM 64-bit, with sources available on [6].
Changes in v3:
* Remove the patch 'tty: serial: Add linflexuart driver for S32V234'
following its acceptance[3];
* Replace 'Freescale' with 'NXP' in the ARCH_S32 config definition and the
'model' property from the device tree;
* Remove the 'fsl-' prefixes from the dtsi and dts file names;
* Move the 'model' property from (fsl-)s32v234.dtsi to s32v234-evb.dts;
* Add newlines between the cpu nodes in s32v234.dtsi;
* Make use of GIC_SPI, GIC_PPI, GIC_CPU_MASK_SIMPLE and IRQ_TYPE_* in the
'interrupts' tuples;
* Move the 'timer' and 'interrupt-controller' nodes before 'soc' in
s32v234.dtsi;
* Be consistent with the 'LINFlexD' spelling in documentation, strings and
comments; add new patch 'serial: fsl_linflexuart: Be consistent with the
name' to update the LINFlexD driver as well;
* Remove from fsl,s32-linflexuart.txt a statement regarding the limitation
to UART mode;
* Make the compatible string SoC specific ("fsl,s32v234-linflexuart"); add
new patch 'serial: fsl_linflexuart: Update compatible string' to update
the LINFlexD driver as well;
* In the LINFlexD binding documentation, insert a space between label and
node name and remove the 'status' property.
Changes in v2:
* Update the entry in fsl.yaml to apply to all S32V234 based boards;
* Add chosen node to dts, with a 'stdout-path' property for earlycon;
* Remove linflex_verify_port(), because it was only called from
uart_set_info(), which was going to always fail at the "baud_base < 9600"
check, as we are not using uartclk from uart_port yet;
* Fix compatible string used in OF_EARLYCON_DECLARE.
[1] https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/s32-automotive-platform/vision-processor-for-front-and-surround-view-camera-machine-learning-and-sensor-fusion:S32V234
[2] https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/ultra-reliable-dev-platforms/s32v-mpus-platforms/s32v-vision-and-sensor-fusion-evaluation-system:S32V234EVB
[3] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=b953815b819b0f327b5538feba3639d52db70172
[4] https://source.codeaurora.org/external/autobsps32/linux/
[5] https://source.codeaurora.org/external/autobsps32/u-boot/
[6] https://source.codeaurora.org/external/s32ds/compiler/gcc/
Eddy Petrișor (1):
dt-bindings: arm: fsl: Add the S32V234-EVB board
Mihaela Martinas (2):
arm64: Introduce config for S32
arm64: defconfig: Enable configs for S32V234
Stefan-Gabriel Mirea (2):
serial: fsl_linflexuart: Update compatible string
serial: fsl_linflexuart: Be consistent with the name
Stoica Cosmin-Stefan (2):
arm64: dts: fsl: Add device tree for S32V234-EVB
dt-bindings: serial: Document Freescale LINFlexD UART
.../admin-guide/kernel-parameters.txt | 2 +-
.../devicetree/bindings/arm/fsl.yaml | 6 +
.../bindings/serial/fsl,s32-linflexuart.txt | 22 +++
arch/arm64/Kconfig.platforms | 5 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
arch/arm64/boot/dts/freescale/s32v234-evb.dts | 25 ++++
arch/arm64/boot/dts/freescale/s32v234.dtsi | 139 ++++++++++++++++++
arch/arm64/configs/defconfig | 3 +
drivers/tty/serial/Kconfig | 8 +-
drivers/tty/serial/fsl_linflexuart.c | 8 +-
include/uapi/linux/serial_core.h | 4 +-
11 files changed, 213 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.txt
create mode 100644 arch/arm64/boot/dts/freescale/s32v234-evb.dts
create mode 100644 arch/arm64/boot/dts/freescale/s32v234.dtsi
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Aw: [PATCH net-next v3 0/3] net: ethernet: mediatek: convert to PHYLINK
From: Frank Wunderlich @ 2019-08-23 17:56 UTC (permalink / raw)
To: "René van Dorst"
Cc: Nelson Chang, netdev, Sean Wang, linux-mips, Russell King,
"René van Dorst", linux-mediatek, John Crispin,
Matthias Brugger, Stefan Roese, David S . Miller,
linux-arm-kernel
In-Reply-To: <20190823134516.27559-1-opensource@vdorst.com>
tested on bpi-r2 (mt7623/mt7530) and bpi-r64 (mt7622/rtl8367)
as reported to rene directly rx-path needs some rework because current rx-speed
on bpi-r2 is 865 Mbits/sec instead of ~940 Mbits/sec
Tested-by: Frank Wunderlich <frank-w@public-files.de>
regards Frank
> Gesendet: Freitag, 23. August 2019 um 15:45 Uhr
> Von: "René van Dorst" <opensource@vdorst.com>
> An: "John Crispin" <john@phrozen.org>, "Sean Wang" <sean.wang@mediatek.com>, "Nelson Chang" <nelson.chang@mediatek.com>, "David S . Miller" <davem@davemloft.net>, "Matthias Brugger" <matthias.bgg@gmail.com>
> Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-mips@vger.kernel.org, "Russell King" <linux@armlinux.org.uk>, "Frank Wunderlich" <frank-w@public-files.de>, "Stefan Roese" <sr@denx.de>, "René van Dorst" <opensource@vdorst.com>
> Betreff: [PATCH net-next v3 0/3] net: ethernet: mediatek: convert to PHYLINK
>
> These patches converts mediatek driver to PHYLINK API.
>
> v2->v3:
> * Phylink improvements and clean-ups after review
> v1->v2:
> * Rebase for mt76x8 changes
> * Phylink improvements and clean-ups after review
> * SGMII port doesn't support 2.5Gbit in SGMII mode only in BASE-X mode.
> Refactor the code.
>
> René van Dorst (3):
> net: ethernet: mediatek: Add basic PHYLINK support
> net: ethernet: mediatek: Re-add support SGMII
> dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the
> new phylink API
>
> .../arm/mediatek/mediatek,sgmiisys.txt | 2 -
> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +-
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
> drivers/net/ethernet/mediatek/Kconfig | 2 +-
> drivers/net/ethernet/mediatek/mtk_eth_path.c | 75 +--
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 529 ++++++++++++------
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 68 ++-
> drivers/net/ethernet/mediatek/mtk_sgmii.c | 65 ++-
> 8 files changed, 477 insertions(+), 293 deletions(-)
>
> --
> 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 v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Cristian Marussi @ 2019-08-23 17:49 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <CAAeHK+yhbUcuLhoetjGUbqM4j9fX84hbwmxzNPF+e1zXj6nKNw@mail.gmail.com>
Hi
On 23/08/2019 18:16, Andrey Konovalov wrote:
> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
>>
>> Hi Andrey
>>
>> On 24/06/2019 15:33, Andrey Konovalov wrote:
>>> This patch is a part of a series that extends kernel ABI to allow to pass
>>> tagged user pointers (with the top byte set to something else other than
>>> 0x00) as syscall arguments.
>>>
>>> This patch adds a simple test, that calls the uname syscall with a
>>> tagged user pointer as an argument. Without the kernel accepting tagged
>>> user pointers the test fails with EFAULT.
>>>
>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>>> ---
>>> tools/testing/selftests/arm64/.gitignore | 1 +
>>> tools/testing/selftests/arm64/Makefile | 11 +++++++
>>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
>>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
>>> 4 files changed, 53 insertions(+)
>>> create mode 100644 tools/testing/selftests/arm64/.gitignore
>>> create mode 100644 tools/testing/selftests/arm64/Makefile
>>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
>>> create mode 100644 tools/testing/selftests/arm64/tags_test.c
>>
>> After building a fresh Kernel from arm64/for-next-core from scratch at:
>>
>> commit 239ab658bea3b387424501e7c416640d6752dc0c
>> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
>> Author: Will Deacon <will@kernel.org>
>> Date: Thu Aug 22 18:23:53 2019 +0100
>>
>> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
>>
>>
>> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
>>
>> 13:30 $ make TARGETS=arm64 kselftest-clean
>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>
>> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
>>
>> 13:30 $ make TARGETS=arm64 kselftest
>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
>> ARCH=arm64 -C ../../.. headers_install
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/unifdef
>> ...
>> ...
>> HDRINST usr/include/asm/msgbuf.h
>> HDRINST usr/include/asm/shmbuf.h
>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
>> tags_test.c: In function ‘main’:
>> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>> ^~~~~~~~~~~~~~~~~~~~~~~
>> PR_GET_TID_ADDRESS
>> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
>> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>> ^~~~~~~~~~~~~~~~~~~~~
>> PR_GET_DUMPABLE
>> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
>> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
>> Makefile:136: recipe for target 'all' failed
>> make[2]: *** [all] Error 2
>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
>> make[1]: *** [kselftest] Error 2
>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> Makefile:179: recipe for target 'sub-make' failed
>> make: *** [sub-make] Error 2
>>
>> Despite seeing KSFT installing Kernel Headers, they cannot be found.
>>
>> Fixing this patch like this make it work for me:
>>
>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>> index a61b2e743e99..f9f79fb272f0 100644
>> --- a/tools/testing/selftests/arm64/Makefile
>> +++ b/tools/testing/selftests/arm64/Makefile
>> @@ -4,6 +4,7 @@
>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>
>> ifneq (,$(filter $(ARCH),aarch64 arm64))
>> +CFLAGS += -I../../../../usr/include/
>> TEST_GEN_PROGS := tags_test
>> TEST_PROGS := run_tags_test.sh
>> endif
>>
>> but is not really a proper fix since it does NOT account for case in which you have
>> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
>>
>> Am I missing something ?
>
> Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
> and the test has #include <sys/prctl.h> so as long as you've updated
> your kernel headers this should work.
>
> (I'm OOO next week, I'll see if I can reproduce this once I'm back).
Ok. Thanks for the reply.
I think I've got it in my local tree having cloned arm64/for-next-core:
18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h
#define PR_SET_TAGGED_ADDR_CTRL 55
#define PR_GET_TAGGED_ADDR_CTRL 56
# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
#endif /* _LINUX_PRCTL_H */
and Kernel header are locally installed in my kernel src dir (by KSFT indeed)
18:34 $ egrep -RA 10 PR_SET_TAG usr/include/
usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55
usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56
usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
usr/include/linux/prctl.h-
usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */
but how are they supposed to be found if nor the test Makefile
neither the KSFT Makefile who installs them pass any -I options to the
compiler ?
I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path,
but when you are cross-compiling ?
18:34 $ make TARGETS=arm64 kselftest
make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
ARCH=arm64 -C ../../.. headers_install
INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include
/opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test
tags_test.c: In function ‘main’:
tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
^~~~~~~~~~~~~~~~~~~~~~~
PR_GET_TID_ADDRESS
tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in
tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
^~~~~~~~~~~~~~~~~~~~~
PR_GET_DUMPABLE
../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed
make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1
Makefile:19: recipe for target 'all' failed
make[3]: *** [all] Error 2
Makefile:137: recipe for target 'all' failed
make[2]: *** [all] Error 2
/home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed
make[1]: *** [kselftest] Error 2
make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
Makefile:179: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
In fact many KSFT testcases seems to brutally add default headers path:
tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/
tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/
tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/
tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/
tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/
...
Cheers
Cristian
>
>
>
>>
>> Thanks
>>
>> Cristian
>>
>>>
>>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
>>> new file mode 100644
>>> index 000000000000..e8fae8d61ed6
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/arm64/.gitignore
>>> @@ -0,0 +1 @@
>>> +tags_test
>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>>> new file mode 100644
>>> index 000000000000..a61b2e743e99
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/arm64/Makefile
>>> @@ -0,0 +1,11 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +
>>> +# ARCH can be overridden by the user for cross compiling
>>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>> +
>>> +ifneq (,$(filter $(ARCH),aarch64 arm64))
>>> +TEST_GEN_PROGS := tags_test
>>> +TEST_PROGS := run_tags_test.sh
>>> +endif
>>> +
>>> +include ../lib.mk
>>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
>>> new file mode 100755
>>> index 000000000000..745f11379930
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh
>>> @@ -0,0 +1,12 @@
>>> +#!/bin/sh
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +
>>> +echo "--------------------"
>>> +echo "running tags test"
>>> +echo "--------------------"
>>> +./tags_test
>>> +if [ $? -ne 0 ]; then
>>> + echo "[FAIL]"
>>> +else
>>> + echo "[PASS]"
>>> +fi
>>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
>>> new file mode 100644
>>> index 000000000000..22a1b266e373
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/arm64/tags_test.c
>>> @@ -0,0 +1,29 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +#include <stdio.h>
>>> +#include <stdlib.h>
>>> +#include <unistd.h>
>>> +#include <stdint.h>
>>> +#include <sys/prctl.h>
>>> +#include <sys/utsname.h>
>>> +
>>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
>>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
>>> + SHIFT_TAG(tag))
>>> +
>>> +int main(void)
>>> +{
>>> + static int tbi_enabled = 0;
>>> + struct utsname *ptr, *tagged_ptr;
>>> + int err;
>>> +
>>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>> + tbi_enabled = 1;
>>> + ptr = (struct utsname *)malloc(sizeof(*ptr));
>>> + if (tbi_enabled)
>>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
>>> + err = uname(tagged_ptr);
>>> + free(ptr);
>>> +
>>> + return err;
>>> +}
>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Aw: Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Frank Wunderlich @ 2019-08-23 17:16 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, Kate Stewart,
srv_heupstream, devicetree, Greg Kroah-Hartman, Mark Brown,
Sean Wang, Liam Girdwood, linux-kernel, Richard Fontana,
Rob Herring, linux-mediatek, linux-arm-kernel,
"René van Dorst", Thomas Gleixner, Eddie Huang,
Lee Jones, Hsin-Hsiung Wang, linux-rtc
In-Reply-To: <b5a21908-faee-17d1-ce26-99b941c0fa70@gmail.com>
> Gesendet: Freitag, 23. August 2019 um 17:42 Uhr
> Von: "Matthias Brugger" <matthias.bgg@gmail.com>
> I suppose that's because 3/10 has code that should be in 2/10 and for some
> reason 3/10 was not pushed for linux-next inclusion. Although it has the same
> Acked-for-mfd-by tag.
>
> @Frank, can you test if adding 3/10 to your code base fixes the issue?
adding part 3 [1] seems to fix the issue too
[ 4.960051] mt6323-regulator mt6323-regulator: Chip ID = 0x2023
thanks
[1] https://patchwork.kernel.org/patch/11110509/
_______________________________________________
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 v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Andrey Konovalov @ 2019-08-23 17:16 UTC (permalink / raw)
To: Cristian Marussi
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <6af3f619-4356-2f67-ed76-92beceb1e0a0@arm.com>
On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> Hi Andrey
>
> On 24/06/2019 15:33, Andrey Konovalov wrote:
> > This patch is a part of a series that extends kernel ABI to allow to pass
> > tagged user pointers (with the top byte set to something else other than
> > 0x00) as syscall arguments.
> >
> > This patch adds a simple test, that calls the uname syscall with a
> > tagged user pointer as an argument. Without the kernel accepting tagged
> > user pointers the test fails with EFAULT.
> >
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > ---
> > tools/testing/selftests/arm64/.gitignore | 1 +
> > tools/testing/selftests/arm64/Makefile | 11 +++++++
> > .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
> > tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
> > 4 files changed, 53 insertions(+)
> > create mode 100644 tools/testing/selftests/arm64/.gitignore
> > create mode 100644 tools/testing/selftests/arm64/Makefile
> > create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
> > create mode 100644 tools/testing/selftests/arm64/tags_test.c
>
> After building a fresh Kernel from arm64/for-next-core from scratch at:
>
> commit 239ab658bea3b387424501e7c416640d6752dc0c
> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
> Author: Will Deacon <will@kernel.org>
> Date: Thu Aug 22 18:23:53 2019 +0100
>
> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
>
>
> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
>
> 13:30 $ make TARGETS=arm64 kselftest-clean
> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>
> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
>
> 13:30 $ make TARGETS=arm64 kselftest
> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> ARCH=arm64 -C ../../.. headers_install
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/unifdef
> ...
> ...
> HDRINST usr/include/asm/msgbuf.h
> HDRINST usr/include/asm/shmbuf.h
> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> tags_test.c: In function ‘main’:
> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> ^~~~~~~~~~~~~~~~~~~~~~~
> PR_GET_TID_ADDRESS
> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> ^~~~~~~~~~~~~~~~~~~~~
> PR_GET_DUMPABLE
> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
> Makefile:136: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
> make[1]: *** [kselftest] Error 2
> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> Makefile:179: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
> Despite seeing KSFT installing Kernel Headers, they cannot be found.
>
> Fixing this patch like this make it work for me:
>
> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> index a61b2e743e99..f9f79fb272f0 100644
> --- a/tools/testing/selftests/arm64/Makefile
> +++ b/tools/testing/selftests/arm64/Makefile
> @@ -4,6 +4,7 @@
> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>
> ifneq (,$(filter $(ARCH),aarch64 arm64))
> +CFLAGS += -I../../../../usr/include/
> TEST_GEN_PROGS := tags_test
> TEST_PROGS := run_tags_test.sh
> endif
>
> but is not really a proper fix since it does NOT account for case in which you have
> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
>
> Am I missing something ?
Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
and the test has #include <sys/prctl.h> so as long as you've updated
your kernel headers this should work.
(I'm OOO next week, I'll see if I can reproduce this once I'm back).
>
> Thanks
>
> Cristian
>
> >
> > diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
> > new file mode 100644
> > index 000000000000..e8fae8d61ed6
> > --- /dev/null
> > +++ b/tools/testing/selftests/arm64/.gitignore
> > @@ -0,0 +1 @@
> > +tags_test
> > diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> > new file mode 100644
> > index 000000000000..a61b2e743e99
> > --- /dev/null
> > +++ b/tools/testing/selftests/arm64/Makefile
> > @@ -0,0 +1,11 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +# ARCH can be overridden by the user for cross compiling
> > +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> > +
> > +ifneq (,$(filter $(ARCH),aarch64 arm64))
> > +TEST_GEN_PROGS := tags_test
> > +TEST_PROGS := run_tags_test.sh
> > +endif
> > +
> > +include ../lib.mk
> > diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
> > new file mode 100755
> > index 000000000000..745f11379930
> > --- /dev/null
> > +++ b/tools/testing/selftests/arm64/run_tags_test.sh
> > @@ -0,0 +1,12 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +echo "--------------------"
> > +echo "running tags test"
> > +echo "--------------------"
> > +./tags_test
> > +if [ $? -ne 0 ]; then
> > + echo "[FAIL]"
> > +else
> > + echo "[PASS]"
> > +fi
> > diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
> > new file mode 100644
> > index 000000000000..22a1b266e373
> > --- /dev/null
> > +++ b/tools/testing/selftests/arm64/tags_test.c
> > @@ -0,0 +1,29 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <unistd.h>
> > +#include <stdint.h>
> > +#include <sys/prctl.h>
> > +#include <sys/utsname.h>
> > +
> > +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
> > +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
> > + SHIFT_TAG(tag))
> > +
> > +int main(void)
> > +{
> > + static int tbi_enabled = 0;
> > + struct utsname *ptr, *tagged_ptr;
> > + int err;
> > +
> > + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> > + tbi_enabled = 1;
> > + ptr = (struct utsname *)malloc(sizeof(*ptr));
> > + if (tbi_enabled)
> > + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
> > + err = uname(tagged_ptr);
> > + free(ptr);
> > +
> > + return err;
> > +}
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] KVM/arm updates for 5.3-rc6
From: Paolo Bonzini @ 2019-08-23 17:07 UTC (permalink / raw)
To: Marc Zyngier, Radim Krčmář
Cc: Mark Rutland, Andrew Jones, kvm, Suzuki K Poulose, Andre Przywara,
kvmarm, Christian Borntraeger, Julien Grall, James Morse,
linux-arm-kernel, Dave Martin, Julien Thierry
In-Reply-To: <20190823163516.179768-1-maz@kernel.org>
On 23/08/19 18:35, Marc Zyngier wrote:
> Paolo, Radim,
>
> One (hopefully last) set of fixes for KVM/arm for 5.3: an embarassing
> MMIO emulation regression, and a UBSAN splat. Oh well...
>
> Please pull,
Please send this (and any other changes until the release) through the
ARM tree---same for s390 if need be.
This way Radim can concentrate on pending 5.4 patches while I am away.
Paolo
> M.
>
> The following changes since commit 16e604a437c89751dc626c9e90cf88ba93c5be64:
>
> KVM: arm/arm64: vgic: Reevaluate level sensitive interrupts on enable (2019-08-09 08:07:26 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.3-3
>
> for you to fetch changes up to 2e16f3e926ed48373c98edea85c6ad0ef69425d1:
>
> KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity (2019-08-23 17:23:01 +0100)
>
> ----------------------------------------------------------------
> KVM/arm fixes for 5.3, take #3
>
> - Don't overskip instructions on MMIO emulation
> - Fix UBSAN splat when initializing PPI priorities
>
> ----------------------------------------------------------------
> Andre Przywara (1):
> KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
>
> Andrew Jones (1):
> KVM: arm/arm64: Only skip MMIO insn once
>
> virt/kvm/arm/mmio.c | 7 +++++++
> virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
> 2 files changed, 27 insertions(+), 10 deletions(-)
>
_______________________________________________
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
From: Kevin Hilman @ 2019-08-23 17:03 UTC (permalink / raw)
To: Kever Yang, Heiko Stuebner
Cc: kernel-build-reports, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <7hd0gvzuvw.fsf@baylibre.com>
Kevin Hilman <khilman@baylibre.com> writes:
> Kever Yang <kever.yang@rock-chips.com> writes:
>
>> Hi Kevin, Heiko,
>>
>> On 2019/8/22 上午2:59, Kevin Hilman wrote:
>>> 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.
>>
>> The CPU voltage does not affect by bootloader for kernel should have its
>> own opp-table,
>>
>> the bootloader may only affect the center/logic power supply.
>>
>>>
>>>> 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.
>>
>> Is it possible to target which patch introduce this bug? This board
>> should have work correctly for a long time with upstream source code.
>
> Unfortunately, it seems to be a regular, but intermittent failure, so
> bisection is not producing anything reliable.
>
> You can see that both in mainline[1] and in linux-next[2] there are
> periodic failures, but it's hard to see any patterns.
Even worse, I (re)tested mainline for versions that were previously
passing (v5.2, v5.3-rc5) and they are also failing now.
They work again if I disable that regulator as suggested by Heiko.
So this is increasingly pointing to failing hardware.
Kevin
_______________________________________________
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
From: Kevin Hilman @ 2019-08-23 16:52 UTC (permalink / raw)
To: Kever Yang, Heiko Stuebner
Cc: kernel-build-reports, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <c973d3fa-5f0d-c277-7c83-6227942a671a@rock-chips.com>
Kever Yang <kever.yang@rock-chips.com> writes:
> Hi Kevin, Heiko,
>
> On 2019/8/22 上午2:59, Kevin Hilman wrote:
>> 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.
>
> The CPU voltage does not affect by bootloader for kernel should have its
> own opp-table,
>
> the bootloader may only affect the center/logic power supply.
>
>>
>>> 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.
>
> Is it possible to target which patch introduce this bug? This board
> should have work correctly for a long time with upstream source code.
Unfortunately, it seems to be a regular, but intermittent failure, so
bisection is not producing anything reliable.
You can see that both in mainline[1] and in linux-next[2] there are
periodic failures, but it's hard to see any patterns.
I'm starting to think that maybe the regulator on my particular board is
just starting to fail, since disabling the regulator for that cluster
prevents any voltage changes and makes things reliable again.
If we don't find a solution to this, I'll probably just have to retire
this board from my kernelCI lab (of course, I'd be happy to replace it
if someone wants to donate another one.) :)
Kevin
[1] https://kernelci.org/boot/rk3399-firefly/job/mainline/
[2] https://kernelci.org/boot/rk3399-firefly/job/next/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm: mediatek: soc driver updates for v5.4
From: Matthias Brugger @ 2019-08-23 16:43 UTC (permalink / raw)
To: arm-soc, soc
Cc: moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org, Bibby Hsieh
Hi Olof and Arnd,
Please find below two patches for soc drivers.
See you,
Matthias
---
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.3-next-soc
for you to fetch changes up to 556030f0604f3cf5f1ea91307c0695541e5c74ca:
soc: mediatek: cmdq: change the type of input parameter (2019-08-23 14:06:48
+0200)
----------------------------------------------------------------
cmdq helper:
reoder function parameter and change size of the parameters
----------------------------------------------------------------
Bibby Hsieh (2):
soc: mediatek: cmdq: reorder the parameter
soc: mediatek: cmdq: change the type of input parameter
drivers/soc/mediatek/mtk-cmdq-helper.c | 10 +++++-----
include/linux/soc/mediatek/mtk-cmdq.h | 14 +++++++-------
2 files changed, 12 insertions(+), 12 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: mediatek: dts64 updates for v5.4
From: Matthias Brugger @ 2019-08-23 16:42 UTC (permalink / raw)
To: arm-soc, soc
Cc: moderated list:ARM/Mediatek SoC support, Mars Cheng,
linux-arm-kernel@lists.infradead.org, Hsin-Hsiung Wang
Hi Olof and Arnd,
Please take the following patches into account.
Thanks!
Matthias
---
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.3-next-dts64
for you to fetch changes up to 7b07a7a4e169180c7da5078bdf5254515e69c152:
dt-bindings: irq: mtk, sysirq: add support for mt6779 (2019-08-23 17:50:07 +0200)
----------------------------------------------------------------
mt8183:
- fix pwrap interrupt number
- add i2c notes
dt-bindings:
- add compatible for mt6779
- add mt6779 uart and sysirq compatible
----------------------------------------------------------------
Hsin-Hsiung Wang (1):
arm64: dts: mt8183: fix pwrap gic number
Mars Cheng (3):
dt-bindings: mediatek: add support for mt6779 reference board
dt-bindings: mtk-uart: add mt6779 uart bindings
dt-bindings: irq: mtk, sysirq: add support for mt6779
Qii Wang (1):
arm64: dts: mt8183: add I2C nodes
.../devicetree/bindings/arm/mediatek.yaml | 4 +
.../interrupt-controller/mediatek,sysirq.txt | 1 +
.../devicetree/bindings/serial/mtk-uart.txt | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 96 +++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 191 ++++++++++++++++++++-
5 files changed, 292 insertions(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm: mediatek: dts32 updates for v5.4
From: Matthias Brugger @ 2019-08-23 16:40 UTC (permalink / raw)
To: arm-soc, soc
Cc: Ryder Lee, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org
Hi Arnd and Olof,
please have a look on the following patch.
Regards,
Matthias
---
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.3-next-dts32
for you to fetch changes up to cc212241df0b8975bb0e6d7f9028405a9c664e49:
arm: dts: mediatek: add basic support for MT7629 SoC (2019-08-22 11:22:17 +0200)
----------------------------------------------------------------
add support for the mt7629 reference board
----------------------------------------------------------------
Ryder Lee (1):
arm: dts: mediatek: add basic support for MT7629 SoC
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/mt7629-rfb.dts | 263 ++++++++++++++++
arch/arm/boot/dts/mt7629.dtsi | 481 ++++++++++++++++++++++++++++++
include/dt-bindings/reset/mt7629-resets.h | 71 +++++
4 files changed, 816 insertions(+)
create mode 100644 arch/arm/boot/dts/mt7629-rfb.dts
create mode 100644 arch/arm/boot/dts/mt7629.dtsi
create mode 100644 include/dt-bindings/reset/mt7629-resets.h
_______________________________________________
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] KVM: arm: VGIC: properly initialise private IRQ affinity
From: Marc Zyngier @ 2019-08-23 16:37 UTC (permalink / raw)
To: Julien Grall, Andre Przywara, Christoffer Dall
Cc: Dave Martin, linux-arm-kernel, kvmarm
In-Reply-To: <bdb1426b-1c00-fce3-5e42-25c97d4311e1@arm.com>
On 23/08/2019 14:54, Julien Grall wrote:
> Hi Andre,
>
> On 23/08/2019 11:34, Andre Przywara wrote:
>> At the moment we initialise the target *mask* of a virtual IRQ to the
>> VCPU it belongs to, even though this mask is only defined for GICv2 and
>> quickly runs out of bits for many GICv3 guests.
>> This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
>> ------
>> [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
>> [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
>> ------
>> Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
>> dump is wrong, due to this very same problem.
>>
>> Because there is no requirement to create the VGIC device before the
>> VCPUs (and QEMU actually does it the other way round), we can't safely
>> initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
>> every private IRQ for each VCPU anyway later (in vgic_init()), we can
>> just move the initialisation of those fields into there, where we
>> definitely know the VGIC type.
>>
>> On the way make sure we really have either a VGICv2 or a VGICv3 device,
>> since the existing code is just checking for "VGICv3 or not", silently
>> ignoring the uninitialised case.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Reported-by: Dave Martin <dave.martin@arm.com>
>
> I have tested with both a combination of GICv2/GICv3 and kvmtools/QEMU. I can
> confirm the UBSAN warning is not present anymore. Feel free to add my tested-by:
>
> Tested-by: Julien Grall <julien.grall@arm.com>
Applied, and pull request sent.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v10 0/1] arm64 tagged address ABI
From: Catalin Marinas @ 2019-08-23 16:37 UTC (permalink / raw)
To: linux-arm-kernel, linux-mm
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Dave Hansen, Andrew Morton, Vincenzo Frascino,
Will Deacon, Dave P Martin
Hi,
Minor update to the arm64 tagged address ABI documentation since v9,
posted here:
http://lkml.kernel.org/r/20190821164730.47450-1-catalin.marinas@arm.com
The mmap/mremap/... patch (1/3) has been queued in the -mm tree and
removed from this series. The tagged-address-abi.rst patch (2/3) has
been queued in the arm64 for-next/core tree. There is only one patch
left in this series (keeping the cover letter for consistency).
Changes in v10:
- Remove the tag preservation paragraph since the new ABI does not
change the behaviour we already have. The only difference is that now
the kernel can access tagged addresses (e.g. delivering a signal on a
tagged alternate stack).
Vincenzo Frascino (1):
arm64: Relax Documentation/arm64/tagged-pointers.rst
Documentation/arm64/tagged-pointers.rst | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v10 1/1] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Catalin Marinas @ 2019-08-23 16:37 UTC (permalink / raw)
To: linux-arm-kernel, linux-mm
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, Dave Hansen, Andrew Morton,
Vincenzo Frascino, Will Deacon, Dave P Martin
In-Reply-To: <20190823163717.19569-1-catalin.marinas@arm.com>
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 | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
index 2acdec3ebbeb..eab4323609b9 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,9 @@ 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.
+
Other considerations
--------------------
_______________________________________________
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: [RFC v4 10/18] objtool: arm64: Implement functions to add switch tables alternatives
From: Julien @ 2019-08-23 16:35 UTC (permalink / raw)
To: Raphael Gault, linux-arm-kernel, linux-kernel, jpoimboe
Cc: peterz, catalin.marinas, will.deacon, raph.gault+kdev
In-Reply-To: <20190816122403.14994-11-raphael.gault@arm.com>
Hi Raphaël,
The title should probably go straight to the point, this provides
support for arm64 switch tables. The use of alternatives is just an
implementation detail (it is good to have it explained in the commit
message, but in the title it would be more helpful to see that this
actually adds support for something that was not working).
On 16/08/19 13:23, Raphael Gault wrote:
> This patch implements the functions required to identify and add as
> alternatives all the possible destinations of the switch table.
> This implementation relies on the new plugin introduced previously which
> records information about the switch-table in a .objtool_data section.
>
I think it would be worth giving a bit more context. Why are you adding
all possible destinations of a switch table as alternatives? What does
this solve?
> Signed-off-by: Raphael Gault <raphael.gault@arm.com>
> ---
> tools/objtool/arch/arm64/arch_special.c | 132 +++++++++++++++++-
> .../objtool/arch/arm64/include/arch_special.h | 10 ++
> .../objtool/arch/arm64/include/insn_decode.h | 3 +-
> tools/objtool/check.c | 6 +-
> tools/objtool/check.h | 2 +
> 5 files changed, 146 insertions(+), 7 deletions(-)
>
> diff --git a/tools/objtool/arch/arm64/arch_special.c b/tools/objtool/arch/arm64/arch_special.c
> index 17a8a06aac2a..11284066157c 100644
> --- a/tools/objtool/arch/arm64/arch_special.c
> +++ b/tools/objtool/arch/arm64/arch_special.c
> @@ -12,8 +12,13 @@
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, see <http://www.gnu.org/licenses/>.
> */
> +
> +#include <stdlib.h>
> +#include <string.h>
> +
> #include "../../special.h"
> #include "arch_special.h"
> +#include "bit_operations.h"
>
> void arch_force_alt_path(unsigned short feature,
> bool uaccess,
> @@ -21,9 +26,133 @@ void arch_force_alt_path(unsigned short feature,
> {
> }
>
> +static u32 next_offset(u8 *table, u8 entry_size)
> +{
> + switch (entry_size) {
> + case 1:
> + return table[0];
> + case 2:
> + return *(u16 *)(table);
> + default:
> + return *(u32 *)(table);
> + }
> +}
> +
> +static u32 get_table_entry_size(u32 insn)
> +{
> + unsigned char size = (insn >> 30) & ONES(2);
I guess you're assuming insn is a ld* instruction. It would be good to
clarify what this mask is doing and on which type of instructions that
can work.
Maybe you could re-use the arm64 decoder to retrieve the size. You could
directly call arm_decode_ld_st() if you know this is a load instruction
if you are very confident about it or call the whole decoding process
and check that you actually have the type of instruction you were expecting.
> + switch (size) {
> + case 0:
> + return 1;
> + case 1:
> + return 2;
> + default:
> + return 4;
> + }
> +}
> +
> +static int add_possible_branch(struct objtool_file *file,
> + struct instruction *insn,
> + u32 base, u32 offset)
> +{
> + struct instruction *dest_insn;
> + struct alternative *alt;
> + offset = base + 4 * offset;
> +
> + alt = calloc(1, sizeof(*alt));
> + if (alt == NULL) {
> + WARN("allocation failure, can't add jump alternative");
> + return -1;
> + }
> +
> + dest_insn = find_insn(file, insn->sec, offset);
> + if (dest_insn == NULL) {
> + free(alt);
You probably should allocate the alternative only once you've found the
target instruction.
> + return 0;
Is is really fine not to find an instruction when you have an entry in
your obtool_data table?
> + }
> + alt->insn = dest_insn;
> + alt->skip_orig = true;
Is skipping the original instruction needed? It still gets executed
before we jump to the target instruction.
> + list_add_tail(&alt->list, &insn->alts);
> + return 0;
> +}
> +
> int arch_add_jump_table(struct objtool_file *file, struct instruction *insn,
> struct rela *table, struct rela *next_table)
> {
> + struct rela *objtool_data_rela = NULL;
> + struct switch_table_info *swt_info = NULL;
> + struct section *objtool_data = find_section_by_name(file->elf, ".objtool_data");
> + struct section *rodata_sec = find_section_by_name(file->elf, ".rodata");
> + struct section *branch_sec = NULL;
> + u8 *switch_table = NULL;
> + u64 base_offset = 0;
> + struct instruction *pre_jump_insn;
> + u32 sec_size = 0;
> + u32 entry_size = 0;
> + u32 offset = 0;
> + u32 i, j;
> +
> + if (objtool_data == NULL)
> + return 0;
> +
> + /*
> + * 1. Using rela, Identify entry for the switch table
> + * 2. Retrieve base offset
> + * 3. Retrieve branch instruction
> + * 3. For all entries in switch table:
> + * 3.1. Compute new offset
> + * 3.2. Create alternative instruction
> + * 3.3. Add alt_instr to insn->alts list
> + */
> + sec_size = objtool_data->sh.sh_size;
> + for (i = 0, swt_info = (void *)objtool_data->data->d_buf;
> + i < sec_size / sizeof(struct switch_table_info);
> + i++, swt_info++) {
> + offset = i * sizeof(struct switch_table_info);
> + objtool_data_rela = find_rela_by_dest_range(objtool_data, offset,
> + sizeof(u64));
> + /* retrieving the objtool data of the switch table we need */
> + if (objtool_data_rela == NULL ||
> + table->sym->sec != objtool_data_rela->sym->sec ||
> + table->addend != objtool_data_rela->addend)
> + continue;
> +
> + /* retrieving switch table content */
> + switch_table = (u8 *)(rodata_sec->data->d_buf + table->addend);
> +
> + /* retrieving pre jump instruction (ldr) */
> + branch_sec = insn->sec;
> + pre_jump_insn = find_insn(file, branch_sec,
> + insn->offset - 3 * sizeof(u32));
> + entry_size = get_table_entry_size(*(u32 *)(branch_sec->data->d_buf + pre_jump_insn->offset));
> +
> + /*
> + * iterating over the pre-jumps instruction in order to
What's a pre-jump instruction? Can you include as comment an example of
what the arm64 jump table looks like? That would help understand what is
actually in the objtool_data section and how you make sense of it.
> + * retrieve switch base offset.
> + */
> + while (pre_jump_insn != NULL &&
> + pre_jump_insn->offset <= insn->offset) {
> + if (pre_jump_insn->stack_op.src.reg == ADR_SOURCE) {
Maybe you can have a separate function to do the processing of a single
switch table/switch_table_info.
> + base_offset = pre_jump_insn->offset +
> + pre_jump_insn->immediate;
> + /*
> + * Once we have the switch table entry size
> + * we add every possible destination using
> + * alternatives of the original branch
> + * instruction
> + */
> + for (j = 0; j < swt_info->nb_entries; j++) {
> + if (add_possible_branch(file, insn,
> + base_offset,
> + next_offset(switch_table, entry_size))) {
> + return -1;
> + }
> + switch_table += entry_size;
> + }
> + }
> + pre_jump_insn = next_insn_same_sec(file, pre_jump_insn);
> + }
> + }
> return 0;
> }
>
> @@ -32,6 +161,5 @@ struct rela *arch_find_switch_table(struct objtool_file *file,
> struct section *rodata_sec,
> unsigned long table_offset)
> {
> - file->ignore_unreachables = true;
> - return NULL;
> + return text_rela;
> }
> diff --git a/tools/objtool/arch/arm64/include/arch_special.h b/tools/objtool/arch/arm64/include/arch_special.h
> index 185103be8a51..cba432fed80f 100644
> --- a/tools/objtool/arch/arm64/include/arch_special.h
> +++ b/tools/objtool/arch/arm64/include/arch_special.h
> @@ -15,6 +15,8 @@
> #ifndef _ARM64_ARCH_SPECIAL_H
> #define _ARM64_ARCH_SPECIAL_H
>
> +#include <linux/types.h>
> +
> #define EX_ENTRY_SIZE 8
> #define EX_ORIG_OFFSET 0
> #define EX_NEW_OFFSET 4
> @@ -30,6 +32,14 @@
> #define ALT_ORIG_LEN_OFFSET 10
> #define ALT_NEW_LEN_OFFSET 11
>
> +#define ADR_SOURCE 255
> +
> +struct switch_table_info {
> + u64 switch_table_label;
> + u64 nb_entries;
> + u64 offset_unsigned;
> +} __attribute__((__packed__));
> +
> static inline bool arch_should_ignore_feature(unsigned short feature)
> {
> return false;
> diff --git a/tools/objtool/arch/arm64/include/insn_decode.h b/tools/objtool/arch/arm64/include/insn_decode.h
> index a01d76306749..65b6efecd68f 100644
> --- a/tools/objtool/arch/arm64/include/insn_decode.h
> +++ b/tools/objtool/arch/arm64/include/insn_decode.h
> @@ -18,6 +18,7 @@
> #define _ARM_INSN_DECODE_H
>
> #include "../../../arch.h"
> +#include "arch_special.h"
>
> #define INSN_RESERVED 0b0000
> #define INSN_UNALLOC_1 0b0001
> @@ -58,8 +59,6 @@
> #define COMPOSED_INSN_REGS_NUM 2
> #define INSN_COMPOSED 1
>
> -#define ADR_SOURCE -1
> -
> typedef int (*arm_decode_class)(u32 instr, unsigned char *type,
> unsigned long *immediate, struct stack_op *op);
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 18f7fb47392a..2c4ea51041e1 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -35,8 +35,8 @@ struct instruction *find_insn(struct objtool_file *file,
> return NULL;
> }
>
> -static struct instruction *next_insn_same_sec(struct objtool_file *file,
> - struct instruction *insn)
> +struct instruction *next_insn_same_sec(struct objtool_file *file,
> + struct instruction *insn)
> {
> struct instruction *next = list_next_entry(insn, list);
>
> @@ -1856,7 +1856,7 @@ static int validate_sibling_call(struct instruction *insn, struct insn_state *st
> {
> if (arch_is_insn_sibling_call(insn) && has_modified_stack_frame(state)) {
> WARN_FUNC("sibling call from callable instruction with modified stack frame",
> - insn->sec, insn->offset);
> + insn->sec, insn->offset);
> return 1;
> }
>
> diff --git a/tools/objtool/check.h b/tools/objtool/check.h
> index 267759760a3d..5833f85f71c3 100644
> --- a/tools/objtool/check.h
> +++ b/tools/objtool/check.h
> @@ -66,6 +66,8 @@ int check(const char *objname, bool orc);
>
> struct instruction *find_insn(struct objtool_file *file,
> struct section *sec, unsigned long offset);
> +struct instruction *next_insn_same_sec(struct objtool_file *file,
> + struct instruction *insn);
>
> #define for_each_insn(file, insn) \
> list_for_each_entry(insn, &file->insn_list, list)
>
Thanks,
--
Julien Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
From: Marc Zyngier @ 2019-08-23 16:35 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Mark Rutland, Andrew Jones, kvm, Suzuki K Poulose, Andre Przywara,
kvmarm, Julien Grall, James Morse, linux-arm-kernel, Dave Martin,
Julien Thierry
In-Reply-To: <20190823163516.179768-1-maz@kernel.org>
From: Andre Przywara <andre.przywara@arm.com>
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
------
[ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
[ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
------
Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
dump is wrong, due to this very same problem.
Because there is no requirement to create the VGIC device before the
VCPUs (and QEMU actually does it the other way round), we can't safely
initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
every private IRQ for each VCPU anyway later (in vgic_init()), we can
just move the initialisation of those fields into there, where we
definitely know the VGIC type.
On the way make sure we really have either a VGICv2 or a VGICv3 device,
since the existing code is just checking for "VGICv3 or not", silently
ignoring the uninitialised case.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Dave Martin <dave.martin@arm.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index bdbc297d06fb..e621b5d45b27 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -8,6 +8,7 @@
#include <linux/cpu.h>
#include <linux/kvm_host.h>
#include <kvm/arm_vgic.h>
+#include <asm/kvm_emulate.h>
#include <asm/kvm_mmu.h>
#include "vgic.h"
@@ -164,12 +165,18 @@ static int kvm_vgic_dist_init(struct kvm *kvm, unsigned int nr_spis)
irq->vcpu = NULL;
irq->target_vcpu = vcpu0;
kref_init(&irq->refcount);
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V2) {
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->targets = 0;
irq->group = 0;
- } else {
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->mpidr = 0;
irq->group = 1;
+ break;
+ default:
+ kfree(dist->spis);
+ return -EINVAL;
}
}
return 0;
@@ -209,7 +216,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
irq->intid = i;
irq->vcpu = NULL;
irq->target_vcpu = vcpu;
- irq->targets = 1U << vcpu->vcpu_id;
kref_init(&irq->refcount);
if (vgic_irq_is_sgi(i)) {
/* SGIs */
@@ -219,11 +225,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
/* PPIs */
irq->config = VGIC_CONFIG_LEVEL;
}
-
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
- irq->group = 1;
- else
- irq->group = 0;
}
if (!irqchip_in_kernel(vcpu->kvm))
@@ -286,10 +287,19 @@ int vgic_init(struct kvm *kvm)
for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) {
struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->group = 1;
- else
+ irq->mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->group = 0;
+ irq->targets = 1U << idx;
+ break;
+ default:
+ ret = -EINVAL;
+ goto out;
+ }
}
}
--
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
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