* [PATCH v2 1/2] arm64: capabilities: add nopti command line argument
From: Mark Langsdorf @ 2018-05-31 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531170832.14263-1-mlangsdo@redhat.com>
The x86 kernel and the documentation use 'nopti' as the kernel command
line argument to disable kernel page table isolation, so add nopti to
the arm64 kernel for compatibility.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 19 +++++++++++++++----
arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2040d4..cf0c728 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3342,8 +3342,8 @@
pt. [PARIDE]
See Documentation/blockdev/paride.txt.
- pti= [X86_64] Control Page Table Isolation of user and
- kernel address spaces. Disabling this feature
+ pti= [X86_64] Control Page Table Isolation of user
+ and kernel address spaces. Disabling this feature
removes hardening, but improves performance of
system calls and interrupts.
@@ -3354,8 +3354,19 @@
Not specifying this option is equivalent to pti=auto.
- nopti [X86_64]
- Equivalent to pti=off
+ kpti= [ARM64] Control Page Table Isolation of user
+ and kernel address spaces. Disabling this feature
+ removes hardening, but improves performance of
+ system calls and interrupts.
+
+ on - unconditionally enable
+ off - unconditionally disable
+
+ Not specifying this option will enable kpti on all
+ systems that support it.
+
+ nopti [X86_64, ARM64]
+ Equivalent to pti=off on X86_64 or kpti=off on ARM64
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d..7c5d8712 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -934,10 +934,19 @@ static int __init parse_kpti(char *str)
if (ret)
return ret;
- __kpti_forced = enabled ? 1 : -1;
+ if (!__kpti_forced)
+ __kpti_forced = enabled ? 1 : -1;
return 0;
}
__setup("kpti=", parse_kpti);
+
+/* for compatibility with documentation and x86 nopti command line arg */
+static int __init force_nokpti(char *arg)
+{
+ __kpti_forced = -1;
+ return 0;
+}
+early_param("nopti", force_nokpti);
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
#ifdef CONFIG_ARM64_HW_AFDBM
--
2.9.5
^ permalink raw reply related
* [PATCH v2 2/2] arm64: cpufeature: always log KPTI setting on boot
From: Mark Langsdorf @ 2018-05-31 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531170832.14263-1-mlangsdo@redhat.com>
Always log KPTI setting at boot time, whether or not KPTI was forced
by a kernel parameter.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
---
arch/arm64/kernel/cpufeature.c | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 7c5d8712..2bfbbe4 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -860,6 +860,7 @@ static bool has_cache_dic(const struct arm64_cpu_capabilities *entry,
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
+static bool __pti_enabled;
static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
int scope)
@@ -884,21 +885,26 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
/* Forced? */
if (__kpti_forced) {
+ __pti_enabled = __kpti_forced > 0;
pr_info_once("kernel page table isolation forced %s by %s\n",
- __kpti_forced > 0 ? "ON" : "OFF", str);
- return __kpti_forced > 0;
- }
-
- /* Useful for KASLR robustness */
- if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
- return true;
+ __pti_enabled ? "ON" : "OFF", str);
+ } else {
+ str = "default";
+ /* Useful for KASLR robustness */
+ if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
+ __pti_enabled = true;
+ /* Don't force KPTI for CPUs that are not vulnerable */
+ else if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+ __pti_enabled = false;
+ /* Defer to CPU feature registers */
+ else
+ __pti_enabled = !has_cpuid_feature(entry, scope);
- /* Don't force KPTI for CPUs that are not vulnerable */
- if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
- return false;
+ pr_info_once("kernel page table isolation %s by %s\n",
+ __pti_enabled ? "ON" : "OFF", str);
+ }
- /* Defer to CPU feature registers */
- return !has_cpuid_feature(entry, scope);
+ return __pti_enabled;
}
static void
--
2.9.5
^ permalink raw reply related
* [PATCH 0/5] rpmsg: Convert to use SPDX license identifiers
From: Suman Anna @ 2018-05-31 17:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Bjorn,
The following series switches over the current licensing text in
various rpmsg drivers to the SPDX licensing format. I see that you
have already picked up my series for the HwSpinlock drivers, so this
series does the same for the rpmsg drivers. Please pick these as well
for 4.18. Patches done on top of latest upstream kernel.
regards
Suman
Suman Anna (5):
rpmsg: Switch to SPDX license identifier
rpmsg: virtio_rpmsg_bus: Switch to SPDX license identifier
rpmsg: smd: Switch to SPDX license identifier
rpmsg: glink: Switch to SPDX license identifier
rpmsg: char: Switch to SPDX license identifier
drivers/rpmsg/Kconfig | 2 ++
drivers/rpmsg/qcom_glink_native.c | 10 +---------
drivers/rpmsg/qcom_glink_native.h | 10 +---------
drivers/rpmsg/qcom_glink_rpm.c | 10 +---------
drivers/rpmsg/qcom_glink_smem.c | 10 +---------
drivers/rpmsg/qcom_smd.c | 10 +---------
drivers/rpmsg/rpmsg_char.c | 10 +---------
drivers/rpmsg/rpmsg_core.c | 10 +---------
drivers/rpmsg/rpmsg_internal.h | 10 +---------
drivers/rpmsg/virtio_rpmsg_bus.c | 10 +---------
include/linux/rpmsg.h | 27 +--------------------------
include/linux/rpmsg/qcom_glink.h | 2 ++
include/uapi/linux/rpmsg.h | 9 ---------
13 files changed, 14 insertions(+), 116 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH 1/5] rpmsg: Switch to SPDX license identifier
From: Suman Anna @ 2018-05-31 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531171103.8703-1-s-anna@ti.com>
Use the appropriate SPDX license identifier in the rpmsg core
source files and drop the previous boilerplate license text.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/rpmsg/Kconfig | 2 ++
drivers/rpmsg/rpmsg_core.c | 10 +---------
drivers/rpmsg/rpmsg_internal.h | 10 +---------
include/linux/rpmsg.h | 27 +--------------------------
4 files changed, 5 insertions(+), 44 deletions(-)
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index 65a9f6b892f0..15e7b94dda5e 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
menu "Rpmsg drivers"
# RPMSG always gets selected by whoever wants it
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index 920a02f0462c..7a57753ad0a1 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* remote processor messaging bus
*
@@ -6,15 +7,6 @@
*
* Ohad Ben-Cohen <ohad@wizery.com>
* Brian Swetland <swetland@google.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#define pr_fmt(fmt) "%s: " fmt, __func__
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 685aa70e9cbe..0d791c30b7ea 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* remote processor messaging bus internals
*
@@ -6,15 +7,6 @@
*
* Ohad Ben-Cohen <ohad@wizery.com>
* Brian Swetland <swetland@google.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef __RPMSG_INTERNAL_H__
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index ca07366c4c33..9fe156d1c018 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -1,35 +1,10 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
/*
* Remote processor messaging
*
* Copyright (C) 2011 Texas Instruments, Inc.
* Copyright (C) 2011 Google, Inc.
* All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * * Neither the name Texas Instruments nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef _LINUX_RPMSG_H
--
2.17.0
^ permalink raw reply related
* [PATCH 2/5] rpmsg: virtio_rpmsg_bus: Switch to SPDX license identifier
From: Suman Anna @ 2018-05-31 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531171103.8703-1-s-anna@ti.com>
Use the appropriate SPDX license identifier in the virtio rpmsg
bus driver source file and drop the previous boilerplate license
text.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/rpmsg/virtio_rpmsg_bus.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 82b83002fcba..664f957012cd 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Virtio-based remote processor messaging bus
*
@@ -6,15 +7,6 @@
*
* Ohad Ben-Cohen <ohad@wizery.com>
* Brian Swetland <swetland@google.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#define pr_fmt(fmt) "%s: " fmt, __func__
--
2.17.0
^ permalink raw reply related
* [PATCH 3/5] rpmsg: smd: Switch to SPDX license identifier
From: Suman Anna @ 2018-05-31 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531171103.8703-1-s-anna@ti.com>
Use the appropriate SPDX license identifier in the rpmsg SMD backend
driver source file and drop the previous boilerplate license text.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/rpmsg/qcom_smd.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
index 5ce9bf7b897d..0819836fc178 100644
--- a/drivers/rpmsg/qcom_smd.c
+++ b/drivers/rpmsg/qcom_smd.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015, Sony Mobile Communications AB.
* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/interrupt.h>
--
2.17.0
^ permalink raw reply related
* [PATCH 4/5] rpmsg: glink: Switch to SPDX license identifier
From: Suman Anna @ 2018-05-31 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531171103.8703-1-s-anna@ti.com>
Use the appropriate SPDX license identifier in various rpmsg
glink driver source files and drop the previous boilerplate
license text.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/rpmsg/qcom_glink_native.c | 10 +---------
drivers/rpmsg/qcom_glink_native.h | 10 +---------
drivers/rpmsg/qcom_glink_rpm.c | 10 +---------
drivers/rpmsg/qcom_glink_smem.c | 10 +---------
include/linux/rpmsg/qcom_glink.h | 2 ++
5 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index 768ef542a841..f505f58b797d 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1,14 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2016-2017, Linaro Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/idr.h>
diff --git a/drivers/rpmsg/qcom_glink_native.h b/drivers/rpmsg/qcom_glink_native.h
index 0cae8a8199f8..624184fc458e 100644
--- a/drivers/rpmsg/qcom_glink_native.h
+++ b/drivers/rpmsg/qcom_glink_native.h
@@ -1,14 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (c) 2016-2017, Linaro Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef __QCOM_GLINK_NATIVE_H__
diff --git a/drivers/rpmsg/qcom_glink_rpm.c b/drivers/rpmsg/qcom_glink_rpm.c
index 69b25d157d0f..f64f45d1a735 100644
--- a/drivers/rpmsg/qcom_glink_rpm.c
+++ b/drivers/rpmsg/qcom_glink_rpm.c
@@ -1,14 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2016-2017, Linaro Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/idr.h>
diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
index 3fa9d43e2c87..2b5cf2790954 100644
--- a/drivers/rpmsg/qcom_glink_smem.c
+++ b/drivers/rpmsg/qcom_glink_smem.c
@@ -1,14 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2016, Linaro Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/io.h>
diff --git a/include/linux/rpmsg/qcom_glink.h b/include/linux/rpmsg/qcom_glink.h
index a622f029836e..96e26d94719f 100644
--- a/include/linux/rpmsg/qcom_glink.h
+++ b/include/linux/rpmsg/qcom_glink.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
#ifndef _LINUX_RPMSG_QCOM_GLINK_H
#define _LINUX_RPMSG_QCOM_GLINK_H
--
2.17.0
^ permalink raw reply related
* [PATCH 5/5] rpmsg: char: Switch to SPDX license identifier
From: Suman Anna @ 2018-05-31 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531171103.8703-1-s-anna@ti.com>
Use the appropriate SPDX license identifier in the rpmsg char driver
source file and drop the previous boilerplate license text. The uapi
header file already had the SPDX license identifier added as part of
a mass update but the license text removal was deferred for later,
and this patch drops the same.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/rpmsg/rpmsg_char.c | 10 +---------
include/uapi/linux/rpmsg.h | 9 ---------
2 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index 1efdf9ff8679..76a4477c6364 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2016, Linaro Ltd.
* Copyright (c) 2012, Michal Simek <monstr@monstr.eu>
@@ -7,15 +8,6 @@
*
* Based on rpmsg performance statistics driver by Michal Simek, which in turn
* was based on TI & Google OMX rpmsg driver.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/cdev.h>
#include <linux/device.h>
diff --git a/include/uapi/linux/rpmsg.h b/include/uapi/linux/rpmsg.h
index 225eb38705dc..e14c6dab4223 100644
--- a/include/uapi/linux/rpmsg.h
+++ b/include/uapi/linux/rpmsg.h
@@ -1,15 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
* Copyright (c) 2016, Linaro Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef _UAPI_RPMSG_H_
--
2.17.0
^ permalink raw reply related
* [linux-sunxi] [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-05-31 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAP03XeoY8_-gG-2h8WP+3ZZFzxeyHERG=o7Y3Btk2svy5kco_Q@mail.gmail.com>
On Thu, May 31, 2018 at 10:25 PM, Christopher Obbard <chris@64studio.com> wrote:
> Hi Jagan,
>
> I cannot find any information on this board online, so I am guessing
> it has not been released yet and you are developing software support
> now.
>
> Do you have any datasheet/overview document of the board?
It's an industrial board for a real product and not so different than
what we supported a software for other A64 boards [1], I will update
the wiki for the same in couple of days.
[1] https://openedev.amarulasolutions.com/display/ODWIKI/A64
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH 1/2] dt-bindings: Add vendor prefix for ArcherMind
From: Rob Herring @ 2018-05-31 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529045258.1415-2-manivannan.sadhasivam@linaro.org>
On Tue, May 29, 2018 at 10:22:57AM +0530, Manivannan Sadhasivam wrote:
> Add vendor prefix for ArcherMind Technology (Nanjing) Co., Ltd.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
I've applied this while you all debate the dts file.
Rob
^ permalink raw reply
* [PATCH 2/2] arm64: dts: Add Mediatek X20 Development Board support
From: Rob Herring @ 2018-05-31 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529045258.1415-3-manivannan.sadhasivam@linaro.org>
tOn Tue, May 29, 2018 at 10:22:58AM +0530, Manivannan Sadhasivam wrote:
> Add initial device tree support for Mediatek X20 Development Board
> based on MT6797 Deca core SoC. This board is one of the 96Boards
> Consumer Edition platform.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index ac17f60f998c..5b7fd6ad96e4 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> new file mode 100644
> index 000000000000..2c09ca95d9e2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for MediaTek X20 Development Board
> + *
> + * Copyright (C) 2018, Linaro Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "mt6797.dtsi"
> +
> +/ {
> + model = "Mediatek X20 Development Board";
> + compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
The board compatible needs documenting.
> +
> + aliases {
> + serial0 = &uart1;
> + };
> +
> + memory at 40000000 {
> + device_type = "memory";
> + reg = <0 0x40000000 0 0x1e605000>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v5 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-31 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530104853.GB22983@e103592.cambridge.arm.com>
On Wed, May 30, 2018 at 11:48:59AM +0100, Dave Martin wrote:
> On Tue, May 29, 2018 at 09:42:31PM +0100, Will Deacon wrote:
> > On Fri, May 25, 2018 at 04:17:08PM +0100, Dave Martin wrote:
> > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > > index fac1c4d..8cf112b 100644
> > > --- a/arch/arm64/include/asm/elf.h
> > > +++ b/arch/arm64/include/asm/elf.h
> > > @@ -121,6 +121,9 @@
> > >
> > > #ifndef __ASSEMBLY__
> > >
> > > +#include <linux/bug.h>
> > > +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> > > +
> > > typedef unsigned long elf_greg_t;
> > >
> > > #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> > > @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> > > do { \
> > > NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> > > (elf_addr_t)current->mm->context.vdso); \
> > > + \
> > > + /* \
> > > + * Should always be nonzero unless there's a kernel bug. \
> > > + * If we haven't determined a sensible value to give to \
> > > + * userspace, omit the entry: \
> > > + */ \
> > > + if (likely(signal_minsigstksz)) \
> > > + NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
> > > } while (0)
> >
> > I think this is the desired behaviour, but now I'm worried that we're forced
> > to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the
> > ELF loader deals with this gracefuly, the FDPIC loader looks a lot less
> > robust (in particular, my reading is that it decrements the stack pointer
> > and then pushes these entries in reverse order by overloading NEW_AUX_ENT).
>
> config BINFMT_ELF_FDPIC
> /* ... */
> depends on (ARM || (SUPERH32 & !MMU) || C6X)
Ok, that's a relief. The checkpoint stuff is still a bit worrying though
(prctl_set_mm_map).
> The FDPIC loader seems to assume it's 32-bit only and also looks broken
> with regard to auxv:
>
> /* force 16 byte _final_ alignment here for generality */
> #define DLINFO_ITEMS 15
>
> /* ... */
>
> nr = 0;
> csp -= 2 * sizeof(unsigned long);
> NEW_AUX_ENT(AT_EXECFD, ...);
> }
>
> /* ... */
>
> csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
> NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> #ifdef ELF_HWCAP2
> NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> #endif
> /* 14 more NEW_AUX_ENT() */
>
>
> Looks like commit 2171364d1a92 ("powerpc: Add HWCAP2 aux entry") added
> HWCAP2 without ensuring that space is reserved.
>
> I can try to draft a patch to handle the auxv in a more sane way for
> FDPIC, but either way I don't see that it should be relevant to arm64.
>
>
> AT_IGNORE feels like a bit of a fig leaf, but it's harmless enough. I'm
> happy to add it if you prefer.
The only userspace code I could find that uses it is something that prints
out auxv, but I'd still better spitting it out so we don't have to worry
about being smaller than AT_VECTOR_SIZE_ARCH.
Thanks,
Will
^ permalink raw reply
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Ray Jui @ 2018-05-31 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJiuCcek9KU6QWsAAxVCLUaf1v97uR6FcLOfY=A1LGCMTmjHjg@mail.gmail.com>
On 5/31/2018 1:22 AM, Cl?ment P?ron wrote:
> Hi Rai,
>
> On Wed, 30 May 2018 at 19:25, Ray Jui <ray.jui@broadcom.com> wrote:
>>
>> Hi Cl?ment,
>>
>> Correct me if I'm wrong, but I thought the trend is to move to use
>> earlycon that can be activated from kernel command line for early print
>> before the serial driver is loaded.
>>
>> Have you tried earlcon?
> No, only tested this method.
>
> Thanks,
> Clement
>
If I remember it correctly, I think the trend is to use earlycon. There
are obvious shortcomings by making this configuration compile time based.
>>
>> Thanks,
>>
>> Ray
>>
>> On 5/30/2018 6:19 AM, Cl?ment P?ron wrote:
>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>
>>> Broadcom Iproc SoCs typically use the UART3 for
>>> debug/console, provide a known good location for that.
>>>
>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>>> ---
>>>
>>> arch/arm/Kconfig.debug | 12 +++++++++++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>>> index 199ebc1c4538..4ea9d5793b91 100644
>>> --- a/arch/arm/Kconfig.debug
>>> +++ b/arch/arm/Kconfig.debug
>>> @@ -207,6 +207,14 @@ choice
>>> depends on ARCH_BCM_HR2
>>> select DEBUG_UART_8250
>>>
>>> + config DEBUG_BCM_IPROC_UART3
>>> + bool "Kernel low-level debugging on BCM IPROC UART3"
>>> + depends on ARCH_BCM_CYGNUS
>>> + select DEBUG_UART_8250
>>> + help
>>> + Say Y here if you want the debug print routines to direct
>>> + their output to the third serial port on these devices.
>>> +
>>> config DEBUG_BCM_KONA_UART
>>> bool "Kernel low-level debugging messages via BCM KONA UART"
>>> depends on ARCH_BCM_MOBILE
>>> @@ -1557,6 +1565,7 @@ config DEBUG_UART_PHYS
>>> default 0x18000400 if DEBUG_BCM_HR2
>>> default 0x18010000 if DEBUG_SIRFATLAS7_UART0
>>> default 0x18020000 if DEBUG_SIRFATLAS7_UART1
>>> + default 0x18023000 if DEBUG_BCM_IPROC_UART3
>>> default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1
>>> default 0x20001000 if DEBUG_HIP01_UART
>>> default 0x20060000 if DEBUG_RK29_UART0
>>> @@ -1676,6 +1685,7 @@ config DEBUG_UART_VIRT
>>> default 0xf1002000 if DEBUG_MT8127_UART0
>>> default 0xf1006000 if DEBUG_MT6589_UART0
>>> default 0xf1009000 if DEBUG_MT8135_UART3
>>> + default 0xf1023000 if DEBUG_BCM_IPROC_UART3
>>> default 0xf11f1000 if DEBUG_VERSATILE
>>> default 0xf1600000 if DEBUG_INTEGRATOR
>>> default 0xf1c28000 if DEBUG_SUNXI_UART0
>>> @@ -1791,7 +1801,7 @@ config DEBUG_UART_8250_WORD
>>> DEBUG_KEYSTONE_UART0 || DEBUG_KEYSTONE_UART1 || \
>>> DEBUG_ALPINE_UART0 || \
>>> DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
>>> - DEBUG_DAVINCI_DA8XX_UART2 || \
>>> + DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_BCM_IPROC_UART3 || \
>>> DEBUG_BCM_KONA_UART || DEBUG_RK32_UART2
>>>
>>> config DEBUG_UART_8250_PALMCHIP
>>>
^ permalink raw reply
* [PATCHv2 0/4] arm64: SMCCC conduit cleanup
From: Mark Rutland @ 2018-05-31 17:32 UTC (permalink / raw)
To: linux-arm-kernel
Currently, the cpu errata code goes digging into PSCI internals to
discover the SMCCC conduit, using the (arguably misnamed) PSCI_CONDUIT_*
definitions. This lack of abstraction is somewhat unfortunate.
Further, the SDEI code has an almost identical set of CONDUIT_*
definitions, and the duplication is rather unfortunate.
Let's unify things behind a common set of SMCCC_CONDUIT_* definitions,
and expose the SMCCCv1.1 conduit via a new helper that hides the PSCI
driver internals.
Since v1 [1]:
* Rebase to the arm64 for-next/core branch, atop of SSBD patches
* Fold in acks
Mark.
[1] https://lkml.kernel.org/r/20180503170330.5591-1-mark.rutland at arm.com
Mark Rutland (4):
arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
arm64: errata: use arm_smccc_get_conduit()
firmware/psci: use common SMCCC_CONDUIT_*
firmware: arm_sdei: use common SMCCC_CONDUIT_*
arch/arm64/kernel/cpu_errata.c | 34 ++++++++++++----------------------
arch/arm64/kernel/sdei.c | 3 ++-
drivers/firmware/arm_sdei.c | 12 ++++++------
drivers/firmware/psci.c | 24 ++++++++++++++++--------
include/linux/arm-smccc.h | 16 ++++++++++++++++
include/linux/arm_sdei.h | 6 ------
include/linux/psci.h | 9 ++-------
7 files changed, 54 insertions(+), 50 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCHv2 1/4] arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
From: Mark Rutland @ 2018-05-31 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531173223.9668-1-mark.rutland@arm.com>
SMCCC callers are currently amassing a collection of enums for the SMCCC
conduit, and are having to dig into the PSCI driver's internals in order
to figure out what to do.
Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's
internal state.
We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
over to the new interface.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
drivers/firmware/psci.c | 15 +++++++++++++++
include/linux/arm-smccc.h | 16 ++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d03274..d855c20de663 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -64,6 +64,21 @@ struct psci_operations psci_ops = {
.smccc_version = SMCCC_VERSION_1_0,
};
+enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
+{
+ if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
+ return SMCCC_CONDUIT_NONE;
+
+ switch (psci_ops.conduit) {
+ case PSCI_CONDUIT_SMC:
+ return SMCCC_CONDUIT_SMC;
+ case PSCI_CONDUIT_HVC:
+ return SMCCC_CONDUIT_HVC;
+ default:
+ return SMCCC_CONDUIT_NONE;
+ }
+}
+
typedef unsigned long (psci_fn)(unsigned long, unsigned long,
unsigned long, unsigned long);
static psci_fn *invoke_psci_fn;
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index ca1d2cc2cdfa..947f60f5e71e 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -89,6 +89,22 @@
#include <linux/linkage.h>
#include <linux/types.h>
+
+enum arm_smccc_conduit {
+ SMCCC_CONDUIT_NONE,
+ SMCCC_CONDUIT_SMC,
+ SMCCC_CONDUIT_HVC,
+};
+
+/**
+ * arm_smccc_1_1_get_conduit()
+ *
+ * Returns the conduit to be used for SMCCCv1.1 or later.
+ *
+ * When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE.
+ */
+enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void);
+
/**
* struct arm_smccc_res - Result from SMC/HVC call
* @a0-a3 result values from registers 0 to 3
--
2.11.0
^ permalink raw reply related
* [PATCHv2 2/4] arm64: errata: use arm_smccc_get_conduit()
From: Mark Rutland @ 2018-05-31 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531173223.9668-1-mark.rutland@arm.com>
Now that we have arm_smccc_get_conduit(), we can hide the PSCI
implementation details from the arm64 cpu errata code, so let's do so.
As arm_smccc_get_conduit() implicitly checks that the SMCCC version is
at least SMCCC_VERSION_1_1, we no longer need to check this explicitly
where switch statements have a default case.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/kernel/cpu_errata.c | 34 ++++++++++++----------------------
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index cf37ca6fa5f2..0d744b47fd63 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -156,9 +156,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
__install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
}
-#include <uapi/linux/psci.h>
#include <linux/arm-smccc.h>
-#include <linux/psci.h>
static void call_smc_arch_workaround_1(void)
{
@@ -193,11 +191,8 @@ enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
if (!entry->matches(entry, SCOPE_LOCAL_CPU))
return;
- if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
- return;
-
- switch (psci_ops.conduit) {
- case PSCI_CONDUIT_HVC:
+ switch (arm_smccc_1_1_get_conduit()) {
+ case SMCCC_CONDUIT_HVC:
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_1, &res);
if ((int)res.a0 < 0)
@@ -208,7 +203,7 @@ enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
smccc_end = NULL;
break;
- case PSCI_CONDUIT_SMC:
+ case SMCCC_CONDUIT_SMC:
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_1, &res);
if ((int)res.a0 < 0)
@@ -275,11 +270,11 @@ void __init arm64_update_smccc_conduit(struct alt_instr *alt,
BUG_ON(nr_inst != 1);
- switch (psci_ops.conduit) {
- case PSCI_CONDUIT_HVC:
+ switch (arm_smccc_1_1_get_conduit()) {
+ case SMCCC_CONDUIT_HVC:
insn = aarch64_insn_get_hvc_value();
break;
- case PSCI_CONDUIT_SMC:
+ case SMCCC_CONDUIT_SMC:
insn = aarch64_insn_get_smc_value();
break;
default:
@@ -305,12 +300,12 @@ void __init arm64_enable_wa2_handling(struct alt_instr *alt,
void arm64_set_ssbd_mitigation(bool state)
{
- switch (psci_ops.conduit) {
- case PSCI_CONDUIT_HVC:
+ switch (arm_smccc_1_1_get_conduit()) {
+ case SMCCC_CONDUIT_HVC:
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_2, state, NULL);
break;
- case PSCI_CONDUIT_SMC:
+ case SMCCC_CONDUIT_SMC:
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2, state, NULL);
break;
@@ -329,18 +324,13 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
- if (psci_ops.smccc_version == SMCCC_VERSION_1_0) {
- ssbd_state = ARM64_SSBD_UNKNOWN;
- return false;
- }
-
- switch (psci_ops.conduit) {
- case PSCI_CONDUIT_HVC:
+ switch (arm_smccc_1_1_get_conduit()) {
+ case SMCCC_CONDUIT_HVC:
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_2, &res);
break;
- case PSCI_CONDUIT_SMC:
+ case SMCCC_CONDUIT_SMC:
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_2, &res);
break;
--
2.11.0
^ permalink raw reply related
* [PATCHv2 3/4] firmware/psci: use common SMCCC_CONDUIT_*
From: Mark Rutland @ 2018-05-31 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531173223.9668-1-mark.rutland@arm.com>
Now that we have common SMCCC_CONDUIT_* definitions, migrate the PSCI
code over to them, and kill off the old PSCI_CONDUIT_* definitions.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
---
drivers/firmware/psci.c | 25 +++++++++----------------
include/linux/psci.h | 9 ++-------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index d855c20de663..6d7d3ccc3a39 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -60,7 +60,7 @@ bool psci_tos_resident_on(int cpu)
}
struct psci_operations psci_ops = {
- .conduit = PSCI_CONDUIT_NONE,
+ .conduit = SMCCC_CONDUIT_NONE,
.smccc_version = SMCCC_VERSION_1_0,
};
@@ -69,14 +69,7 @@ enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
return SMCCC_CONDUIT_NONE;
- switch (psci_ops.conduit) {
- case PSCI_CONDUIT_SMC:
- return SMCCC_CONDUIT_SMC;
- case PSCI_CONDUIT_HVC:
- return SMCCC_CONDUIT_HVC;
- default:
- return SMCCC_CONDUIT_NONE;
- }
+ return psci_ops.conduit;
}
typedef unsigned long (psci_fn)(unsigned long, unsigned long,
@@ -228,13 +221,13 @@ static unsigned long psci_migrate_info_up_cpu(void)
0, 0, 0);
}
-static void set_conduit(enum psci_conduit conduit)
+static void set_conduit(enum arm_smccc_conduit conduit)
{
switch (conduit) {
- case PSCI_CONDUIT_HVC:
+ case SMCCC_CONDUIT_HVC:
invoke_psci_fn = __invoke_psci_fn_hvc;
break;
- case PSCI_CONDUIT_SMC:
+ case SMCCC_CONDUIT_SMC:
invoke_psci_fn = __invoke_psci_fn_smc;
break;
default:
@@ -256,9 +249,9 @@ static int get_set_conduit_method(struct device_node *np)
}
if (!strcmp("hvc", method)) {
- set_conduit(PSCI_CONDUIT_HVC);
+ set_conduit(SMCCC_CONDUIT_HVC);
} else if (!strcmp("smc", method)) {
- set_conduit(PSCI_CONDUIT_SMC);
+ set_conduit(SMCCC_CONDUIT_SMC);
} else {
pr_warn("invalid \"method\" property: %s\n", method);
return -EINVAL;
@@ -714,9 +707,9 @@ int __init psci_acpi_init(void)
pr_info("probing for conduit method from ACPI.\n");
if (acpi_psci_use_hvc())
- set_conduit(PSCI_CONDUIT_HVC);
+ set_conduit(SMCCC_CONDUIT_HVC);
else
- set_conduit(PSCI_CONDUIT_SMC);
+ set_conduit(SMCCC_CONDUIT_SMC);
return psci_probe();
}
diff --git a/include/linux/psci.h b/include/linux/psci.h
index 8b1b3b5935ab..affcd2128df8 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -14,6 +14,7 @@
#ifndef __LINUX_PSCI_H
#define __LINUX_PSCI_H
+#include <linux/arm-smccc.h>
#include <linux/init.h>
#include <linux/types.h>
@@ -25,12 +26,6 @@ bool psci_tos_resident_on(int cpu);
int psci_cpu_init_idle(unsigned int cpu);
int psci_cpu_suspend_enter(unsigned long index);
-enum psci_conduit {
- PSCI_CONDUIT_NONE,
- PSCI_CONDUIT_SMC,
- PSCI_CONDUIT_HVC,
-};
-
enum smccc_version {
SMCCC_VERSION_1_0,
SMCCC_VERSION_1_1,
@@ -45,7 +40,7 @@ struct psci_operations {
int (*affinity_info)(unsigned long target_affinity,
unsigned long lowest_affinity_level);
int (*migrate_info_type)(void);
- enum psci_conduit conduit;
+ enum arm_smccc_conduit conduit;
enum smccc_version smccc_version;
};
--
2.11.0
^ permalink raw reply related
* [PATCHv2 4/4] firmware: arm_sdei: use common SMCCC_CONDUIT_*
From: Mark Rutland @ 2018-05-31 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531173223.9668-1-mark.rutland@arm.com>
Now that we have common definitions for SMCCC conduits, move the SDEI
code over to them, and remove the SDEI-specific definitions.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: James Morse <james.morse@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/sdei.c | 3 ++-
drivers/firmware/arm_sdei.c | 12 ++++++------
include/linux/arm_sdei.h | 6 ------
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/sdei.c b/arch/arm64/kernel/sdei.c
index 6b8d90d5ceae..a3be67ae8a88 100644
--- a/arch/arm64/kernel/sdei.c
+++ b/arch/arm64/kernel/sdei.c
@@ -2,6 +2,7 @@
// Copyright (C) 2017 Arm Ltd.
#define pr_fmt(fmt) "sdei: " fmt
+#include <linux/arm-smccc.h>
#include <linux/arm_sdei.h>
#include <linux/hardirq.h>
#include <linux/irqflags.h>
@@ -125,7 +126,7 @@ unsigned long sdei_arch_get_entry_point(int conduit)
return 0;
}
- sdei_exit_mode = (conduit == CONDUIT_HVC) ? SDEI_EXIT_HVC : SDEI_EXIT_SMC;
+ sdei_exit_mode = (conduit == SMCCC_CONDUIT_HVC) ? SDEI_EXIT_HVC : SDEI_EXIT_SMC;
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
if (arm64_kernel_unmapped_at_el0()) {
diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
index 1ea71640fdc2..1357dbd7c7fc 100644
--- a/drivers/firmware/arm_sdei.c
+++ b/drivers/firmware/arm_sdei.c
@@ -896,29 +896,29 @@ static int sdei_get_conduit(struct platform_device *pdev)
if (np) {
if (of_property_read_string(np, "method", &method)) {
pr_warn("missing \"method\" property\n");
- return CONDUIT_INVALID;
+ return SMCCC_CONDUIT_NONE;
}
if (!strcmp("hvc", method)) {
sdei_firmware_call = &sdei_smccc_hvc;
- return CONDUIT_HVC;
+ return SMCCC_CONDUIT_HVC;
} else if (!strcmp("smc", method)) {
sdei_firmware_call = &sdei_smccc_smc;
- return CONDUIT_SMC;
+ return SMCCC_CONDUIT_SMC;
}
pr_warn("invalid \"method\" property: %s\n", method);
} else if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled) {
if (acpi_psci_use_hvc()) {
sdei_firmware_call = &sdei_smccc_hvc;
- return CONDUIT_HVC;
+ return SMCCC_CONDUIT_HVC;
} else {
sdei_firmware_call = &sdei_smccc_smc;
- return CONDUIT_SMC;
+ return SMCCC_CONDUIT_SMC;
}
}
- return CONDUIT_INVALID;
+ return SMCCC_CONDUIT_NONE;
}
static int sdei_probe(struct platform_device *pdev)
diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
index 942afbd544b7..21e337d99fa6 100644
--- a/include/linux/arm_sdei.h
+++ b/include/linux/arm_sdei.h
@@ -5,12 +5,6 @@
#include <uapi/linux/arm_sdei.h>
-enum sdei_conduit_types {
- CONDUIT_INVALID = 0,
- CONDUIT_SMC,
- CONDUIT_HVC,
-};
-
#include <asm/sdei.h>
/* Arch code should override this to set the entry point from firmware... */
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Rohit Khanna @ 2018-05-31 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530090044.GA2452@arm.com>
Will, thanks for the comments.
I will push a new patch set.
We want to avoid using __flush_icache_all as much as possible and hence trying to flush cache by range.
Thanks
Rohit
________________________________________
From: Will Deacon <will.deacon@arm.com>
Sent: Wednesday, May 30, 2018 2:00 AM
To: Rohit Khanna
Cc: catalin.marinas at arm.com; robin.murphy at arm.com; mark.rutland at arm.com; Suzuki.Poulose at arm.com; Bo Yan; Alexander Van Brunt; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH] arm64: alternative:flush cache with unpatched code
Hi Rohit,
Please keep me on cc for future versions of this patch. Comments inline.
On Tue, May 29, 2018 at 11:11:28AM -0700, Rohit Khanna wrote:
> In the current implementation, __apply_alternatives patches
> flush_icache_range and then executes it without invalidating the icache.
> Thus, icache can contain some of the old instructions for
> flush_icache_range. This can cause unpredictable behavior as during
> execution we can get a mix of old and new instructions for
> flush_icache_range.
>
> This patch :
> 1. Adds a new function flush_cache_kernel_range for flushing kernel
> memory range. This function uses non hot-patched code and can be
> safely used to flush cache during code patching.
>
> 2. Modifies __apply_alternatives so that it uses
> flush_cache_kernel_range to flush the cache range after patching code.
>
> Signed-off-by: Rohit Khanna <rokhanna@nvidia.com>
> ---
> arch/arm64/kernel/alternative.c | 31 +++++++++++++++++++++++++++++--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> index 5c4bce4ac381..e93cfd26a314 100644
> --- a/arch/arm64/kernel/alternative.c
> +++ b/arch/arm64/kernel/alternative.c
> @@ -122,6 +122,33 @@ static void patch_alternative(struct alt_instr *alt,
> }
> }
>
> +/* This is used for flushing kernel memory range after
> + * __apply_alternatives has patched kernel code
> + */
> +static void flush_cache_kernel_range(void *start, void *end)
> +{
How about something like clean_dcache_range_nopatch instead?
> + u64 d_start, i_start, d_size, i_size;
> +
> + /* use sanitized value of ctr_el0 rather than raw value from CPU */
> + d_size = 4 << ((arm64_ftr_reg_ctrel0.sys_val >> 0x10) & 0xF); /* bytes */
> + i_size = 4 << (arm64_ftr_reg_ctrel0.sys_val & 0xF); /* bytes */
You should be able to use read_sanitised_ftr_reg() and
cpuid_feature_extract_unsigned_field() here.
> + d_start = (u64)start & ~(d_size - 1);
> + while (d_start <= (u64)end) {
Please add a comment about the A53 erratum this is handling by using
clean+inv.
> + asm volatile("dc civac, %0" : : "r" (d_start));
> + d_start += d_size;
> + }
> + dsb(ish);
> +
> + i_start = (u64)start & ~(i_size - 1);
> + while (i_start <= (u64)end) {
> + asm volatile("ic ivau, %0" : : "r" (i_start));
> + i_start += i_size;
> + }
> + dsb(ish);
> + isb();
As I mentioned before, I think it would be simpler just to avoid doing the
I-cache invalidation by range and instead call __flush_icache_all once we've
exiting the loop in __apply_alternatives.
Will
^ permalink raw reply
* [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
From: Robin Murphy @ 2018-05-31 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530140625.21247-2-thierry.reding@gmail.com>
On 30/05/18 15:06, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Instead of setting the DMA ops pointer to NULL, set the correct,
> non-IOMMU ops depending on the device's coherency setting.
It looks like it's probably been 4 or 5 years since that became subtly
wrong by virtue of the landscape changing around it, but it's clearly
not enough of a problem to consider stable backports :)
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v4:
> - new patch to fix existing arm_iommu_detach_device() to do what we need
>
> arch/arm/mm/dma-mapping.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index af27f1c22d93..87a0037574e4 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask)
> return __dma_supported(dev, mask, false);
> }
>
> +static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> +{
> + return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
> +}
> +
> #ifdef CONFIG_ARM_DMA_USE_IOMMU
>
> static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
> @@ -2296,7 +2301,7 @@ void arm_iommu_detach_device(struct device *dev)
> iommu_detach_device(mapping->domain, dev);
> kref_put(&mapping->kref, release_iommu_mapping);
> to_dma_iommu_mapping(dev) = NULL;
> - set_dma_ops(dev, NULL);
> + set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent));
>
> pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
> }
> @@ -2357,11 +2362,6 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { }
>
> #endif /* CONFIG_ARM_DMA_USE_IOMMU */
>
> -static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
> -{
> - return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
> -}
> -
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
>
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Jernej Škrabec @ 2018-05-31 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531092133.3gqepoabvuruiztz@flea.home>
Dne ?etrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > >> > > + if (tcon->quirks->needs_tcon_top) {
> > >> > > + struct device_node *np;
> > >> > > +
> > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
> > >> > > 0);
> > >> > > + if (np) {
> > >> > > + struct platform_device *pdev;
> > >> > > +
> > >> > > + pdev = of_find_device_by_node(np);
> > >> > > + if (pdev)
> > >> > > + tcon->tcon_top =
> > >> > > platform_get_drvdata(pdev);
> > >> > > + of_node_put(np);
> > >> > > +
> > >> > > + if (!tcon->tcon_top)
> > >> > > + return -EPROBE_DEFER;
> > >> > > + }
> > >> > > + }
> > >> > > +
> > >> >
> > >> > I might have missed it, but I've not seen the bindings additions for
> > >> > that property. This shouldn't really be done that way anyway, instead
> > >> > of using a direct phandle, you should be using the of-graph, with the
> > >> > TCON-top sitting where it belongs in the flow of data.
> > >>
> > >> Just to answer to the first question, it did describe it in "[PATCH
> > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> > >>
> > >> As why I designed it that way - HW representation could be described
> > >> that way> >>
> > >> (ASCII art makes sense when fixed width font is used to view it):
> > >> / LCD0/LVDS0
> > >>
> > >> / TCON-LCD0
> > >>
> > >> | \ MIPI DSI
> > >>
> > >> mixer0 |
> > >>
> > >> \ / TCON-LCD1 - LCD1/LVDS1
> > >>
> > >> TCON-TOP
> > >>
> > >> / \ TCON-TV0 - TVE0/RGB
> > >>
> > >> mixer1 | \
> > >>
> > >> | TCON-TOP - HDMI
> > >> |
> > >> | /
> > >>
> > >> \ TCON-TV1 - TVE1/RGB
> > >>
> > >> This is a bit simplified, since there is also TVE-TOP, which is
> > >> responsible
> > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
> > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
> > >> seems that you can arbitrarly choose which DAC is responsible for
> > >> which signal, so there is a ton of possible end combinations, but I'm
> > >> not 100% sure.
> > >>
> > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
> > >> suggest more possibilities, although some of them seem wrong, like RGB
> > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
> > >> code.
> > >>
> > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
> > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
> > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
> > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
> > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
> > >> (when it works in RGB mode) and LCD. But that is just my guess since
> > >> I'm not really familiar with RGB and LCD interfaces.
> > >>
> > >> I'm really not sure what would be the best representation in OF-graph.
> > >> Can you suggest one?
> > >
> > > Rob might disagree on this one, but I don't see anything wrong with
> > > having loops in the graph. If the TCON-TOP can be both the input and
> > > output of the TCONs, then so be it, and have it described that way in
> > > the graph.
> > >
> > > The code is already able to filter out nodes that have already been
> > > added to the list of devices we need to wait for in the component
> > > framework, so that should work as well.
> > >
> > > And we'd need to describe TVE-TOP as well, even though we don't have a
> > > driver for it yet. That will simplify the backward compatibility later
> > > on.
> >
> > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
> > binds everything together, and provides signal routing, kind of like
> > DE-TOP on A64. So the signal mux controls that were originally found
> > in TCON0 and TVE0 were moved out.
> >
> > The driver needs to know about that, but the graph about doesn't make
> > much sense directly. Without looking at the manual, I understand it to
> > likely be one mux between the mixers and TCONs, and one between the
> > TCON-TVs and HDMI. Would it make more sense to just have the graph
> > connections between the muxed components, and remove TCON-TOP from
> > it, like we had in the past? A phandle could be used to reference
> > the TCON-TOP for mux controls, in addition to the clocks and resets.
> >
> > For TVE, we would need something to represent each of the output pins,
> > so the device tree can actually describe what kind of signal, be it
> > each component of RGB/YUV or composite video, is wanted on each pin,
> > if any. This is also needed on the A20 for the Cubietruck, so we can
> > describe which pins are tied to the VGA connector, and which one does
> > R, G, or B.
>
> I guess we'll see how the DT maintainers feel about this, but my
> impression is that the OF graph should model the flow of data between
> the devices. If there's a mux somewhere, then the data is definitely
> going through it, and as such it should be part of the graph.
I concur, but I spent few days thinking how to represent this sanely in graph,
but I didn't find any good solution. I'll represent here my idea and please
tell your opinion before I start implementing it.
First, let me be clear that mixer0 and mixer1 don't have same capabilities
(different number of planes, mixer0 supports writeback, mixer1 does not,
etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
obviously depends on end system.
So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
According to current practice in sun4i-drm driver, graph has to have port 0,
representing input and port 1, representing output. This would mean that graph
looks something like that:
tcon_top: tcon-top at 1c70000 {
compatible = "allwinner,sun8i-r40-tcon-top";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_top_in: port at 0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
tcon_top_in_mixer0: endpoint at 0 {
reg = <0>;
remote-endpoint = <&mixer0_out_tcon_top>;
};
tcon_top_in_mixer1: endpoint at 1 {
reg = <1>;
remote-endpoint = <&mixer1_out_tcon_top>;
};
tcon_top_in_tcon_tv: endpoint at 2 {
reg = <2>;
// here is HDMI input connection, part of board DTS
remote-endpoint = <board specific phandle to TV TCON output>;
};
};
tcon_top_out: port at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
tcon_top_out_tcon0: endpoint at 0 {
reg = <0>;
// here is mixer0 output connection, part of board DTS
remote-endpoint = <board specific phandle to TCON>;
};
tcon_top_out_tcon1: endpoint at 1 {
reg = <1>;
// here is mixer1 output connection, part of board DTS
remote-endpoint = <board specific phandle to TCON>;
};
tcon_top_out_hdmi: endpoint at 2 {
reg = <2>;
remote-endpoint = <&hdmi_in_tcon_top>;
};
};
};
};
tcon_tv0: lcd-controller at 1c73000 {
compatible = "allwinner,sun8i-r40-tcon-tv-0";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_tv0_in: port at 0 {
reg = <0>;
tcon_tv0_in_tcon_top: endpoint {
// endpoint depends on board, part of board DTS
remote-endpoint = <phandle to one of tcon_top_out_tcon>;
};
};
tcon_tv0_out: port at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// endpoints to TV TOP and TCON TOP HDMI input
...
};
};
};
tcon_tv1: lcd-controller at 1c74000 {
compatible = "allwinner,sun8i-r40-tcon-tv-1";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon_tv1_in: port at 0 {
reg = <0>;
tcon_tv1_in_tcon_top: endpoint {
// endpoint depends on board, part of board DTS
remote-endpoint = <phandle to one of tcon_top_out_tcon>;
};
};
tcon_tv1_out: port at 1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
// endpoints to TV TOP and TCON TOP HDMI input
...
};
};
};
tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
outputs would be LCD or LVDS panels or MIPI DSI encoder.
Please note that each TCON (there are 4 of them) would need to have unique
compatible and have HW index stored in quirks data. It would be used by TCON
TOP driver for configuring muxes.
What do you think about above suggestion?
Best regards,
Jernej
^ permalink raw reply
* [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Robin Murphy @ 2018-05-31 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530140625.21247-3-thierry.reding@gmail.com>
On 30/05/18 15:06, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Depending on the kernel configuration, early ARM architecture setup code
> may have attached the GPU to a DMA/IOMMU mapping that transparently uses
> the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
> backed buffers (a special bit in the GPU's MMU page tables indicates the
> memory path to take: via the SMMU or directly to the memory controller).
> Transparently backing DMA memory with an IOMMU prevents Nouveau from
> properly handling such memory accesses and causes memory access faults.
>
> As a side-note: buffers other than those allocated in instance memory
> don't need to be physically contiguous from the GPU's perspective since
> the GPU can map them into contiguous buffers using its own MMU. Mapping
> these buffers through the IOMMU is unnecessary and will even lead to
> performance degradation because of the additional translation. One
> exception to this are compressible buffers which need large pages. In
> order to enable these large pages, multiple small pages will have to be
> combined into one large (I/O virtually contiguous) mapping via the
> IOMMU. However, that is a topic outside the scope of this fix and isn't
> currently supported. An implementation will want to explicitly create
> these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
> mapping would still be required.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v4:
> - use existing APIs to detach from a DMA/IOMMU mapping
>
> Changes in v3:
> - clarify the use of IOMMU mapping for compressible buffers
> - squash multiple patches into this
>
> drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> index 78597da6313a..0e372a190d3f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> @@ -23,6 +23,10 @@
> #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
> #include "priv.h"
>
> +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> +#include <asm/dma-iommu.h>
> +#endif
> +
> static int
> nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
> {
> @@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra *tdev)
> unsigned long pgsize_bitmap;
> int ret;
>
> +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> + if (dev->archdata.mapping) {
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
Nit: there's arguably little point using the helper here after you've
already shattered the illusion by poking dev->archdata.mapping directly,
but I guess this disappears again anyway once the refcounting gets
sorted out and the mapping releases itself properly, so:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> +
> + arm_iommu_detach_device(dev);
> + arm_iommu_release_mapping(mapping);
> + }
> +#endif
> +
> if (!tdev->func->iommu_bit)
> return;
>
>
^ permalink raw reply
* [PATCH 0/3] Initial Spectre variant 1 patches
From: Tony Lindgren @ 2018-05-31 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [180531 13:34]:
> Hi,
>
> This series adds initial support for the Spectre variant 1 workarounds
> to the kernel. This does _not_ cover the user accessors, which are
> still in development.
>
> The series adds support for the array_index_mask_nospec() macro, used
> by generic kernel code to mask out of bounds pointers, and also adds
> the syscall table hardening.
For the series including v2 patch of 3/3:
Boot-tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980/Condor I2C support
From: Sergei Shtylyov @ 2018-05-31 20:18 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180529-v4.17-rc7' tag. We're adding the R8A77980 I2C nodes
and then describing 2 PCA9654 I/O expanders connected to the I2C0 bus on
the Condor board.
[1/2] arm64: dts: renesas: r8a77980: add I2C support
[2/2] arm64: dts: renesas: condor: add I2C0 support
WBR, Sergei
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-31 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
Define the generic R8A77980 parts of the I2C[0-5] device nodes.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- removed the DMA props for I2C3/4;
- fixed a typo in the patch description;
- added Geert's tag.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 105 ++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -16,6 +16,15 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -135,6 +144,102 @@
#power-domain-cells = <1>;
};
+ i2c0: i2c at e6500000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6500000 0 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 931>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at e6508000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 930>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 930>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at e6510000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe6510000 0 0x40>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 929>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 929>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at e66d0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d0000 0 0x40>;
+ interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 928>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 928>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at e66d8000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 927>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 927>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at e66e0000 {
+ compatible = "renesas,i2c-r8a77980",
+ "renesas,rcar-gen3-i2c";
+ reg = <0 0xe66e0000 0 0x40>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 919>;
+ dmas = <&dmac1 0x9b>, <&dmac1 0x9a>,
+ <&dmac2 0x9b>, <&dmac2 0x9a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
hscif0: serial at e6540000 {
compatible = "renesas,hscif-r8a77980",
"renesas,rcar-gen3-hscif",
^ 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