* [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Krzysztof Kozlowski @ 2016-11-03 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-11-jh80.chung@samsung.com>
On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So Use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
> arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
> arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
> arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
This looks totally independent to rest of patches so it can be applied
separately without any functional impact (except lack of minimum
frequency). Is that correct?
Best regards,
Krzysztof
^ permalink raw reply
* arm64 build failure with CONFIG_ARM64_LSE_ATOMICS=y
From: Catalin Marinas @ 2016-11-03 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103111238.GC24243@shodan.usersys.redhat.com>
On Thu, Nov 03, 2016 at 12:12:38PM +0100, Artem Savkov wrote:
> On Thu, Nov 03, 2016 at 10:39:43AM +0000, Suzuki K Poulose wrote:
> > On 02/11/16 23:28, Will Deacon wrote:
> > > On Wed, Nov 02, 2016 at 05:44:27PM +0100, Artem Savkov wrote:
> > > > Looks like your patch "efd9e03 arm64: Use static keys for CPU features"
> > > > breaks arm64 build with "CONFIG_ARM64_LSE_ATOMICS=y" because it creates a
> > > > circular dependency for asm/lse.h through jump_label.h:
[...]
> Apparently it fails with an older gcc (4.8.5), but doesn't with 6.2.0.
> The different bit is that with 4.8.5 I don't have CC_HAVE_ASM_GOTO set.
> It is reproducible with 6.2.0 if you manually remove CC_HAVE_ASM_GOTO.
-----------8<----------------
>From e27eb40cd5af38f1a5e64553a367220f00a1b5d8 Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 3 Nov 2016 18:34:34 +0000
Subject: [PATCH] arm64: Fix circular include of asm/lse.h through
linux/jump_label.h
Commit efd9e03facd0 ("arm64: Use static keys for CPU features")
introduced support for static keys in asm/cpufeature.h, including
linux/jump_label.h. When CC_HAVE_ASM_GOTO is not defined, this causes a
circular dependency via linux/atomic.h, asm/lse.h and asm/cpufeature.h.
This patch moves the capability macros out out of asm/cpufeature.h into
a separate asm/cpucaps.h and modifies some of the #includes accordingly.
Fixes: efd9e03facd0 ("arm64: Use static keys for CPU features")
Reported-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/alternative.h | 2 +-
arch/arm64/include/asm/cpucaps.h | 40 ++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/cpufeature.h | 20 +-----------------
arch/arm64/include/asm/lse.h | 1 -
4 files changed, 42 insertions(+), 21 deletions(-)
create mode 100644 arch/arm64/include/asm/cpucaps.h
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 39feb85a6931..6e1cb8c5af4d 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -1,7 +1,7 @@
#ifndef __ASM_ALTERNATIVE_H
#define __ASM_ALTERNATIVE_H
-#include <asm/cpufeature.h>
+#include <asm/cpucaps.h>
#include <asm/insn.h>
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
new file mode 100644
index 000000000000..87b446535185
--- /dev/null
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -0,0 +1,40 @@
+/*
+ * arch/arm64/include/asm/cpucaps.h
+ *
+ * Copyright (C) 2016 ARM 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 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ASM_CPUCAPS_H
+#define __ASM_CPUCAPS_H
+
+#define ARM64_WORKAROUND_CLEAN_CACHE 0
+#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1
+#define ARM64_WORKAROUND_845719 2
+#define ARM64_HAS_SYSREG_GIC_CPUIF 3
+#define ARM64_HAS_PAN 4
+#define ARM64_HAS_LSE_ATOMICS 5
+#define ARM64_WORKAROUND_CAVIUM_23154 6
+#define ARM64_WORKAROUND_834220 7
+#define ARM64_HAS_NO_HW_PREFETCH 8
+#define ARM64_HAS_UAO 9
+#define ARM64_ALT_PAN_NOT_UAO 10
+#define ARM64_HAS_VIRT_HOST_EXTN 11
+#define ARM64_WORKAROUND_CAVIUM_27456 12
+#define ARM64_HAS_32BIT_EL0 13
+#define ARM64_HYP_OFFSET_LOW 14
+#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
+
+#define ARM64_NCAPS 16
+
+#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index a27c3245ba21..0bc0b1de90c4 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -11,6 +11,7 @@
#include <linux/jump_label.h>
+#include <asm/cpucaps.h>
#include <asm/hwcap.h>
#include <asm/sysreg.h>
@@ -24,25 +25,6 @@
#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap))
#define cpu_feature(x) ilog2(HWCAP_ ## x)
-#define ARM64_WORKAROUND_CLEAN_CACHE 0
-#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE 1
-#define ARM64_WORKAROUND_845719 2
-#define ARM64_HAS_SYSREG_GIC_CPUIF 3
-#define ARM64_HAS_PAN 4
-#define ARM64_HAS_LSE_ATOMICS 5
-#define ARM64_WORKAROUND_CAVIUM_23154 6
-#define ARM64_WORKAROUND_834220 7
-#define ARM64_HAS_NO_HW_PREFETCH 8
-#define ARM64_HAS_UAO 9
-#define ARM64_ALT_PAN_NOT_UAO 10
-#define ARM64_HAS_VIRT_HOST_EXTN 11
-#define ARM64_WORKAROUND_CAVIUM_27456 12
-#define ARM64_HAS_32BIT_EL0 13
-#define ARM64_HYP_OFFSET_LOW 14
-#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
-
-#define ARM64_NCAPS 16
-
#ifndef __ASSEMBLY__
#include <linux/kernel.h>
diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
index 23acc00be32d..fc756e22c84c 100644
--- a/arch/arm64/include/asm/lse.h
+++ b/arch/arm64/include/asm/lse.h
@@ -5,7 +5,6 @@
#include <linux/stringify.h>
#include <asm/alternative.h>
-#include <asm/cpufeature.h>
#ifdef __ASSEMBLER__
--
Catalin
^ permalink raw reply related
* [PATCH] at91sam9g20.dtsi: set correct USB clock divisors
From: Alexandre Belloni @ 2016-11-03 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503811-32697-1-git-send-email-yurovsky@gmail.com>
On 26/10/2016 at 10:43:31 -0700, Andrey Yurovsky wrote :
> The AT91SAM9G20 has different clock divisors from the otherwise similar
> AT91SAM9260. Set them in at91sam9g20.dtsi so that all AT91SAM9G20 users set up
> the USB host controller clocks correctly.
>
> Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
> ---
> arch/arm/boot/dts/at91sam9g20.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
> index f593016..6c4488c 100644
> --- a/arch/arm/boot/dts/at91sam9g20.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g20.dtsi
> @@ -62,6 +62,10 @@
> atmel,clk-output-range = <0 133000000>;
> atmel,clk-divisors = <1 2 4 6>;
> };
> +
> + usb: usbck {
> + atmel,clk-divisors = <4 2 0 0>;
> + };
Actually, I had a look at the datasheet and it still says the divisors
are 1, 2 and 4. There are existing board using USB and those divisors.
Can someone at Atmel confirm?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 1/5] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
From: Krzysztof Kozlowski @ 2016-11-03 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-2-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 03, 2016 at 03:39:05PM +0900, Chanwoo Choi wrote:
> This patch supports the multiple IORESOURCE_MEM resources for one pin-bank.
> In the pre-existing Exynos series, the registers of the gpio bank are included
> in the one memory map. But, some gpio bank need to support the one more memory
> map (IORESOURCE_MEM) because the registers of gpio bank are separated into
> the different memory map.
>
> For example,
> The both ALIVE and IMEM domain have the different memory base address.
> The GFP[1-5] of exynos5433 are composed as following:
> - ALIVE domain : WEINT_* registers
> - IMEM domain : CON/DAT/PUD/DRV/CONPDN/PUDPDN register
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio at vger.kernel.org
> Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> .../bindings/pinctrl/samsung-pinctrl.txt | 19 ++++++++++
> drivers/pinctrl/samsung/pinctrl-exynos.c | 39 +++++++++------------
> drivers/pinctrl/samsung/pinctrl-exynos.h | 11 ++++++
> drivers/pinctrl/samsung/pinctrl-samsung.c | 40 ++++++++++++++--------
> drivers/pinctrl/samsung/pinctrl-samsung.h | 10 ++++--
> 5 files changed, 80 insertions(+), 39 deletions(-)
>
Hi,
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Krzysztof Kozlowski @ 2016-11-03 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-3-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 03, 2016 at 03:39:06PM +0900, Chanwoo Choi wrote:
> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
> to support the multiple memory map because the registers of GPFx are located
> in the different domain.
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/pinctrl/samsung/pinctrl-exynos.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
I think that, instead of in previous patch, the
"samsung,exynos5433-pinctrl" compatible should be documented here along
with information that it requires two addresses for mappings.
Best regards,
Krzysztof
> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
> index d657b52dfdb5..12f7d1eb65bc 100644
> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
> @@ -1339,6 +1339,11 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
> EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
> EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
> EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
> + EXYNOS_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1),
> + EXYNOS_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1),
> + EXYNOS_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1),
> + EXYNOS_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1),
> + EXYNOS_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1),
> };
>
> /* pin banks of exynos5433 pin-controller - AUD */
> @@ -1420,6 +1425,7 @@ static void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
> .eint_wkup_init = exynos_eint_wkup_init,
> .suspend = exynos_pinctrl_suspend,
> .resume = exynos_pinctrl_resume,
> + .nr_ext_resources = 1,
> }, {
> /* pin-controller instance 1 data */
> .pin_banks = exynos5433_pin_banks1,
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v3 0/2] net: stmmac: Add OXNAS DWMAC Glue
From: David Miller @ 2016-11-03 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102140237.6955-1-narmstrong@baylibre.com>
From: Neil Armstrong <narmstrong@baylibre.com>
Date: Wed, 2 Nov 2016 15:02:35 +0100
> This patchset add support for the Sysnopsys DWMAC Gigabit Ethernet
> controller Glue layer of the Oxford Semiconductor OX820 SoC.
Series applied to net-next, thanks.
^ permalink raw reply
* [PATCH v2] ARM: DTS: r8a7794: alt: Fix PFC names for DU
From: Jacopo Mondi @ 2016-11-03 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478180574-15464-1-git-send-email-jacopo@jmondi.org>
Update the PFC pin groups and function names of DU interface for
r8a7794 ALT board.
The currently specified pin groups and function names prevented PFC and
DU interfaces from being correctly configured:
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
sh-pfc e6060000.pin-controller: function 'du' not supported
sh-pfc e6060000.pin-controller: invalid function du in map table
rcar-du: probe of feb00000.display failed with error -22
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
---
v1->v2:
- s/PCF/PFC/ in commit message according to Sergei Shtylyov's comment
Patch applied against Simon Horman's renesas/master branch.
The PCF pin groups and function renaming was introduced by commit 56ed4bb9 and
DTS for ALT board has never been update accordingly.
Tested displaying frames on VGA interface: the rcar-du driver loads correctly.
arch/arm/boot/dts/r8a7794-alt.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 8d1b35a..9d65fb3 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -165,8 +165,8 @@
pinctrl-names = "default";
du_pins: du {
- groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
- function = "du";
+ groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_clk0_out";
+ function = "du1";
};
scif2_pins: scif2 {
--
2.7.4
^ permalink raw reply related
* [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Jens Wiklander @ 2016-11-03 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <573b8fff-eeb7-3656-6f32-de69d906a966@ti.com>
On Mon, Oct 31, 2016 at 01:24:14PM -0500, Andrew F. Davis wrote:
> On 10/29/2016 04:46 AM, Jens Wiklander wrote:
> > On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
> >> On 10/28/2016 05:19 AM, Jens Wiklander wrote:
> >>> Hi,
> >>>
> >>> This patch set introduces a generic TEE subsystem. The TEE subsystem will
> >>> contain drivers for various TEE implementations. A TEE (Trusted Execution
> >>> Environment) is a trusted OS running in some secure environment, for
> >>> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
> >>>
> >>> Regarding use cases, TrustZone has traditionally been used for
> >>> offloading secure tasks to the secure world. Examples include:
> >>> - Secure key handling where the OS may or may not have direct access to key
> >>> material.
> >>> - E-commerce and payment technologies. Credentials, credit card numbers etc
> >>> could be stored in a more secure environment.
> >>> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
> >>> etc.
> >>> - Secure boot to ensure that loaded binaries haven?t been tampered with.
> >>> It?s not strictly needed for secure boot, but you could enhance security
> >>> by leveraging a TEE during boot.
> >>> - Digital Rights Management (DRM), the studios provides content with
> >>> different resolution depending on the security of the device. Higher
> >>> security means higher resolution.
> >>>
> >>> A TEE could also be used in existing and new technologies. For example IMA
> >>> (Integrity Measurement Architecture) which has been in the kernel for quite
> >>> a while. Today you can enhance security by using a TPM-chip to sign the IMA
> >>> measurement list. This is something that you also could do by leveraging a
> >>> TEE.
> >>>
> >>> Another example could be in 2-factor authentication which is becoming
> >>> increasingly more important. FIDO (https://fidoalliance.org) for example
> >>> are using public key cryptography in their 2-factor authentication standard
> >>> (U2F). With FIDO, a private and public key pair will be generated for every
> >>> site you visit and the private key should never leave the local device.
> >>> This is an example where you could use secure storage in a TEE for the
> >>> private key.
> >>>
> >>> Today you will find a quite a few different out of tree implementations of
> >>> TEE drivers which tends to fragment the TEE ecosystem and development. We
> >>> think it would be a good idea to have a generic TEE driver integrated in
> >>> the kernel which would serve as a base for several different TEE solutions,
> >>> no matter if they are on-chip like TrustZone or if they are on a separate
> >>> crypto co-processor.
> >>>
> >>> To develop this TEE subsystem we have been using the open source TEE called
> >>> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
> >>> first TEE solution supported by this new subsystem. OP-TEE is a
> >>> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
> >>> only GlobalPlatform TEEs, instead we have tried to design it so that it
> >>> should work with other TEE solutions also.
> >>>
> >>
> >> The above is my biggest concern with this whole subsystem, to me it
> >> still feels very OPTEE specific. As much as I would love to believe
> >> OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
> >> use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
> >> to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
> >> and whatever Intel/AMD are cooking up for x86.
> >
> > I'd rather say that it's slightly GlobalPlatform specific, but a bit
> > more flexible.
> >
> >>
> >> As we all know when things are upstreamed we lose the ability to make
> >> radical changes easily, especially to full subsystems. What happens when
> >> this framework, built with only one existing TEE, built by the one
> >> existing TEE's devs, is not as flexible as we need when other TEEs start
> >> rolling out?
> >
> > Initially the TEE subsystem was much more flexible and was criticized
> > for that.
> >
>
> That's rather strange, I haven't been following this from the start so I
> will just take your word that this is where the community wants this
> subsystem to go.
>
> >>
> >> Do we see this as a chicken and egg situation, or is there any harm
> >> beyond the pains of supporting an out-of-tree driver for a while, to
> >> wait until we have at least one other TEE to add to this subsystem
> >> before merging?
> >
> > This proposal is the bare minimum to have something useful. On top of
> > this there's more things we'd like to add, for example an in-kernel API
> > for accessing the TEE and secure buffer handling. The way we're dealing
> > with shared memory need to be improved to better support multiple guests
> > communicating with one TEE.
> >
> > What we can do now with the subsystem now is somewhat limited by the
> > fact that we're trying to upstream it and want to do that it in
> > manageable increments.
> >
>
> Fair enough.
>
> For now this series is being used in our production SDKs so it has at
> least some basic testing from us, so for the whole series:
>
> Tested-by: Andrew F. Davis <afd@ti.com>
Thanks, Andrew. A summary of all tags so far:
When I sent out this patch set I missed including the previous
tested-bys:
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com>
Then there's also the acked-by from Andreas which should have been
included even if the mail now bounces:
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
The DT patch has (since v8):
Acked-by: Rob Herring <robh@kernel.org>
Thanks,
Jens
^ permalink raw reply
* [PATCH v3 3/5] arm64: dts: exynos: Add dts files for Samsung Exynos5433 64bit SoC
From: Krzysztof Kozlowski @ 2016-11-03 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-4-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 03, 2016 at 03:39:07PM +0900, Chanwoo Choi wrote:
> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
> Octa-core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
> PSCI (Power State Coordination Interface) v0.1.
>
> This patch includes following Device Tree node to support Exynos5433 SoC:
> 1. Octa cores for big.LITTLE architecture
> - Cortex-A53 LITTLE Quad-core
> - Cortex-A57 big Quad-core
> - Support PSCI v0.1
>
Patch looks good to me. The GIC interrupt flags will have to be fixed
someday (e.f. https://patchwork.kernel.org/patch/9336553/) but this may
wait... It is violating the GIC since ancient times so I guess we can
violate it some more till someone will be annoyed enough to fix it. :)
BR,
Krzysztof
^ permalink raw reply
* [PATCHv3 4/4] ARM: socfpga: dts: Add Monitor to A10-SR MFD
From: Dinh Nguyen @ 2016-11-03 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097178-24341-5-git-send-email-tthayer@opensource.altera.com>
On 11/02/2016 09:32 AM, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> Add the Monitor functionality to the Arria10 DevKit
> System Resource chip.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> v2 Change from -mon to -monitor for clarity.
> v3 Change node name from a10_monitor to monitor.
> ---
> arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
> index eb00ae3..996e745 100644
> --- a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
> +++ b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
> @@ -121,6 +121,10 @@
> gpio-controller;
> #gpio-cells = <2>;
> };
> +
> + monitor {
> + compatible = "altr,a10sr-monitor";
> + };
> };
> };
>
>
Acked-by: Dinh Nguyen <dinguyen@opensource.altera.com>
^ permalink raw reply
* [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Volodymyr Babchuk @ 2016-11-03 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103193505.GA5600@ermac>
On 3 November 2016 at 21:35, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> On Mon, Oct 31, 2016 at 01:24:14PM -0500, Andrew F. Davis wrote:
>> On 10/29/2016 04:46 AM, Jens Wiklander wrote:
>> > On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
>> >> On 10/28/2016 05:19 AM, Jens Wiklander wrote:
>> >>> Hi,
>> >>>
>> >>> This patch set introduces a generic TEE subsystem. The TEE subsystem will
>> >>> contain drivers for various TEE implementations. A TEE (Trusted Execution
>> >>> Environment) is a trusted OS running in some secure environment, for
>> >>> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
>> >>>
>> >>> Regarding use cases, TrustZone has traditionally been used for
>> >>> offloading secure tasks to the secure world. Examples include:
>> >>> - Secure key handling where the OS may or may not have direct access to key
>> >>> material.
>> >>> - E-commerce and payment technologies. Credentials, credit card numbers etc
>> >>> could be stored in a more secure environment.
>> >>> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
>> >>> etc.
>> >>> - Secure boot to ensure that loaded binaries haven?t been tampered with.
>> >>> It?s not strictly needed for secure boot, but you could enhance security
>> >>> by leveraging a TEE during boot.
>> >>> - Digital Rights Management (DRM), the studios provides content with
>> >>> different resolution depending on the security of the device. Higher
>> >>> security means higher resolution.
>> >>>
>> >>> A TEE could also be used in existing and new technologies. For example IMA
>> >>> (Integrity Measurement Architecture) which has been in the kernel for quite
>> >>> a while. Today you can enhance security by using a TPM-chip to sign the IMA
>> >>> measurement list. This is something that you also could do by leveraging a
>> >>> TEE.
>> >>>
>> >>> Another example could be in 2-factor authentication which is becoming
>> >>> increasingly more important. FIDO (https://fidoalliance.org) for example
>> >>> are using public key cryptography in their 2-factor authentication standard
>> >>> (U2F). With FIDO, a private and public key pair will be generated for every
>> >>> site you visit and the private key should never leave the local device.
>> >>> This is an example where you could use secure storage in a TEE for the
>> >>> private key.
>> >>>
>> >>> Today you will find a quite a few different out of tree implementations of
>> >>> TEE drivers which tends to fragment the TEE ecosystem and development. We
>> >>> think it would be a good idea to have a generic TEE driver integrated in
>> >>> the kernel which would serve as a base for several different TEE solutions,
>> >>> no matter if they are on-chip like TrustZone or if they are on a separate
>> >>> crypto co-processor.
>> >>>
>> >>> To develop this TEE subsystem we have been using the open source TEE called
>> >>> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
>> >>> first TEE solution supported by this new subsystem. OP-TEE is a
>> >>> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
>> >>> only GlobalPlatform TEEs, instead we have tried to design it so that it
>> >>> should work with other TEE solutions also.
>> >>>
>> >>
>> >> The above is my biggest concern with this whole subsystem, to me it
>> >> still feels very OPTEE specific. As much as I would love to believe
>> >> OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
>> >> use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
>> >> to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
>> >> and whatever Intel/AMD are cooking up for x86.
>> >
>> > I'd rather say that it's slightly GlobalPlatform specific, but a bit
>> > more flexible.
>> >
>> >>
>> >> As we all know when things are upstreamed we lose the ability to make
>> >> radical changes easily, especially to full subsystems. What happens when
>> >> this framework, built with only one existing TEE, built by the one
>> >> existing TEE's devs, is not as flexible as we need when other TEEs start
>> >> rolling out?
>> >
>> > Initially the TEE subsystem was much more flexible and was criticized
>> > for that.
>> >
>>
>> That's rather strange, I haven't been following this from the start so I
>> will just take your word that this is where the community wants this
>> subsystem to go.
>>
>> >>
>> >> Do we see this as a chicken and egg situation, or is there any harm
>> >> beyond the pains of supporting an out-of-tree driver for a while, to
>> >> wait until we have at least one other TEE to add to this subsystem
>> >> before merging?
>> >
>> > This proposal is the bare minimum to have something useful. On top of
>> > this there's more things we'd like to add, for example an in-kernel API
>> > for accessing the TEE and secure buffer handling. The way we're dealing
>> > with shared memory need to be improved to better support multiple guests
>> > communicating with one TEE.
>> >
>> > What we can do now with the subsystem now is somewhat limited by the
>> > fact that we're trying to upstream it and want to do that it in
>> > manageable increments.
>> >
>>
>> Fair enough.
>>
>> For now this series is being used in our production SDKs so it has at
>> least some basic testing from us, so for the whole series:
>>
>> Tested-by: Andrew F. Davis <afd@ti.com>
>
> Thanks, Andrew. A summary of all tags so far:
>
> When I sent out this patch set I missed including the previous
> tested-bys:
> Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey)
> Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com>
>
> Then there's also the acked-by from Andreas which should have been
> included even if the mail now bounces:
> Acked-by: Andreas Dannenberg <dannenberg@ti.com>
>
> The DT patch has (since v8):
> Acked-by: Rob Herring <robh@kernel.org>
>
> Thanks,
> Jens
Jens,
I want to specify that I tested those patches on Renesas RCAR H3 platform.
So my please update my Tested-by:
Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (RCAR H3)
As far as I know, Renesas plans to use OP-TEE as a driver for cryptographic
accelerators and others secure peripherals. So TEE support will be crucial
for theirs platform.
Also I suspect that every platform on ARMv8 will include ARM Trusted Firmware
(because it now provides PSCI) and some sort of TEE. So we really need
generic TEE interface in the kernel.
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Joerg Roedel @ 2016-11-03 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22ac6cba7386e133a97af729526f4e6457745554.1478194747.git.robin.murphy@arm.com>
On Thu, Nov 03, 2016 at 05:39:07PM +0000, Robin Murphy wrote:
> drivers/iommu/arm-smmu-v3.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
This looks better, thanks. Cherry-picked the other fix from the
pull-request and applied this on-top.
Joerg
^ permalink raw reply
* [PATCH v5 0/7] add NS2 support to bgmac
From: David Miller @ 2016-11-03 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478106488-11779-1-git-send-email-jon.mason@broadcom.com>
From: Jon Mason <jon.mason@broadcom.com>
Date: Wed, 2 Nov 2016 13:08:01 -0400
> Add support for the amac found in the Broadcom Northstar2 SoC to the
> bgmac driver. This necessitates adding support to connect to an
> externally defined phy (as described in the device tree) in the driver.
> These phy changes are in addition to the changes necessary to get NS2
> working.
This does not apply cleanly to the net-next, please respin.
^ permalink raw reply
* [PATCH v3 3/5] arm64: dts: exynos: Add dts files for Samsung Exynos5433 64bit SoC
From: Krzysztof Kozlowski @ 2016-11-03 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103194716.GC12945@kozik-lap>
On Thu, Nov 03, 2016 at 09:47:16PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Nov 03, 2016 at 03:39:07PM +0900, Chanwoo Choi wrote:
> > This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
> > Octa-core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
> > PSCI (Power State Coordination Interface) v0.1.
> >
> > This patch includes following Device Tree node to support Exynos5433 SoC:
> > 1. Octa cores for big.LITTLE architecture
> > - Cortex-A53 LITTLE Quad-core
> > - Cortex-A57 big Quad-core
> > - Support PSCI v0.1
> >
>
> Patch looks good to me. The GIC interrupt flags will have to be fixed
> someday (e.f. https://patchwork.kernel.org/patch/9336553/) but this may
> wait... It is violating the GIC since ancient times so I guess we can
> violate it some more till someone will be annoyed enough to fix it. :)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 4/5] arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board
From: Krzysztof Kozlowski @ 2016-11-03 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-5-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 03, 2016 at 03:39:08PM +0900, Chanwoo Choi wrote:
> This patch adds the Device Tree source for Exynos5433-based Samsung TM2 board.
> This board fully support the all things for mobile target.
>
> This patch supports the following devices:
> 1. basic SoC
> - Initial booting for Samsung Exynos5433 SoC
> - DRAM LPDDR3 (3GB)
> - eMMC (32GB)
> - ARM architecture timer
>
> 2. power management devices
> - Sasmung S2MPS13 PMIC for the power supply
> - CPUFREQ for big.LITTLE cores
> - TMU for big.LITTLE cores and GPU
> - ADC with thermistor to measure the temperature of AP/Battery/Charger
> - Maxim MAX77843 Interface PMIC (MUIC/Haptic/Regulator)
>
> 3. sound devices
> - I2S for sound bus
> - LPASS for sound power control
> - Wolfson WM5110 for sound codec
> - Maxim MAX98504 for speaker amplifier
> - TM2 ASoC Machine device driver node
>
> 3. display devices
> - DECON, DSI and MIC for the panel output
>
> 4. usb devices
> - USB 3.0 DRD (Dual Role Device)
> - USB 3.0 Host controller
>
> 5. storage devices
> - MSHC (Mobile Storage Host Controller) for eMMC device
>
> 6. misc devices
> - gpio-keys (power, volume up/down, home key)
> - PWM (Pulse Width Modulation Timer)
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Inha Song <ideal.song@samsung.com>
> Signed-off-by: Ingi kim <ingi2.kim@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> .../bindings/arm/samsung/samsung-boards.txt | 1 +
> arch/arm64/boot/dts/exynos/Makefile | 4 +-
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 974 +++++++++++++++++++++
> 3 files changed, 978 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 5/5] arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board
From: Krzysztof Kozlowski @ 2016-11-03 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-6-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 03, 2016 at 03:39:09PM +0900, Chanwoo Choi wrote:
> This patch adds the Device Tree source for Exynos5433-based Samsung TM2E
> board. TM2E board is the most similar with TM2 board. The exynos5433-tm2e.dts
> include the difference between TM2 and TM2E.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Inha Song <ideal.song@samsung.com>
> Signed-off-by: Ingi kim <ingi2.kim@samsung.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> .../bindings/arm/samsung/samsung-boards.txt | 1 +
> arch/arm64/boot/dts/exynos/Makefile | 1 +
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 41 ++++++++++++++++++++++
> 3 files changed, 43 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCHv2 00/11] arm64: move thread_info off of the task stack
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Building atop of Andy's work on x86 and generic code, these patches move
arm64's thread_info off of the stack and into task_struct. This protects
thread_info from corruption in the face of stack overflow, and serves as
a step towards fully robust stack overflow handling, which will be
addressed by subsequent patches.
The patches are based atop of a couple or preparatory patches (also
needed for s390) which I've placed in my kernel.org repo, tagged as
core-ti-stack-split. I expect this to be a stable base for both arm64
and s390.
This series, atop of that, is in the arm64/ti-stack-split branch [2].
Since RFC [3]:
* Rely on prior patches to make thread_info arch-specific
* Make smp_processor_id() use a per-cpu variable
* Split out current_stack_pointer
* Make SMP actually work
Since v1 [4]:
* Fix irq stack entry from EL1
* Fix single step entry from EL0
* Add Laura's Tested-by
* Make comments more helpful
* Make asm-offsets use task_struct, and s/TI_*/TSK_TI_*/
* Add patch to unexport walk_stackframe
[1] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=core-ti-stack-split
[2] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/ti-stack-split
[3] https://lkml.kernel.org/r/1473947349-14521-1-git-send-email-mark.rutland at arm.com
[4] https://lkml.kernel.org/r/1476904234-9511-1-git-send-email-mark.rutland at arm.com
Thanks,
Mark.
Mark Rutland (11):
arm64: thread_info remove stale items
arm64: asm-offsets: remove unused definitions
arm64: factor out current_stack_pointer
arm64: traps: simplify die() and __die()
arm64: unexport walk_stackframe
arm64: prep stack walkers for THREAD_INFO_IN_TASK
arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx
arm64: smp: prepare for smp_processor_id() rework
arm64: make cpu number a percpu variable
arm64: assembler: introduce ldr_this_cpu
arm64: split thread_info from task stack
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/assembler.h | 19 +++++++++++----
arch/arm64/include/asm/current.h | 22 +++++++++++++++++
arch/arm64/include/asm/percpu.h | 2 ++
arch/arm64/include/asm/perf_event.h | 2 ++
arch/arm64/include/asm/smp.h | 12 +++++++++-
arch/arm64/include/asm/stack_pointer.h | 9 +++++++
arch/arm64/include/asm/suspend.h | 2 +-
arch/arm64/include/asm/thread_info.h | 32 +------------------------
arch/arm64/kernel/asm-offsets.c | 10 ++++----
arch/arm64/kernel/entry.S | 43 +++++++++++++++++-----------------
arch/arm64/kernel/head.S | 11 +++++----
arch/arm64/kernel/process.c | 36 +++++++++++++++++++++++-----
arch/arm64/kernel/return_address.c | 1 +
arch/arm64/kernel/sleep.S | 3 ---
arch/arm64/kernel/smp.c | 14 ++++++++---
arch/arm64/kernel/stacktrace.c | 7 +++++-
arch/arm64/kernel/suspend.c | 6 -----
arch/arm64/kernel/traps.c | 19 +++++++++------
arch/arm64/mm/proc.S | 6 +++++
21 files changed, 162 insertions(+), 96 deletions(-)
create mode 100644 arch/arm64/include/asm/current.h
create mode 100644 arch/arm64/include/asm/stack_pointer.h
--
2.7.4
^ permalink raw reply
* [PATCHv2 01/11] arm64: thread_info remove stale items
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
We have a comment claiming __switch_to() cares about where cpu_context
is located relative to cpu_domain in thread_info. However arm64 has
never had a thread_info::cpu_domain field, and neither __switch_to nor
cpu_switch_to care where the cpu_context field is relative to others.
Additionally, the init_thread_info alias is never used anywhere in the
kernel, and will shortly become problematic when thread_info is moved
into task_struct.
This patch removes both.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/thread_info.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index e9ea5a6..76a9559 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -42,7 +42,6 @@ typedef unsigned long mm_segment_t;
/*
* low level task data that entry.S needs immediate access to.
- * __switch_to() assumes cpu_context follows immediately after cpu_domain.
*/
struct thread_info {
unsigned long flags; /* low level flags */
@@ -60,7 +59,6 @@ struct thread_info {
.addr_limit = KERNEL_DS, \
}
-#define init_thread_info (init_thread_union.thread_info)
#define init_stack (init_thread_union.stack)
/*
--
2.7.4
^ permalink raw reply related
* [PATCHv2 02/11] arm64: asm-offsets: remove unused definitions
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
Subsequent patches will move the thread_info::{task,cpu} fields, and the
current TI_{TASK,CPU} offset definitions are not used anywhere.
This patch removes the redundant definitions.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/asm-offsets.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 4a2f0f0..d30b232 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -39,8 +39,6 @@ int main(void)
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
DEFINE(TI_ADDR_LIMIT, offsetof(struct thread_info, addr_limit));
- DEFINE(TI_TASK, offsetof(struct thread_info, task));
- DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
BLANK();
DEFINE(THREAD_CPU_CONTEXT, offsetof(struct task_struct, thread.cpu_context));
BLANK();
--
2.7.4
^ permalink raw reply related
* [PATCHv2 03/11] arm64: factor out current_stack_pointer
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
We define current_stack_pointer in <asm/thread_info.h>, though other
files and header relying upon it do not have this necessary include, and
are thus fragile to changes in the header soup.
Subsequent patches will affect the header soup such that directly
including <asm/thread_info.h> may result in a circular header include in
some of these cases, so we can't simply include <asm/thread_info.h>.
Instead, factor current_thread_info into its own header, and have all
existing users include this explicitly.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/percpu.h | 2 ++
arch/arm64/include/asm/perf_event.h | 2 ++
arch/arm64/include/asm/stack_pointer.h | 9 +++++++++
arch/arm64/include/asm/thread_info.h | 6 +-----
arch/arm64/kernel/return_address.c | 1 +
arch/arm64/kernel/stacktrace.c | 1 +
arch/arm64/kernel/traps.c | 1 +
7 files changed, 17 insertions(+), 5 deletions(-)
create mode 100644 arch/arm64/include/asm/stack_pointer.h
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 5394c84..d7a3c62 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -16,6 +16,8 @@
#ifndef __ASM_PERCPU_H
#define __ASM_PERCPU_H
+#include <asm/stack_pointer.h>
+
static inline void set_my_cpu_offset(unsigned long off)
{
asm volatile("msr tpidr_el1, %0" :: "r" (off) : "memory");
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 2065f46..9eee2be 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -17,6 +17,8 @@
#ifndef __ASM_PERF_EVENT_H
#define __ASM_PERF_EVENT_H
+#include <asm/stack_pointer.h>
+
#define ARMV8_PMU_MAX_COUNTERS 32
#define ARMV8_PMU_COUNTER_MASK (ARMV8_PMU_MAX_COUNTERS - 1)
diff --git a/arch/arm64/include/asm/stack_pointer.h b/arch/arm64/include/asm/stack_pointer.h
new file mode 100644
index 0000000..ffcdf74
--- /dev/null
+++ b/arch/arm64/include/asm/stack_pointer.h
@@ -0,0 +1,9 @@
+#ifndef __ASM_STACK_POINTER_H
+#define __ASM_STACK_POINTER_H
+
+/*
+ * how to get the current stack pointer from C
+ */
+register unsigned long current_stack_pointer asm ("sp");
+
+#endif /* __ASM_STACK_POINTER_H */
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 76a9559..3a4f85d 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -36,6 +36,7 @@
struct task_struct;
+#include <asm/stack_pointer.h>
#include <asm/types.h>
typedef unsigned long mm_segment_t;
@@ -62,11 +63,6 @@ struct thread_info {
#define init_stack (init_thread_union.stack)
/*
- * how to get the current stack pointer from C
- */
-register unsigned long current_stack_pointer asm ("sp");
-
-/*
* how to get the thread information struct from C
*/
static inline struct thread_info *current_thread_info(void) __attribute_const__;
diff --git a/arch/arm64/kernel/return_address.c b/arch/arm64/kernel/return_address.c
index 1718706..12a87f2 100644
--- a/arch/arm64/kernel/return_address.c
+++ b/arch/arm64/kernel/return_address.c
@@ -12,6 +12,7 @@
#include <linux/export.h>
#include <linux/ftrace.h>
+#include <asm/stack_pointer.h>
#include <asm/stacktrace.h>
struct return_address_data {
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index c2efddf..5b80068 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -22,6 +22,7 @@
#include <linux/stacktrace.h>
#include <asm/irq.h>
+#include <asm/stack_pointer.h>
#include <asm/stacktrace.h>
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index c9986b3..95a5452 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -38,6 +38,7 @@
#include <asm/esr.h>
#include <asm/insn.h>
#include <asm/traps.h>
+#include <asm/stack_pointer.h>
#include <asm/stacktrace.h>
#include <asm/exception.h>
#include <asm/system_misc.h>
--
2.7.4
^ permalink raw reply related
* [PATCHv2 04/11] arm64: traps: simplify die() and __die()
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
In arm64's die and __die routines we pass around a thread_info, and
subsequently use this to determine the relevant task_struct, and the end
of the thread's stack. Subsequent patches will decouple thread_info from
the stack, and this approach will no longer work.
To figure out the end of the stack, we can use the new generic
end_of_stack() helper. As we only call __die() from die(), and die()
always deals with the current task, we can remove the parameter and have
both acquire current directly, which also makes it clear that __die
can't be called for arbitrary tasks.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/traps.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 95a5452..7ac30bf 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -228,10 +228,9 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
#endif
#define S_SMP " SMP"
-static int __die(const char *str, int err, struct thread_info *thread,
- struct pt_regs *regs)
+static int __die(const char *str, int err, struct pt_regs *regs)
{
- struct task_struct *tsk = thread->task;
+ struct task_struct *tsk = current;
static int die_counter;
int ret;
@@ -246,7 +245,8 @@ static int __die(const char *str, int err, struct thread_info *thread,
print_modules();
__show_regs(regs);
pr_emerg("Process %.*s (pid: %d, stack limit = 0x%p)\n",
- TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk), thread + 1);
+ TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk),
+ end_of_stack(tsk));
if (!user_mode(regs)) {
dump_mem(KERN_EMERG, "Stack: ", regs->sp,
@@ -265,7 +265,6 @@ static DEFINE_RAW_SPINLOCK(die_lock);
*/
void die(const char *str, struct pt_regs *regs, int err)
{
- struct thread_info *thread = current_thread_info();
int ret;
oops_enter();
@@ -273,9 +272,9 @@ void die(const char *str, struct pt_regs *regs, int err)
raw_spin_lock_irq(&die_lock);
console_verbose();
bust_spinlocks(1);
- ret = __die(str, err, thread, regs);
+ ret = __die(str, err, regs);
- if (regs && kexec_should_crash(thread->task))
+ if (regs && kexec_should_crash(current))
crash_kexec(regs);
bust_spinlocks(0);
--
2.7.4
^ permalink raw reply related
* [PATCHv2 05/11] arm64: unexport walk_stackframe
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
The walk_stackframe functions is architecture-specific, with a varying
prototype, and common code should not use it directly. None of its
current users can be built as modules. With THREAD_INFO_IN_TASK, users
will also need to hold a stack reference before calling it.
There's no reason for it to be exported, and it's very easy to misuse,
so unexport it for now.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/stacktrace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 5b80068..d53f99d 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -129,7 +129,6 @@ void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
break;
}
}
-EXPORT_SYMBOL(walk_stackframe);
#ifdef CONFIG_STACKTRACE
struct stack_trace_data {
--
2.7.4
^ permalink raw reply related
* [PATCHv2 06/11] arm64: prep stack walkers for THREAD_INFO_IN_TASK
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
When CONFIG_THREAD_INFO_IN_TASK is selected, task stacks may be freed
before a task is destroyed. To account for this, the stacks are
refcounted, and when manipulating the stack of another task, it is
necessary to get/put the stack to ensure it isn't freed and/or re-used
while we do so.
This patch reworks the arm64 stack walking code to account for this.
When CONFIG_THREAD_INFO_IN_TASK is not selected these perform no
refcounting, and this should only be a structural change that does not
affect behaviour.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/process.c | 20 ++++++++++++++------
arch/arm64/kernel/stacktrace.c | 5 +++++
arch/arm64/kernel/traps.c | 5 +++++
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 01753cd..ec7b9c0 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -350,27 +350,35 @@ struct task_struct *__switch_to(struct task_struct *prev,
unsigned long get_wchan(struct task_struct *p)
{
struct stackframe frame;
- unsigned long stack_page;
+ unsigned long stack_page, ret = 0;
int count = 0;
if (!p || p == current || p->state == TASK_RUNNING)
return 0;
+ stack_page = (unsigned long)try_get_task_stack(p);
+ if (!stack_page)
+ return 0;
+
frame.fp = thread_saved_fp(p);
frame.sp = thread_saved_sp(p);
frame.pc = thread_saved_pc(p);
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
frame.graph = p->curr_ret_stack;
#endif
- stack_page = (unsigned long)task_stack_page(p);
do {
if (frame.sp < stack_page ||
frame.sp >= stack_page + THREAD_SIZE ||
unwind_frame(p, &frame))
- return 0;
- if (!in_sched_functions(frame.pc))
- return frame.pc;
+ goto out;
+ if (!in_sched_functions(frame.pc)) {
+ ret = frame.pc;
+ goto out;
+ }
} while (count ++ < 16);
- return 0;
+
+out:
+ put_task_stack(p);
+ return ret;
}
unsigned long arch_align_stack(unsigned long sp)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d53f99d..8a552a3 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -181,6 +181,9 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
struct stack_trace_data data;
struct stackframe frame;
+ if (!try_get_task_stack(tsk))
+ return;
+
data.trace = trace;
data.skip = trace->skip;
@@ -202,6 +205,8 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
walk_stackframe(tsk, &frame, save_trace, &data);
if (trace->nr_entries < trace->max_entries)
trace->entries[trace->nr_entries++] = ULONG_MAX;
+
+ put_task_stack(tsk);
}
void save_stack_trace(struct stack_trace *trace)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ac30bf..4731133 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -148,6 +148,9 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
if (!tsk)
tsk = current;
+ if (!try_get_task_stack(tsk))
+ return;
+
/*
* Switching between stacks is valid when tracing current and in
* non-preemptible context.
@@ -213,6 +216,8 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
stack + sizeof(struct pt_regs));
}
}
+
+ put_task_stack(tsk);
}
void show_stack(struct task_struct *tsk, unsigned long *sp)
--
2.7.4
^ permalink raw reply related
* [PATCHv2 07/11] arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
When returning from idle, we rely on the fact that thread_info lives at
the end of the kernel stack, and restore this by masking the saved stack
pointer. Subsequent patches will sever the relationship between the
stack and thread_info, and to cater for this we must save/restore sp_el0
explicitly, storing it in cpu_suspend_ctx.
As cpu_suspend_ctx must be doubleword aligned, this leaves us with an
extra slot in cpu_suspend_ctx. We can use this to save/restore tpidr_el1
in the same way, which simplifies the code, avoiding pointer chasing on
the restore path (as we no longer need to load thread_info::cpu followed
by the relevant slot in __per_cpu_offset based on this).
This patch stashes both registers in cpu_suspend_ctx.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/suspend.h | 2 +-
arch/arm64/kernel/sleep.S | 3 ---
arch/arm64/kernel/suspend.c | 6 ------
arch/arm64/mm/proc.S | 6 ++++++
4 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/suspend.h b/arch/arm64/include/asm/suspend.h
index b8a313f..de5600f 100644
--- a/arch/arm64/include/asm/suspend.h
+++ b/arch/arm64/include/asm/suspend.h
@@ -1,7 +1,7 @@
#ifndef __ASM_SUSPEND_H
#define __ASM_SUSPEND_H
-#define NR_CTX_REGS 10
+#define NR_CTX_REGS 12
#define NR_CALLEE_SAVED_REGS 12
/*
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index 1bec41b..df67652 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -125,9 +125,6 @@ ENTRY(_cpu_resume)
/* load sp from context */
ldr x2, [x0, #CPU_CTX_SP]
mov sp, x2
- /* save thread_info */
- and x2, x2, #~(THREAD_SIZE - 1)
- msr sp_el0, x2
/*
* cpu_do_resume expects x0 to contain context address pointer
*/
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index bb0cd78..1e3be90 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -47,12 +47,6 @@ void notrace __cpu_suspend_exit(void)
cpu_uninstall_idmap();
/*
- * Restore per-cpu offset before any kernel
- * subsystem relying on it has a chance to run.
- */
- set_my_cpu_offset(per_cpu_offset(cpu));
-
- /*
* PSTATE was not saved over suspend/resume, re-enable any detected
* features that might not have been set correctly.
*/
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 352c73b..6a853a8 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -70,11 +70,14 @@ ENTRY(cpu_do_suspend)
mrs x8, mdscr_el1
mrs x9, oslsr_el1
mrs x10, sctlr_el1
+ mrs x11, tpidr_el1
+ mrs x12, sp_el0
stp x2, x3, [x0]
stp x4, xzr, [x0, #16]
stp x5, x6, [x0, #32]
stp x7, x8, [x0, #48]
stp x9, x10, [x0, #64]
+ stp x11, x12, [x0, #80]
ret
ENDPROC(cpu_do_suspend)
@@ -90,6 +93,7 @@ ENTRY(cpu_do_resume)
ldp x6, x8, [x0, #32]
ldp x9, x10, [x0, #48]
ldp x11, x12, [x0, #64]
+ ldp x13, x14, [x0, #80]
msr tpidr_el0, x2
msr tpidrro_el0, x3
msr contextidr_el1, x4
@@ -112,6 +116,8 @@ ENTRY(cpu_do_resume)
msr mdscr_el1, x10
msr sctlr_el1, x12
+ msr tpidr_el1, x13
+ msr sp_el0, x14
/*
* Restore oslsr_el1 by writing oslar_el1
*/
--
2.7.4
^ permalink raw reply related
* [PATCHv2 08/11] arm64: smp: prepare for smp_processor_id() rework
From: Mark Rutland @ 2016-11-03 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
Subsequent patches will make smp_processor_id() use a percpu variable.
This will make smp_processor_id() dependent on the percpu offset, and
thus we cannot use smp_processor_id() to figure out what to initialise
the offset to.
Prepare for this by initialising the percpu offset based on
current::cpu, which will work regardless of how smp_processor_id() is
implemented. Also, make this relationship obvious by placing this code
together at the start of secondary_start_kernel().
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/smp.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 8507703..f64401f 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -208,7 +208,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
asmlinkage void secondary_start_kernel(void)
{
struct mm_struct *mm = &init_mm;
- unsigned int cpu = smp_processor_id();
+ unsigned int cpu;
+
+ cpu = task_cpu(current);
+ set_my_cpu_offset(per_cpu_offset(cpu));
/*
* All kernel threads share the same mm context; grab a
@@ -217,8 +220,6 @@ asmlinkage void secondary_start_kernel(void)
atomic_inc(&mm->mm_count);
current->active_mm = mm;
- set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
-
/*
* TTBR0 is only used for the identity mapping at this stage. Make it
* point to zero page to avoid speculatively fetching new entries.
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox