* [PATCH] crypto: arm/speck - fix building in Thumb2 mode
From: Stefan Agner @ 2018-06-19 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618223323.130072-1-ebiggers@google.com>
On 19.06.2018 00:33, Eric Biggers wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here
> -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here
> -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here
> -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here
> -- `bic sp,#0xf'
>
> The problem is that the 'bic' instruction can't operate on the 'sp'
> register in Thumb2 mode. Fix it by using a temporary register. This
> isn't in the main loop, so the performance difference is negligible.
> This also matches what aes-neonbs-core.S does.
>
> Reported-by: Stefan Agner <stefan@agner.ch>
> Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated
> implementation of Speck-XTS")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> arch/arm/crypto/speck-neon-core.S | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/crypto/speck-neon-core.S
> b/arch/arm/crypto/speck-neon-core.S
> index 3c1e203e53b9..57caa742016e 100644
> --- a/arch/arm/crypto/speck-neon-core.S
> +++ b/arch/arm/crypto/speck-neon-core.S
> @@ -272,9 +272,11 @@
> * Allocate stack space to store 128 bytes worth of tweaks. For
> * performance, this space is aligned to a 16-byte boundary so that we
> * can use the load/store instructions that declare 16-byte alignment.
> + * For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
> */
> - sub sp, #128
> - bic sp, #0xf
> + sub r12, sp, #128
> + bic r12, #0xf
> + mov sp, r12
Looks good to me and compiles fine here. Thanks!
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> .if \n == 64
> // Load first tweak
^ permalink raw reply
* [PATCH] arm64: zynqmp: Add support for Avnet Ultra96 rev1 board
From: Michal Simek @ 2018-06-19 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <80d21c84d427cb6b4122efd3dea7f1c4ab4cf2be.1525261987.git.michal.simek@xilinx.com>
Hi,
On 2.5.2018 13:53, Michal Simek wrote:
> Avnet Ultra96 rev1 board is commercialized Xilinx zcu100 revC/D
> internal board. The patch is reusing zcu100 revC files but changing
> model description and compatible strings which are used for example by
> libmraa.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> I choose this option because there are houndreds of zcu100 boards
> created and this will enable support both versions.
>
> Record avnet prefix was sent by separate patch.
> ---
> arch/arm64/boot/dts/xilinx/Makefile | 1 +
> .../boot/dts/xilinx/avnet-ultra96-rev1.dts | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
> create mode 100644 arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts
>
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile b/arch/arm64/boot/dts/xilinx/Makefile
> index d452f80e7601..60f5443f3ef4 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_ZYNQMP) += avnet-ultra96-rev1.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1232-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1254-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1275-revA.dtb
> diff --git a/arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts b/arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts
> new file mode 100644
> index 000000000000..88aa06fa78a8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Avnet Ultra96 rev1
> + *
> + * (C) Copyright 2018, Xilinx, Inc.
> + *
> + * Michal Simek <michal.simek@xilinx.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp-zcu100-revC.dts"
> +
> +/ {
> + model = "Avnet Ultra96 Rev1";
> + compatible = "avnet,ultra96-rev1", "avnet,ultra96",
> + "xlnx,zynqmp-zcu100-revC", "xlnx,zynqmp-zcu100",
> + "xlnx,zynqmp";
> +};
>
Rob/Mark: Do you see any issue with this patch?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/f48b93d3/attachment.sig>
^ permalink raw reply
* [PATCH v6 17/29] drm/mediatek: add connection from RDMA1 to DSI1
From: CK Hu @ 2018-06-19 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-18-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI1
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 13e91903f493..90228cad051a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -28,6 +28,7 @@
> #define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> #define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> #define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> @@ -86,8 +87,10 @@
> #define RDMA0_SOUT_DSI3 0x5
> #define RDMA1_SOUT_DPI0 0x2
> #define RDMA1_SOUT_DPI1 0x3
> +#define RDMA1_SOUT_DSI1 0x1
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> +#define DSI1_SEL_IN_RDMA1 0x1
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -170,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> value = RDMA0_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DPI0;
> @@ -198,6 +204,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> value = DPI1_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> + value = DSI1_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 18/29] drm/mediatek: add connection from RDMA1 to DSI2
From: CK Hu @ 2018-06-19 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-19-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI2
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 90228cad051a..9cf2fcb4932a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -28,6 +28,7 @@
> #define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIE_SEL_IN 0x0a4
> #define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> #define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> @@ -88,9 +89,11 @@
> #define RDMA1_SOUT_DPI0 0x2
> #define RDMA1_SOUT_DPI1 0x3
> #define RDMA1_SOUT_DSI1 0x1
> +#define RDMA1_SOUT_DSI2 0x4
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> +#define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -176,6 +179,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI2;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DPI0;
> @@ -207,6 +213,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> value = DSI1_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI2_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 19/29] drm/mediatek: add connection from RDMA1 to DSI3
From: CK Hu @ 2018-06-19 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-20-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI3
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 9cf2fcb4932a..d0d5f337ce14 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -90,10 +90,12 @@
> #define RDMA1_SOUT_DPI1 0x3
> #define RDMA1_SOUT_DSI1 0x1
> #define RDMA1_SOUT_DSI2 0x4
> +#define RDMA1_SOUT_DSI3 0x5
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -182,6 +184,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DPI0;
> @@ -216,6 +221,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI2_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> + value = DSI3_SEL_IN_RDMA1;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 20/29] drm/mediatek: add connection from RDMA2 to DPI0
From: CK Hu @ 2018-06-19 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-21-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA2 to DPI0
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index d0d5f337ce14..c88742a6c2b9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -31,6 +31,7 @@
> #define DISP_REG_CONFIG_DSIE_SEL_IN 0x0a4
> #define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT 0x0b8
> #define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> #define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
> @@ -91,7 +92,9 @@
> #define RDMA1_SOUT_DSI1 0x1
> #define RDMA1_SOUT_DSI2 0x4
> #define RDMA1_SOUT_DSI3 0x5
> +#define RDMA2_SOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA1 0x1
> +#define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> @@ -193,6 +196,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DPI0;
> } else {
> value = 0;
> }
> @@ -224,6 +230,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> value = DSI3_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> + value = DPI0_SEL_IN_RDMA2;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 21/29] drm/mediatek: add connection from RDMA2 to DPI1
From: CK Hu @ 2018-06-19 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-22-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA2 to DPI1
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index c88742a6c2b9..a4b418302f32 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -93,9 +93,11 @@
> #define RDMA1_SOUT_DSI2 0x4
> #define RDMA1_SOUT_DSI3 0x5
> #define RDMA2_SOUT_DPI0 0x2
> +#define RDMA2_SOUT_DPI1 0x3
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> +#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> @@ -199,6 +201,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_SOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DPI1;
> } else {
> value = 0;
> }
> @@ -233,6 +238,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> value = DPI0_SEL_IN_RDMA2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> + value = DPI1_SEL_IN_RDMA2;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 22/29] drm/mediatek: add connection from RDMA2 to DSI1
From: CK Hu @ 2018-06-19 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-23-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA2 to DSI1
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a4b418302f32..db78fad785e3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -94,11 +94,13 @@
> #define RDMA1_SOUT_DSI3 0x5
> #define RDMA2_SOUT_DPI0 0x2
> #define RDMA2_SOUT_DPI1 0x3
> +#define RDMA2_SOUT_DSI1 0x1
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> +#define DSI1_SEL_IN_RDMA2 0x4
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -204,6 +206,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI1;
> } else {
> value = 0;
> }
> @@ -241,6 +246,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> value = DPI1_SEL_IN_RDMA2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI1_SEL_IN_RDMA2;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 23/29] drm/mediatek: add connection from RDMA2 to DSI2
From: CK Hu @ 2018-06-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-24-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA2 to DSI2
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index db78fad785e3..e5db1ab51c9b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -95,6 +95,7 @@
> #define RDMA2_SOUT_DPI0 0x2
> #define RDMA2_SOUT_DPI1 0x3
> #define RDMA2_SOUT_DSI1 0x1
> +#define RDMA2_SOUT_DSI2 0x4
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> @@ -102,6 +103,7 @@
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI1_SEL_IN_RDMA2 0x4
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI2_SEL_IN_RDMA2 (0x4 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> @@ -209,6 +211,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI2;
> } else {
> value = 0;
> }
> @@ -249,6 +254,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI1_SEL_IN_RDMA2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI2_SEL_IN_RDMA2;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH v6 24/29] drm/mediatek: add connection from RDMA2 to DSI3
From: CK Hu @ 2018-06-19 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393670-26862-25-git-send-email-stu.hsieh@mediatek.com>
On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA2 to DSI3
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index e5db1ab51c9b..0a1b967cab1b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -96,6 +96,7 @@
> #define RDMA2_SOUT_DPI1 0x3
> #define RDMA2_SOUT_DSI1 0x1
> #define RDMA2_SOUT_DSI2 0x4
> +#define RDMA2_SOUT_DSI3 0x5
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> @@ -105,6 +106,7 @@
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define DSI2_SEL_IN_RDMA2 (0x4 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI3_SEL_IN_RDMA2 (0x4 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -214,6 +216,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI3;
> } else {
> value = 0;
> }
> @@ -257,6 +262,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI2_SEL_IN_RDMA2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI3_SEL_IN_RDMA2;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> value = COLOR1_SEL_IN_OVL1;
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Will Deacon @ 2018-06-19 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d5e01f4bedc649ff8a2ee17b17c1c33d@HXTBJIDCEMVIW02.hxtcorp.net>
On Tue, Jun 19, 2018 at 03:02:15AM +0000, Jin, Yanjiang wrote:
> > You seem to be using this for user-space phys_to_virt() based on values found in
> > /proc/iomem. This should give you what you want, and isolate your user-space
> > from the kernel's unexpected naming of variables.
>
> I don't know could I simplify this problem?
> Let's ignore what memstart_addr represents here, we just want to implement
> phys_to_virt() in an userspace applications(kexec-tools or others).
>
> ARM64 Kernel has a below definition:
>
> #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
>
> So userspace app must know PHYS_OFFSET(equal to memstart_addr now). Seems
> this is very simple, but memstart_addr has gone through several operations
> in arm64_memblock_init() depends on different Kernel configurations, so
> userspace app needs to know many additional definitions as following:
>
> memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP),
> ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET,
> memblock_end_of_DRAM(), IS_ENABLED(CONFIG_RANDOMIZE_BASE),
> memstart_offset_seed.
>
> It is hard to know all above in kexec-tools now. Originally I planned to
> read memstart_addr's value from "/dev/mem", but someone thought not all
> Kernels enable "/dev/mem", we'd better find a more generic approach. So we
> want to get some suggestions from ARM kernel community.
> Can we export this variable in Kernel side through sysconf() or other
> similar methods? Or someone can provide an effect way to get
> memstart_addr's value?
I thought the suggestion from James was to expose this via an ELF NOTE
in kcore and vmcore (or in the header directly if that's possible, but
I'm not sure about it)?
Will
^ permalink raw reply
* [PATCH] serial: mps2-uart: Initialize early console
From: Vladimir Murzin @ 2018-06-19 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529384097-1631-1-git-send-email-linux@roeck-us.net>
Hi Guenter,
On 19/06/18 05:54, Guenter Roeck wrote:
> The early console code for mps2-uart assumes that the serial hardware is
> enabled for transmit when the system boots. However, this is not the case
> after reset. This results in a hang in mps2_early_putchar() if the serial
> transmitter is not enabled by a boot loader or ROM monitor.
I was under impression that for earlycon there is an assumption/requirement
that the serial port must already be setup and configured. For instance, I
see such requirement for pl011. So it looks like boot code's fault not to
enable serial (for mps2 it needs to setup BAUDDIV as well).
I'm not against the patch per se, but I'd like to hear if my understanding of
earlycon requirements is correct or not.
Cheers
Vladimir
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/tty/serial/mps2-uart.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> index 9f8f63719126..0743a0551ce1 100644
> --- a/drivers/tty/serial/mps2-uart.c
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -448,6 +448,14 @@ static struct console mps2_uart_console = {
>
> #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
>
> +static void mps2_early_init(struct uart_port *port)
> +{
> + u8 control = readb(port->membase + UARTn_CTRL);
> +
> + control |= UARTn_CTRL_TX_ENABLE;
> + writeb(control, port->membase + UARTn_CTRL);
> +}
> +
> static void mps2_early_putchar(struct uart_port *port, int ch)
> {
> while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
> @@ -469,6 +477,7 @@ static int __init mps2_early_console_setup(struct earlycon_device *device,
> if (!device->port.membase)
> return -ENODEV;
>
> + mps2_early_init(&device->port);
> device->con->write = mps2_early_write;
>
> return 0;
>
^ permalink raw reply
* [PATCH v2] mmc: sdhci-of-arasan: Add quirk for unstable clocks
From: Adrian Hunter @ 2018-06-19 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615081830.zrgx6arwn6ga27gu@laureti-dev>
On 15/06/18 11:18, Helmut Grohne wrote:
> Some controllers immediately report SDHCI_CLOCK_INT_STABLE after
> enabling the clock even when the clock is not stable. When used in
> conjunction with older/slower cards, this can result in:
>
> mmc0: error -84 whilst initialising SD card
>
> When the stable reporting is broken, we simply wait for the maximum
> stabilization period.
>
> Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 2 ++
> drivers/mmc/host/sdhci-of-arasan.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> Changes since v1 (RFC):
> * Use an arasan-specific quirk in the ->set_clock() callback as requested by
> Adrian Hunter.
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 60481bfc3d31..c0e0f04a8504 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -39,6 +39,8 @@ Optional Properties:
> - xlnx,fails-without-test-cd: when present, the controller doesn't work when
> the CD line is not connected properly, and the line is not connected
> properly. Test mode can be used to force the controller to function.
> + - xlnx,int-clock-stable-broken: when present, the controller always reports
> + that the internal clock is stable even when it is not.
>
> Example:
> sdhci at e0100000 {
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index c33a5f7393bd..f7fe26c75150 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -102,6 +102,9 @@ struct sdhci_arasan_data {
>
> /* Controller does not have CD wired and will not function normally without */
> #define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> +/* Controller immediately reports SDHCI_CLOCK_INT_STABLE after enabling the
> + * internal clock even when the clock isn't stable */
> +#define SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE BIT(1)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -207,6 +210,16 @@ static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
>
> sdhci_set_clock(host, clock);
>
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE)
> + /*
> + * Some controllers immediately report SDHCI_CLOCK_INT_STABLE
> + * after enabling the clock even though the clock is not
> + * stable. Trying to use a clock without waiting here results
> + * in EILSEQ while detecting some older/slower cards. The
> + * chosen delay is the maximum delay from sdhci_set_clock.
> + */
> + msleep(20);
> +
> if (ctrl_phy) {
> phy_power_on(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = true;
> @@ -759,6 +772,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
>
> + if (of_property_read_bool(np, "xlnx,int-clock-stable-broken"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Jin, Yanjiang @ 2018-06-19 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619085541.GB13984@arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: 2018?6?19? 16:56
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
> kernel at lists.infradead.org>
> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
> linear region
>
> On Tue, Jun 19, 2018 at 03:02:15AM +0000, Jin, Yanjiang wrote:
> > > You seem to be using this for user-space phys_to_virt() based on
> > > values found in /proc/iomem. This should give you what you want, and
> > > isolate your user-space from the kernel's unexpected naming of variables.
> >
> > I don't know could I simplify this problem?
> > Let's ignore what memstart_addr represents here, we just want to
> > implement
> > phys_to_virt() in an userspace applications(kexec-tools or others).
> >
> > ARM64 Kernel has a below definition:
> >
> > #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) |
> PAGE_OFFSET)
> >
> > So userspace app must know PHYS_OFFSET(equal to memstart_addr now).
> > Seems this is very simple, but memstart_addr has gone through several
> > operations in arm64_memblock_init() depends on different Kernel
> > configurations, so userspace app needs to know many additional definitions as
> following:
> >
> > memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP),
> > ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET,
> > memblock_end_of_DRAM(), IS_ENABLED(CONFIG_RANDOMIZE_BASE),
> > memstart_offset_seed.
> >
> > It is hard to know all above in kexec-tools now. Originally I planned
> > to read memstart_addr's value from "/dev/mem", but someone thought not
> > all Kernels enable "/dev/mem", we'd better find a more generic
> > approach. So we want to get some suggestions from ARM kernel community.
> > Can we export this variable in Kernel side through sysconf() or other
> > similar methods? Or someone can provide an effect way to get
> > memstart_addr's value?
>
> I thought the suggestion from James was to expose this via an ELF NOTE in kcore
> and vmcore (or in the header directly if that's possible, but I'm not sure about it)?
Hi Will,
Thanks for your reply firstly. But same as DEVMEM, kcore is not a must-have, so we can't depend on it.
On the other hand, phys_to_virt() is called during generating vmcore in Kexec-tools, vmcore also can't help this issue.
Unfortunately, not all platforms support analyzing Kernel config in userspace application, so Kexec-tools can't know some key kernel options. If not so, we can simulate the whole arm64_memblock_init() progress in kexec-tools.
Thanks,
Yanjiang
>
> Will
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Will Deacon @ 2018-06-19 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6860c284f1c74faa95edd6cf866ec80d@HXTBJIDCEMVIW02.hxtcorp.net>
On Tue, Jun 19, 2018 at 09:34:56AM +0000, Jin, Yanjiang wrote:
> > On Tue, Jun 19, 2018 at 03:02:15AM +0000, Jin, Yanjiang wrote:
> > > > You seem to be using this for user-space phys_to_virt() based on
> > > > values found in /proc/iomem. This should give you what you want, and
> > > > isolate your user-space from the kernel's unexpected naming of variables.
> > >
> > > I don't know could I simplify this problem?
> > > Let's ignore what memstart_addr represents here, we just want to
> > > implement
> > > phys_to_virt() in an userspace applications(kexec-tools or others).
> > >
> > > ARM64 Kernel has a below definition:
> > >
> > > #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) |
> > PAGE_OFFSET)
> > >
> > > So userspace app must know PHYS_OFFSET(equal to memstart_addr now).
> > > Seems this is very simple, but memstart_addr has gone through several
> > > operations in arm64_memblock_init() depends on different Kernel
> > > configurations, so userspace app needs to know many additional definitions as
> > following:
> > >
> > > memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP),
> > > ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET,
> > > memblock_end_of_DRAM(), IS_ENABLED(CONFIG_RANDOMIZE_BASE),
> > > memstart_offset_seed.
> > >
> > > It is hard to know all above in kexec-tools now. Originally I planned
> > > to read memstart_addr's value from "/dev/mem", but someone thought not
> > > all Kernels enable "/dev/mem", we'd better find a more generic
> > > approach. So we want to get some suggestions from ARM kernel community.
> > > Can we export this variable in Kernel side through sysconf() or other
> > > similar methods? Or someone can provide an effect way to get
> > > memstart_addr's value?
> >
> > I thought the suggestion from James was to expose this via an ELF NOTE in kcore
> > and vmcore (or in the header directly if that's possible, but I'm not sure about it)?
>
> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
> must-have, so we can't depend on it.
Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
> On the other hand, phys_to_virt() is called during generating vmcore in
> Kexec-tools, vmcore also can't help this issue.
I don't understand this part. If you have the vmcore in your hand, why can't
you grok the pv offset from the note and use that in phys_to_virt()?
> Unfortunately, not all platforms support analyzing Kernel config in
> userspace application, so Kexec-tools can't know some key kernel options.
> If not so, we can simulate the whole arm64_memblock_init() progress in
> kexec-tools.
I don't understand what the kernel config has to do with kexec tools.
Will
^ permalink raw reply
* [PATCH 0/2] KVM: Fix !KVM_COMPAT ioctl behaviour
From: Marc Zyngier @ 2018-06-19 9:42 UTC (permalink / raw)
To: linux-arm-kernel
Mark Rutland recently pointed out that a couple of issues with the way
we deal with compat tasks:
1) arm64 unexpectedly selects KVM_COMPAT, while offering no way for a
32bit userspace to change any register
2) Even deselecting KVM_COMPAT, we end-up with compat_ioctl being NULL,
and the VFS behaviour is thus to call the non-compat ioctl
(1) is completely unintentional and should be fixed. (2) is quite odd,
and probably just as unintentional. This series fixes it by installing
a compat_ioctl callback whose only job is to return -EINVAL.
Tested on arm64 with a 32bit kvmtool.
Marc Zyngier (2):
KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
KVM: arm64: Prevent KVM_COMPAT from being selected
virt/kvm/Kconfig | 2 +-
virt/kvm/kvm_main.c | 19 +++++++++----------
2 files changed, 10 insertions(+), 11 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Marc Zyngier @ 2018-06-19 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619094251.8586-1-marc.zyngier@arm.com>
The current behaviour of the compat ioctls is a bit odd.
We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
otherwise. But NULL means that the normal, non-compat ioctl should
be used directly for compat tasks, and there is no way to actually
prevent a compat task from issueing KVM ioctls.
This patch changes this behaviour, by always registering a compat_ioctl
method, even if KVM_COMPAT is not selected. In that case, the callback
will always return -EINVAL.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/kvm_main.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ada21f47f22b..8b47507faab5 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -116,6 +116,11 @@ static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
#ifdef CONFIG_KVM_COMPAT
static long kvm_vcpu_compat_ioctl(struct file *file, unsigned int ioctl,
unsigned long arg);
+#define KVM_COMPAT(c) .compat_ioctl = (c)
+#else
+static long kvm_no_compat_ioctl(struct file *file, unsigned int ioctl,
+ unsigned long arg) { return -EINVAL; }
+#define KVM_COMPAT(c) .compat_ioctl = kvm_no_compat_ioctl
#endif
static int hardware_enable_all(void);
static void hardware_disable_all(void);
@@ -2396,11 +2401,9 @@ static int kvm_vcpu_release(struct inode *inode, struct file *filp)
static struct file_operations kvm_vcpu_fops = {
.release = kvm_vcpu_release,
.unlocked_ioctl = kvm_vcpu_ioctl,
-#ifdef CONFIG_KVM_COMPAT
- .compat_ioctl = kvm_vcpu_compat_ioctl,
-#endif
.mmap = kvm_vcpu_mmap,
.llseek = noop_llseek,
+ KVM_COMPAT(kvm_vcpu_compat_ioctl),
};
/*
@@ -2824,10 +2827,8 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
static const struct file_operations kvm_device_fops = {
.unlocked_ioctl = kvm_device_ioctl,
-#ifdef CONFIG_KVM_COMPAT
- .compat_ioctl = kvm_device_ioctl,
-#endif
.release = kvm_device_release,
+ KVM_COMPAT(kvm_device_ioctl),
};
struct kvm_device *kvm_device_from_filp(struct file *filp)
@@ -3165,10 +3166,8 @@ static long kvm_vm_compat_ioctl(struct file *filp,
static struct file_operations kvm_vm_fops = {
.release = kvm_vm_release,
.unlocked_ioctl = kvm_vm_ioctl,
-#ifdef CONFIG_KVM_COMPAT
- .compat_ioctl = kvm_vm_compat_ioctl,
-#endif
.llseek = noop_llseek,
+ KVM_COMPAT(kvm_vm_compat_ioctl),
};
static int kvm_dev_ioctl_create_vm(unsigned long type)
@@ -3259,8 +3258,8 @@ static long kvm_dev_ioctl(struct file *filp,
static struct file_operations kvm_chardev_ops = {
.unlocked_ioctl = kvm_dev_ioctl,
- .compat_ioctl = kvm_dev_ioctl,
.llseek = noop_llseek,
+ KVM_COMPAT(kvm_dev_ioctl),
};
static struct miscdevice kvm_dev = {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] KVM: arm64: Prevent KVM_COMPAT from being selected
From: Marc Zyngier @ 2018-06-19 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619094251.8586-1-marc.zyngier@arm.com>
There is very little point in trying to support the 32bit KVM/arm API
on arm64, and this was never an anticipated use case.
Let's make it clear by not selecting KVM_COMPAT.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
index 72143cfaf6ec..ea434ddc8499 100644
--- a/virt/kvm/Kconfig
+++ b/virt/kvm/Kconfig
@@ -47,7 +47,7 @@ config KVM_GENERIC_DIRTYLOG_READ_PROTECT
config KVM_COMPAT
def_bool y
- depends on KVM && COMPAT && !S390
+ depends on KVM && COMPAT && !(S390 || ARM64)
config HAVE_KVM_IRQ_BYPASS
bool
--
2.17.1
^ permalink raw reply related
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Jin, Yanjiang @ 2018-06-19 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619094045.GD13984@arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: 2018?6?19? 17:41
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
> kernel at lists.infradead.org>
> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
> linear region
>
> On Tue, Jun 19, 2018 at 09:34:56AM +0000, Jin, Yanjiang wrote:
> > > On Tue, Jun 19, 2018 at 03:02:15AM +0000, Jin, Yanjiang wrote:
> > > > > You seem to be using this for user-space phys_to_virt() based on
> > > > > values found in /proc/iomem. This should give you what you want,
> > > > > and isolate your user-space from the kernel's unexpected naming of
> variables.
> > > >
> > > > I don't know could I simplify this problem?
> > > > Let's ignore what memstart_addr represents here, we just want to
> > > > implement
> > > > phys_to_virt() in an userspace applications(kexec-tools or others).
> > > >
> > > > ARM64 Kernel has a below definition:
> > > >
> > > > #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) |
> > > PAGE_OFFSET)
> > > >
> > > > So userspace app must know PHYS_OFFSET(equal to memstart_addr now).
> > > > Seems this is very simple, but memstart_addr has gone through
> > > > several operations in arm64_memblock_init() depends on different
> > > > Kernel configurations, so userspace app needs to know many
> > > > additional definitions as
> > > following:
> > > >
> > > > memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP),
> > > > ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET,
> > > > memblock_end_of_DRAM(), IS_ENABLED(CONFIG_RANDOMIZE_BASE),
> > > > memstart_offset_seed.
> > > >
> > > > It is hard to know all above in kexec-tools now. Originally I
> > > > planned to read memstart_addr's value from "/dev/mem", but someone
> > > > thought not all Kernels enable "/dev/mem", we'd better find a more
> > > > generic approach. So we want to get some suggestions from ARM kernel
> community.
> > > > Can we export this variable in Kernel side through sysconf() or
> > > > other similar methods? Or someone can provide an effect way to get
> > > > memstart_addr's value?
> > >
> > > I thought the suggestion from James was to expose this via an ELF
> > > NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm
> not sure about it)?
> >
> > Thanks for your reply firstly. But same as DEVMEM, kcore is not a
> > must-have, so we can't depend on it.
>
> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
>
> > On the other hand, phys_to_virt() is called during generating vmcore
> > in Kexec-tools, vmcore also can't help this issue.
>
> I don't understand this part. If you have the vmcore in your hand, why can't you
> grok the pv offset from the note and use that in phys_to_virt()?
It is a chicken-and-egg issue.
phys_to virt() is for crashdump setup. To generate vmcore, we must call phys_to_virt(). At this point, no vmcore exists.
Yanjiang
>
> > Unfortunately, not all platforms support analyzing Kernel config in
> > userspace application, so Kexec-tools can't know some key kernel options.
> > If not so, we can simulate the whole arm64_memblock_init() progress
> > in kexec-tools.
>
> I don't understand what the kernel config has to do with kexec tools.
I mean that if we can know kernel .config in all circumstances, we can calculate memstart_addr as below in Kexec-tools:
memstart_addr = round_down(memblock_start_of_DRAM(),
ARM64_MEMSTART_ALIGN);
#if defined(CONFIG_SPARSEMEM_VMEMMAP) && ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
#define ARM64_MEMSTART_ALIGN (1UL << SECTION_SIZE_BITS)
......
#endif
#define ARM64_MEMSTART_SHIFT PMD_SHIFT
#if CONFIG_PGTABLE_LEVELS > 2
#define PMD_SHIFT ARM64_HW_PGTABLE_LEVEL_SHIFT(2)
...........
#endif
Yanjiang
>
> Will
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
^ permalink raw reply
* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Mark Rutland @ 2018-06-19 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619094251.8586-2-marc.zyngier@arm.com>
On Tue, Jun 19, 2018 at 10:42:50AM +0100, Marc Zyngier wrote:
> The current behaviour of the compat ioctls is a bit odd.
> We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
> otherwise. But NULL means that the normal, non-compat ioctl should
> be used directly for compat tasks, and there is no way to actually
> prevent a compat task from issueing KVM ioctls.
>
> This patch changes this behaviour, by always registering a compat_ioctl
> method, even if KVM_COMPAT is not selected. In that case, the callback
> will always return -EINVAL.
>
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
I virt/kvm/Kconfig we have:
config KVM_COMPAT
def_bool y
depends on KVM && COMPAT && !S390
... and in arch/s390 we have COMPAT support, so does this potentially break
anything there?
Thanks,
Mark.
> ---
> virt/kvm/kvm_main.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ada21f47f22b..8b47507faab5 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -116,6 +116,11 @@ static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
> #ifdef CONFIG_KVM_COMPAT
> static long kvm_vcpu_compat_ioctl(struct file *file, unsigned int ioctl,
> unsigned long arg);
> +#define KVM_COMPAT(c) .compat_ioctl = (c)
> +#else
> +static long kvm_no_compat_ioctl(struct file *file, unsigned int ioctl,
> + unsigned long arg) { return -EINVAL; }
> +#define KVM_COMPAT(c) .compat_ioctl = kvm_no_compat_ioctl
> #endif
> static int hardware_enable_all(void);
> static void hardware_disable_all(void);
> @@ -2396,11 +2401,9 @@ static int kvm_vcpu_release(struct inode *inode, struct file *filp)
> static struct file_operations kvm_vcpu_fops = {
> .release = kvm_vcpu_release,
> .unlocked_ioctl = kvm_vcpu_ioctl,
> -#ifdef CONFIG_KVM_COMPAT
> - .compat_ioctl = kvm_vcpu_compat_ioctl,
> -#endif
> .mmap = kvm_vcpu_mmap,
> .llseek = noop_llseek,
> + KVM_COMPAT(kvm_vcpu_compat_ioctl),
> };
>
> /*
> @@ -2824,10 +2827,8 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
>
> static const struct file_operations kvm_device_fops = {
> .unlocked_ioctl = kvm_device_ioctl,
> -#ifdef CONFIG_KVM_COMPAT
> - .compat_ioctl = kvm_device_ioctl,
> -#endif
> .release = kvm_device_release,
> + KVM_COMPAT(kvm_device_ioctl),
> };
>
> struct kvm_device *kvm_device_from_filp(struct file *filp)
> @@ -3165,10 +3166,8 @@ static long kvm_vm_compat_ioctl(struct file *filp,
> static struct file_operations kvm_vm_fops = {
> .release = kvm_vm_release,
> .unlocked_ioctl = kvm_vm_ioctl,
> -#ifdef CONFIG_KVM_COMPAT
> - .compat_ioctl = kvm_vm_compat_ioctl,
> -#endif
> .llseek = noop_llseek,
> + KVM_COMPAT(kvm_vm_compat_ioctl),
> };
>
> static int kvm_dev_ioctl_create_vm(unsigned long type)
> @@ -3259,8 +3258,8 @@ static long kvm_dev_ioctl(struct file *filp,
>
> static struct file_operations kvm_chardev_ops = {
> .unlocked_ioctl = kvm_dev_ioctl,
> - .compat_ioctl = kvm_dev_ioctl,
> .llseek = noop_llseek,
> + KVM_COMPAT(kvm_dev_ioctl),
> };
>
> static struct miscdevice kvm_dev = {
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH] iommu/io-pgtable-arm: Fix pgtable allocation in selftest
From: Will Deacon @ 2018-06-19 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618112754.24942-1-jean-philippe.brucker@arm.com>
On Mon, Jun 18, 2018 at 12:27:54PM +0100, Jean-Philippe Brucker wrote:
> Commit 4b123757eeaa ("iommu/io-pgtable-arm: Make allocations
> NUMA-aware") added a NUMA hint to page table allocation, but the pgtable
> selftest doesn't provide an SMMU device parameter. Since dev_to_node
> doesn't accept a NULL argument, add a special case for selftest.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Thanks, I'll pick this up.
Will
^ permalink raw reply
* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Marc Zyngier @ 2018-06-19 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619100134.4loab4jtnfdzrpxu@lakrids.cambridge.arm.com>
On 19/06/18 11:01, Mark Rutland wrote:
> On Tue, Jun 19, 2018 at 10:42:50AM +0100, Marc Zyngier wrote:
>> The current behaviour of the compat ioctls is a bit odd.
>> We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
>> otherwise. But NULL means that the normal, non-compat ioctl should
>> be used directly for compat tasks, and there is no way to actually
>> prevent a compat task from issueing KVM ioctls.
>>
>> This patch changes this behaviour, by always registering a compat_ioctl
>> method, even if KVM_COMPAT is not selected. In that case, the callback
>> will always return -EINVAL.
>>
>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> I virt/kvm/Kconfig we have:
>
> config KVM_COMPAT
> def_bool y
> depends on KVM && COMPAT && !S390
>
> ... and in arch/s390 we have COMPAT support, so does this potentially break
> anything there?
It doesn't seem to (COMPAT seems to support the 31 bit stuff, which I
don't think ever had KVM support), but my s390-foo is quite basic.
Christian, could you help here?
Thanks,
M.
>
> Thanks,
> Mark.
>
>> ---
>> virt/kvm/kvm_main.c | 19 +++++++++----------
>> 1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index ada21f47f22b..8b47507faab5 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -116,6 +116,11 @@ static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
>> #ifdef CONFIG_KVM_COMPAT
>> static long kvm_vcpu_compat_ioctl(struct file *file, unsigned int ioctl,
>> unsigned long arg);
>> +#define KVM_COMPAT(c) .compat_ioctl = (c)
>> +#else
>> +static long kvm_no_compat_ioctl(struct file *file, unsigned int ioctl,
>> + unsigned long arg) { return -EINVAL; }
>> +#define KVM_COMPAT(c) .compat_ioctl = kvm_no_compat_ioctl
>> #endif
>> static int hardware_enable_all(void);
>> static void hardware_disable_all(void);
>> @@ -2396,11 +2401,9 @@ static int kvm_vcpu_release(struct inode *inode, struct file *filp)
>> static struct file_operations kvm_vcpu_fops = {
>> .release = kvm_vcpu_release,
>> .unlocked_ioctl = kvm_vcpu_ioctl,
>> -#ifdef CONFIG_KVM_COMPAT
>> - .compat_ioctl = kvm_vcpu_compat_ioctl,
>> -#endif
>> .mmap = kvm_vcpu_mmap,
>> .llseek = noop_llseek,
>> + KVM_COMPAT(kvm_vcpu_compat_ioctl),
>> };
>>
>> /*
>> @@ -2824,10 +2827,8 @@ static int kvm_device_release(struct inode *inode, struct file *filp)
>>
>> static const struct file_operations kvm_device_fops = {
>> .unlocked_ioctl = kvm_device_ioctl,
>> -#ifdef CONFIG_KVM_COMPAT
>> - .compat_ioctl = kvm_device_ioctl,
>> -#endif
>> .release = kvm_device_release,
>> + KVM_COMPAT(kvm_device_ioctl),
>> };
>>
>> struct kvm_device *kvm_device_from_filp(struct file *filp)
>> @@ -3165,10 +3166,8 @@ static long kvm_vm_compat_ioctl(struct file *filp,
>> static struct file_operations kvm_vm_fops = {
>> .release = kvm_vm_release,
>> .unlocked_ioctl = kvm_vm_ioctl,
>> -#ifdef CONFIG_KVM_COMPAT
>> - .compat_ioctl = kvm_vm_compat_ioctl,
>> -#endif
>> .llseek = noop_llseek,
>> + KVM_COMPAT(kvm_vm_compat_ioctl),
>> };
>>
>> static int kvm_dev_ioctl_create_vm(unsigned long type)
>> @@ -3259,8 +3258,8 @@ static long kvm_dev_ioctl(struct file *filp,
>>
>> static struct file_operations kvm_chardev_ops = {
>> .unlocked_ioctl = kvm_dev_ioctl,
>> - .compat_ioctl = kvm_dev_ioctl,
>> .llseek = noop_llseek,
>> + KVM_COMPAT(kvm_dev_ioctl),
>> };
>>
>> static struct miscdevice kvm_dev = {
>> --
>> 2.17.1
>>
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/2] KVM: arm64: Prevent KVM_COMPAT from being selected
From: Mark Rutland @ 2018-06-19 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619094251.8586-3-marc.zyngier@arm.com>
On Tue, Jun 19, 2018 at 10:42:51AM +0100, Marc Zyngier wrote:
> There is very little point in trying to support the 32bit KVM/arm API
> on arm64, and this was never an anticipated use case.
>
> Let's make it clear by not selecting KVM_COMPAT.
Do any other architectures have KVM && COMPAT, and expose an
incompatible ABI to COMPAT tasks?
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Given the state of arm/arm64, this makes sense to me. FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
> ---
> virt/kvm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> index 72143cfaf6ec..ea434ddc8499 100644
> --- a/virt/kvm/Kconfig
> +++ b/virt/kvm/Kconfig
> @@ -47,7 +47,7 @@ config KVM_GENERIC_DIRTYLOG_READ_PROTECT
>
> config KVM_COMPAT
> def_bool y
> - depends on KVM && COMPAT && !S390
> + depends on KVM && COMPAT && !(S390 || ARM64)
>
> config HAVE_KVM_IRQ_BYPASS
> bool
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Jon Hunter @ 2018-06-19 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On 17/06/18 15:31, Jonathan Neusch?fer wrote:
> Multiple binding documents have various forms of unbalanced quotation
> marks. Fix them.
>
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer@gmx.net>
> ---
>
> Should I split this patch so that different parts can go through different trees?
> ---
> .../devicetree/bindings/arm/samsung/samsung-boards.txt | 2 +-
> .../devicetree/bindings/gpio/nintendo,hollywood-gpio.txt | 2 +-
> Documentation/devicetree/bindings/input/touchscreen/hideep.txt | 2 +-
> .../bindings/interrupt-controller/nvidia,tegra20-ictlr.txt | 2 +-
> .../devicetree/bindings/interrupt-controller/st,stm32-exti.txt | 2 +-
> Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
> Documentation/devicetree/bindings/net/fsl-fman.txt | 2 +-
> Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
> Documentation/devicetree/bindings/regulator/tps65090.txt | 2 +-
> Documentation/devicetree/bindings/reset/st,sti-softreset.txt | 2 +-
> Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt | 2 +-
> Documentation/devicetree/bindings/sound/qcom,apq8096.txt | 2 +-
> 12 files changed, 12 insertions(+), 12 deletions(-)
...
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
> index 1099fe0788fa..f246ccbf8838 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
> @@ -15,7 +15,7 @@ Required properties:
> include "nvidia,tegra30-ictlr".
> - reg : Specifies base physical address and size of the registers.
> Each controller must be described separately (Tegra20 has 4 of them,
> - whereas Tegra30 and later have 5"
> + whereas Tegra30 and later have 5).
> - interrupt-controller : Identifies the node as an interrupt controller.
> - #interrupt-cells : Specifies the number of cells needed to encode an
> interrupt source. The value must be 3.
For the above Tegra portion ...
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 0/7] arm64: perf: Support for chained counters
From: Suzuki K Poulose @ 2018-06-19 10:15 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for counting PMU events using 64bit counters
for arm64 PMU.
The Arm v8 PMUv3 supports combining two adjacent 32bit counters
(low even and hig odd counters) to count a given "event" in 64bit mode.
This series adds the support for 64bit events in the core arm_pmu driver
infrastructure and adds the support for armv8 64bit kernel PMU to use
chained counters to count in 64bit mode. For CPU cycles, we use the cycle
counter in 64bit mode, only when requested. If the cycle counter is not
available, we fall back to chaining the counters.
Tested on Juno, Fast models. Applies on 4.18-rc1
Changes since v2:
- Clean up select counter routine. (Mark Rutland)
- Stop PMU while processing overflows (Mark Rutland)
- Drop special allocation algorithm for chain indices
- Since we access the counters when the PMU is stopped,
get rid of the unncessary barriers.
- Ensure a counter is allocated when checking for chained event
Change since v1:
- Remove unnecessary isb()s in chain counter reads/writes
- Fix event programming order for counters
- Tighten chain counter event read sequence
- Set chain event to count in all ELs
- Cleanup helpers to be consistent
- Fix build break on xcale PMU (reported by kbuild-robot)
- Remove the explicit counter width field from pmu backends and default
to 32bit.
- Rename flag ARMPMU_EVT_LONG => ARMPMU_EVT_64BIT and
the format string "chain" => "bits64". (Unfortunately we can't use "64bit"
and I am open for suggestion on a better name)
- Rename armpmu_get_event_max_period() => armpmu_event_max_period()
- For 64bit CPU cycles events, allow chaining if cycle counter is
not available.
Suzuki K Poulose (7):
arm_pmu: Clean up maximum period handling
arm_pmu: Change API to support 64bit counter values
arm_pmu: Add support for 64bit event counters
arm_pmu: Tidy up clear_event_idx call backs
arm64: perf: Clean up armv8pmu_select_counter
arm64: perf: Disable PMU while processing counter overflows
arm64: perf: Add support for chaining event counters
arch/arm/kernel/perf_event_v6.c | 6 +-
arch/arm/kernel/perf_event_v7.c | 7 +-
arch/arm/kernel/perf_event_xscale.c | 10 +-
arch/arm64/kernel/perf_event.c | 249 +++++++++++++++++++++++++++++-------
drivers/perf/arm_pmu.c | 51 +++++---
include/linux/perf/arm_pmu.h | 11 +-
6 files changed, 255 insertions(+), 79 deletions(-)
--
2.7.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox