* [PATCH v3] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-22 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526571941-9816-1-git-send-email-Dave.Martin@arm.com>
Hi Dave,
On Thu, May 17, 2018 at 04:45:41PM +0100, Dave Martin wrote:
> Stateful CPU architecture extensions may require the signal frame
> to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> However, changing this #define is an ABI break.
[...]
> For arm64 SVE:
>
> The SVE context block in the signal frame needs to be considered
> too when computing the maximum possible signal frame size.
>
> Because the size of this block depends on the vector length, this
> patch computes the size based not on the thread's current vector
> length but instead on the maximum possible vector length: this
> determines the maximum size of SVE context block that can be
> observed in any signal frame for the lifetime of the process.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Alex Benn?e <alex.bennee@linaro.org>
>
> ---
>
> Changes since v2:
>
> * Redefine AT_MINSIGSTKSZ as 51 to avoid clash with values defined by
> other architectures.
>
> This turns out to be a problem for glibc; also random userspace
> software does not necessary check the architecture before using
> getauxval() or otherwise parsing the aux vector, which can make
> aliased tags problematic.
>
> Really, the headers need cleaning up tree-wide in such away that the
> AT_* definitions do not appear to be arch-private. To be addressed
> separately.
> ---
> arch/arm64/include/asm/elf.h | 11 ++++++++
> arch/arm64/include/asm/processor.h | 5 ++++
> arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
> arch/arm64/kernel/cpufeature.c | 1 +
> arch/arm64/kernel/signal.c | 51 +++++++++++++++++++++++++++++++-----
> 5 files changed, 63 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index fac1c4d..dc32adb 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -24,6 +24,11 @@
> #include <asm/ptrace.h>
> #include <asm/user.h>
>
> +#ifndef __ASSEMBLY__
> +#include <linux/bug.h>
> +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> +#endif
Maybe move these inside the pre-existing #ifndef __ASSEMBLY__ block.
> /*
> * AArch64 static relocation types.
> */
> @@ -146,8 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> /* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
> #define ARCH_DLINFO \
> do { \
> + int minsigstksz = signal_minsigstksz; \
> + \
> + if (WARN_ON(minsigstksz <= 0)) \
> + minsigstksz = MINSIGSTKSZ; \
> + \
How can this happen?
> NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> (elf_addr_t)current->mm->context.vdso); \
> + NEW_AUX_ENT(AT_MINSIGSTKSZ, minsigstksz); \
> } while (0)
>
> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 7675989..6f60e92 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -35,6 +35,8 @@
> #ifdef __KERNEL__
>
> #include <linux/build_bug.h>
> +#include <linux/cache.h>
> +#include <linux/init.h>
> #include <linux/stddef.h>
> #include <linux/string.h>
>
> @@ -244,6 +246,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
> void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
> void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
>
> +extern int __ro_after_init signal_minsigstksz; /* user signal frame size */
Probably better as unsigned long, to be consistent with the size field
of the sigframe user layout structure.
> +extern void __init minsigstksz_setup(void);
> +
> /* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
> #define SVE_SET_VL(arg) sve_set_current_vl(arg)
> #define SVE_GET_VL() sve_get_current_vl()
> diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
> index ec0a86d..743c0b8 100644
> --- a/arch/arm64/include/uapi/asm/auxvec.h
> +++ b/arch/arm64/include/uapi/asm/auxvec.h
> @@ -19,7 +19,8 @@
>
> /* vDSO location */
> #define AT_SYSINFO_EHDR 33
> +#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
>
> -#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
> +#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
>
> #endif
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9d1b06d..0e0b53d 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1619,6 +1619,7 @@ void __init setup_cpu_features(void)
> pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
>
> sve_setup();
> + minsigstksz_setup();
>
> /* Advertise that we have computed the system capabilities */
> set_sys_caps_initialised();
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 154b7d3..ae8d4ea 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -17,6 +17,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/cache.h>
> #include <linux/compat.h>
> #include <linux/errno.h>
> #include <linux/kernel.h>
> @@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
> return 0;
> }
>
> -/* Determine the layout of optional records in the signal frame */
> -static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> +/*
> + * Determine the layout of optional records in the signal frame
> + *
> + * add_all: if true, lays out the biggest possible signal frame for
> + * this task; otherwise, generates a layout for the current state
> + * of the task.
> + */
> +static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
> + bool add_all)
> {
> int err;
>
> @@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> return err;
>
> /* fault information, if valid */
> - if (current->thread.fault_code) {
> + if (add_all || current->thread.fault_code) {
> err = sigframe_alloc(user, &user->esr_offset,
> sizeof(struct esr_context));
> if (err)
> @@ -591,8 +599,18 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> if (system_supports_sve()) {
> unsigned int vq = 0;
>
> - if (test_thread_flag(TIF_SVE))
> - vq = sve_vq_from_vl(current->thread.sve_vl);
> + if (add_all || test_thread_flag(TIF_SVE)) {
> + int vl = sve_max_vl;
> +
> + if (!add_all)
> + vl = current->thread.sve_vl;
> +
> + /* Fail safe if something wasn't initialised */
> + if (WARN_ON(!sve_vl_valid(vl)))
> + vl = SVE_VL_MIN;
How can this happen?
> +
> + vq = sve_vq_from_vl(vl);
> + }
>
> err = sigframe_alloc(user, &user->sve_offset,
> SVE_SIG_CONTEXT_SIZE(vq));
> @@ -603,7 +621,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> return sigframe_alloc_end(user);
> }
>
> -
> static int setup_sigframe(struct rt_sigframe_user_layout *user,
> struct pt_regs *regs, sigset_t *set)
> {
> @@ -701,7 +718,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
> int err;
>
> init_user_layout(user);
> - err = setup_sigframe_layout(user);
> + err = setup_sigframe_layout(user, false);
> if (err)
> return err;
>
> @@ -936,3 +953,23 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
> thread_flags = READ_ONCE(current_thread_info()->flags);
> } while (thread_flags & _TIF_WORK_MASK);
> }
> +
> +int __ro_after_init signal_minsigstksz;
> +
> +/*
> + * Determine the stack space required for guaranteed signal devliery.
> + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> + */
> +void __init minsigstksz_setup(void)
> +{
> + struct rt_sigframe_user_layout user;
> +
> + init_user_layout(&user);
> +
> + if (WARN_ON(setup_sigframe_layout(&user, true)))
> + signal_minsigstksz = SIGSTKSZ;
Why not just omit the aux record in this case? Something has gone badly
wrong, so it's unlikely we're going to get much further anyway.
Will
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Sebastian Andrzej Siewior @ 2018-05-22 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522131004.3012953c@gandalf.local.home>
On 2018-05-22 13:10:04 [-0400], Steven Rostedt wrote:
> On Thu, 17 May 2018 14:40:06 +0200
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
> > +static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
> > /*
> > * Update current's FPSIMD/SVE registers from thread_struct.
> > *
> > @@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
> > * non-SVE thread.
> > */
> > if (task == current) {
> > + local_lock(fpsimd_lock);
> > local_bh_disable();
>
> I'm surprised that we don't have a "local_lock_bh()"?
right. Like the last time when we introduced a global lock with no
locking context?
> -- Steve
>
> >
> > task_fpsimd_save();
Sebastian
^ permalink raw reply
* [PATCH V3 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-22 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526890046-10565-9-git-send-email-christophe.roullier@st.com>
On Mon, May 21, 2018 at 10:07:26AM +0200, Christophe Roullier wrote:
> This patch describes syscon DT bindings.
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
> Documentation/devicetree/bindings/arm/stm32.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt b/Documentation/devicetree/bindings/arm/stm32.txt
> index 6808ed9..e46ebad 100644
> --- a/Documentation/devicetree/bindings/arm/stm32.txt
> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
> @@ -8,3 +8,8 @@ using one of the following compatible strings:
> st,stm32f746
> st,stm32h743
> st,stm32mp157
> +
> +Required nodes:
> +- syscon: the soc bus node must have a system controller node pointing to the
> + global control registers, with the compatible string
> + "st,stm32mp157-syscfg", "syscon";
Please don't mix soc/board bindings with other nodes. So perhaps
stm32-syscon.txt.
Rob
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Marc Zyngier @ 2018-05-22 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fKjFT-00064F-Bs@rmk-PC.armlinux.org.uk>
On 21/05/18 12:45, Russell King wrote:
> Add PSCI based hardening for cores that require more complex handling in
> firmware.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/mm/proc-v7-bugs.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++
> arch/arm/mm/proc-v7.S | 21 +++++++++++++++++++
> 2 files changed, 71 insertions(+)
>
> diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
> index 65a9b8141f86..0c37e6a2830d 100644
> --- a/arch/arm/mm/proc-v7-bugs.c
> +++ b/arch/arm/mm/proc-v7-bugs.c
> @@ -1,9 +1,12 @@
> // SPDX-License-Identifier: GPL-2.0
> +#include <linux/arm-smccc.h>
> #include <linux/kernel.h>
> +#include <linux/psci.h>
> #include <linux/smp.h>
>
> #include <asm/cp15.h>
> #include <asm/cputype.h>
> +#include <asm/proc-fns.h>
> #include <asm/system_misc.h>
>
> void cpu_v7_bugs_init(void);
> @@ -39,6 +42,9 @@ void cpu_v7_ca15_ibe(void)
> #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> void (*harden_branch_predictor)(void);
>
> +extern void cpu_v7_smc_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm);
> +extern void cpu_v7_hvc_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm);
> +
> static void harden_branch_predictor_bpiall(void)
> {
> write_sysreg(0, BPIALL);
> @@ -49,6 +55,18 @@ static void harden_branch_predictor_iciallu(void)
> write_sysreg(0, ICIALLU);
> }
>
> +#ifdef CONFIG_ARM_PSCI
> +static void call_smc_arch_workaround_1(void)
> +{
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
> +}
> +
> +static void call_hvc_arch_workaround_1(void)
> +{
> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
> +}
> +#endif
> +
> void cpu_v7_bugs_init(void)
> {
> const char *spectre_v2_method = NULL;
> @@ -73,6 +91,38 @@ void cpu_v7_bugs_init(void)
> spectre_v2_method = "ICIALLU";
> break;
> }
> +
> +#ifdef CONFIG_ARM_PSCI
> + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
> + struct arm_smccc_res res;
> +
> + switch (psci_ops.conduit) {
> + case PSCI_CONDUIT_HVC:
> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> + if ((int)res.a0 < 0)
> + break;
I just realised that there is a small, but significant difference
between this and the arm64 version: On arm64, we have a table of
vulnerable implementations, and we try the mitigation on a per-cpu
basis. Here, you entirely rely on the firmware to discover whether the
CPU needs mitigation or not. You then need to check for a return value
of 1, which indicates that although the mitigation is implemented, it is
not required on this particular CPU.
But that's probably moot if you don't support BL systems.
> + harden_branch_predictor = call_hvc_arch_workaround_1;
> + processor.switch_mm = cpu_v7_hvc_switch_mm;
> + spectre_v2_method = "hypervisor";
> + break;
> +
> + case PSCI_CONDUIT_SMC:
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> + if ((int)res.a0 < 0)
> + break;
> + harden_branch_predictor = call_smc_arch_workaround_1;
> + processor.switch_mm = cpu_v7_smc_switch_mm;
> + spectre_v2_method = "firmware PSCI";
My previous remark still stands: this is not really PSCI.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
-
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Steven Rostedt @ 2018-05-22 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522172115.fpqguqlsq6bavtxy@linutronix.de>
On Tue, 22 May 2018 19:21:16 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> On 2018-05-22 13:10:04 [-0400], Steven Rostedt wrote:
> > On Thu, 17 May 2018 14:40:06 +0200
> > Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> >
> > > +static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
> > > /*
> > > * Update current's FPSIMD/SVE registers from thread_struct.
> > > *
> > > @@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
> > > * non-SVE thread.
> > > */
> > > if (task == current) {
> > > + local_lock(fpsimd_lock);
> > > local_bh_disable();
> >
> > I'm surprised that we don't have a "local_lock_bh()"?
>
> right. Like the last time when we introduced a global lock with no
> locking context?
>
I meant, we could have local_lock_bh(fpsimd_lock); that would turn into
a local_bh_disable() when !PREEMPT_RT.
-- Steve
^ permalink raw reply
* [PATCH 1/6] coresight: remove CORESIGHT_LINKS_AND_SINKS dependencies and selections
From: Mathieu Poirier @ 2018-05-22 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518012024.22645-1-kim.phillips@arm.com>
On Thu, May 17, 2018 at 08:20:19PM -0500, Kim Phillips wrote:
> A coresight topology doesn't need to include links, i.e., a source can
> be directly connected to a sink. As such, selecting and/or depending on
> LINKS_AND_SINKS is no longer needed.
I'm good with this patch but now the help text for CORESIGHT_LINKS_AND_SINKS no
longer match what the config does. I see two ways to fix this:
1) Rework the help text.
2) Rework CORESIGHT_LINKS_AND_SINKS to be CORESIGHT_FUNNEL and move
coresight-replicator.o under CORESIGHT_DYNAMIC_REPLICATOR in the Makefile. I
really liked your idea of making the replicator driver intelligent enough to
deal with both DT and platform declaration, which merges two driver into one.
I'm obviously favouring the second option but recognise it doesn't have to be
part of this patchet. So for this set please rework the help text for
CORESIGHT_LINKS_AND_SINKS. Once we've dealt with this topic we can refactor the
replicator driver.
Thanks,
Mathieu
>
> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/Kconfig | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index ef9cb3c164e1..83fb78651ef9 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -23,7 +23,6 @@ config CORESIGHT_LINKS_AND_SINKS
>
> config CORESIGHT_LINK_AND_SINK_TMC
> bool "Coresight generic TMC driver"
> - depends on CORESIGHT_LINKS_AND_SINKS
> help
> This enables support for the Trace Memory Controller driver.
> Depending on its configuration the device can act as a link (embedded
> @@ -33,7 +32,6 @@ config CORESIGHT_LINK_AND_SINK_TMC
>
> config CORESIGHT_SINK_TPIU
> bool "Coresight generic TPIU driver"
> - depends on CORESIGHT_LINKS_AND_SINKS
> help
> This enables support for the Trace Port Interface Unit driver,
> responsible for bridging the gap between the on-chip coresight
> @@ -44,7 +42,6 @@ config CORESIGHT_SINK_TPIU
>
> config CORESIGHT_SINK_ETBV10
> bool "Coresight ETBv1.0 driver"
> - depends on CORESIGHT_LINKS_AND_SINKS
> help
> This enables support for the Embedded Trace Buffer version 1.0 driver
> that complies with the generic implementation of the component without
> @@ -53,7 +50,6 @@ config CORESIGHT_SINK_ETBV10
> config CORESIGHT_SOURCE_ETM3X
> bool "CoreSight Embedded Trace Macrocell 3.x driver"
> depends on !ARM64
> - select CORESIGHT_LINKS_AND_SINKS
> help
> This driver provides support for processor ETM3.x and PTM1.x modules,
> which allows tracing the instructions that a processor is executing
> @@ -63,7 +59,6 @@ config CORESIGHT_SOURCE_ETM3X
> config CORESIGHT_SOURCE_ETM4X
> bool "CoreSight Embedded Trace Macrocell 4.x driver"
> depends on ARM64
> - select CORESIGHT_LINKS_AND_SINKS
> help
> This driver provides support for the ETM4.x tracer module, tracing the
> instructions that a processor is executing. This is primarily useful
> @@ -72,7 +67,6 @@ config CORESIGHT_SOURCE_ETM4X
>
> config CORESIGHT_DYNAMIC_REPLICATOR
> bool "CoreSight Programmable Replicator driver"
> - depends on CORESIGHT_LINKS_AND_SINKS
> help
> This enables support for dynamic CoreSight replicator link driver.
> The programmable ATB replicator allows independent filtering of the
> @@ -81,7 +75,6 @@ config CORESIGHT_DYNAMIC_REPLICATOR
> config CORESIGHT_STM
> bool "CoreSight System Trace Macrocell driver"
> depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
> - select CORESIGHT_LINKS_AND_SINKS
> select STM
> help
> This driver provides support for hardware assisted software
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Sebastian Andrzej Siewior @ 2018-05-22 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522132429.6f1dcf92@gandalf.local.home>
On 2018-05-22 13:24:29 [-0400], Steven Rostedt wrote:
> On Tue, 22 May 2018 19:21:16 +0200
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
> > On 2018-05-22 13:10:04 [-0400], Steven Rostedt wrote:
> > > On Thu, 17 May 2018 14:40:06 +0200
> > > Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> > >
> > > > +static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
> > > > /*
> > > > * Update current's FPSIMD/SVE registers from thread_struct.
> > > > *
> > > > @@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
> > > > * non-SVE thread.
> > > > */
> > > > if (task == current) {
> > > > + local_lock(fpsimd_lock);
> > > > local_bh_disable();
> > >
> > > I'm surprised that we don't have a "local_lock_bh()"?
> >
> > right. Like the last time when we introduced a global lock with no
> > locking context?
> >
>
> I meant, we could have local_lock_bh(fpsimd_lock); that would turn into
> a local_bh_disable() when !PREEMPT_RT.
Oh that part. That could be possible I guess. I need to look into the
second part which disables preemption while the FPU is taken.
> -- Steve
Sebastian
^ permalink raw reply
* [PATCH v2 01/13] dt-bindings: power: add RK3036 SoCs header for power-domain
From: Rob Herring @ 2018-05-22 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268501-9200-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:28:21AM +0800, Elaine Zhang wrote:
> From: Caesar Wang <wxt@rock-chips.com>
>
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> include/dt-bindings/power/rk3036-power.h | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 include/dt-bindings/power/rk3036-power.h
>
> diff --git a/include/dt-bindings/power/rk3036-power.h b/include/dt-bindings/power/rk3036-power.h
> new file mode 100644
> index 000000000000..59e09f1c5af7
> --- /dev/null
> +++ b/include/dt-bindings/power/rk3036-power.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (c) 2017 Rockchip Electronics Co. Ltd.
> + * Author: Caesar Wang <wxt@rock-chips.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
Use SPDX tag instead.
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
> + */
> +
> +#ifndef __DT_BINDINGS_POWER_RK3036_POWER_H__
> +#define __DT_BINDINGS_POWER_RK3036_POWER_H__
> +
> +#define RK3036_PD_MSCH 0
> +#define RK3036_PD_CORE 1
> +#define RK3036_PD_PERI 2
> +#define RK3036_PD_VIO 3
> +#define RK3036_PD_VPU 4
> +#define RK3036_PD_GPU 5
> +#define RK3036_PD_SYS 6
> +
> +#endif
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH v2 02/13] dt-bindings: add binding for rk3036 power domains
From: Rob Herring @ 2018-05-22 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268528-9247-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:28:48AM +0800, Elaine Zhang wrote:
> From: Caesar Wang <wxt@rock-chips.com>
>
> Add binding documentation for the power domains
> found on Rockchip RK3036 SoCs.
>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 05/13] dt-bindings: power: add RK3128 SoCs header for power-domain
From: Rob Herring @ 2018-05-22 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268602-9760-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:30:02AM +0800, Elaine Zhang wrote:
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> include/dt-bindings/power/rk3128-power.h | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 include/dt-bindings/power/rk3128-power.h
>
> diff --git a/include/dt-bindings/power/rk3128-power.h b/include/dt-bindings/power/rk3128-power.h
> new file mode 100644
> index 000000000000..26aef519cd94
> --- /dev/null
> +++ b/include/dt-bindings/power/rk3128-power.h
> @@ -0,0 +1,28 @@
> +/*
> + * Copyright (c) 2017 Rockchip Electronics Co. Ltd.
> + * Author: Elaine Zhang <zhangqing@rock-chips.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
Use SPDX tag instead, otherwise:
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 06/13] dt-bindings: add binding for rk3128 power domains
From: Rob Herring @ 2018-05-22 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268626-11855-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:30:26AM +0800, Elaine Zhang wrote:
> Add binding documentation for the power domains
> found on Rockchip RK3128 SoCs.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 08/13] dt-bindings: power: add RK3228 SoCs header for power-domain
From: Rob Herring @ 2018-05-22 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268668-20006-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:31:08AM +0800, Elaine Zhang wrote:
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> include/dt-bindings/power/rk3228-power.h | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 include/dt-bindings/power/rk3228-power.h
>
> diff --git a/include/dt-bindings/power/rk3228-power.h b/include/dt-bindings/power/rk3228-power.h
> new file mode 100644
> index 000000000000..fa1264d5a995
> --- /dev/null
> +++ b/include/dt-bindings/power/rk3228-power.h
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
This goes on the first line. checkpatch.pl will tell you this.
The license here is different than all the others, was that the intent?
> + */
> +
> +#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__
> +#define __DT_BINDINGS_POWER_RK3228_POWER_H__
> +
> +/**
> + * RK3228 idle id Summary.
> + */
> +
> +#define RK3228_PD_CORE 0
> +#define RK3228_PD_MSCH 1
> +#define RK3228_PD_BUS 2
> +#define RK3228_PD_SYS 3
> +#define RK3228_PD_VIO 4
> +#define RK3228_PD_VOP 5
> +#define RK3228_PD_VPU 6
> +#define RK3228_PD_RKVDEC 7
> +#define RK3228_PD_GPU 8
> +#define RK3228_PD_PERI 9
> +#define RK3228_PD_GMAC 10
> +
> +#endif
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH v2 09/13] dt-bindings: add binding for rk3228 power domains
From: Rob Herring @ 2018-05-22 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268684-22709-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:31:24AM +0800, Elaine Zhang wrote:
> Add binding documentation for the power domains
> found on Rockchip RK3228 SoCs.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Rob Herring @ 2018-05-22 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268724-25288-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:32:04AM +0800, Elaine Zhang wrote:
> From: Finley Xiao <finley.xiao@rock-chips.com>
>
> According to a description from TRM, add all the power domains.
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> include/dt-bindings/power/px30-power.h | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 include/dt-bindings/power/px30-power.h
>
> diff --git a/include/dt-bindings/power/px30-power.h b/include/dt-bindings/power/px30-power.h
> new file mode 100644
> index 000000000000..4ed482e80950
> --- /dev/null
> +++ b/include/dt-bindings/power/px30-power.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
Same comments here.
> + */
> +
> +#ifndef __DT_BINDINGS_POWER_PX30_POWER_H__
> +#define __DT_BINDINGS_POWER_PX30_POWER_H__
> +
> +/* VD_CORE */
> +#define PX30_PD_A35_0 0
> +#define PX30_PD_A35_1 1
> +#define PX30_PD_A35_2 2
> +#define PX30_PD_A35_3 3
> +#define PX30_PD_SCU 4
> +
> +/* VD_LOGIC */
> +#define PX30_PD_USB 5
> +#define PX30_PD_DDR 6
> +#define PX30_PD_SDCARD 7
> +#define PX30_PD_CRYPTO 8
> +#define PX30_PD_GMAC 9
> +#define PX30_PD_MMC_NAND 10
> +#define PX30_PD_VPU 11
> +#define PX30_PD_VO 12
> +#define PX30_PD_VI 13
> +#define PX30_PD_GPU 14
> +
> +/* VD_PMU */
> +#define PX30_PD_PMU 15
> +
> +#endif
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH] ARM: dts: imx6q: Use correct SDMA script for SPI5 core
From: Fabio Estevam @ 2018-05-22 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522174509.18154-1-sean.nyekjaer@prevas.dk>
On Tue, May 22, 2018 at 2:45 PM, Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:
> According to the reference manual the shp_2_mcu / mcu_2_shp
> scripts must be used for devices connected through the SPBA.
>
> This fixes an issue we saw with DMA transfers.
> Sometimes the SPI controller RX FIFO was not empty after a DMA
> transfer and the driver got stuck in the next PIO transfer when
> it read one word more than expected.
>
> commit dd4b487b32a35 ("ARM: dts: imx6: Use correct SDMA script
> for SPI cores") is fixing the same issue but only for SPI1 - 4.
>
> Fixes: 677940258dd8e ("ARM: dts: imx6q: enable dma for ecspi5")
> Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 5/6] coresight: populate MODULE_AUTHOR, DESCRIPTION, and LICENSEs
From: Mathieu Poirier @ 2018-05-22 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518012024.22645-5-kim.phillips@arm.com>
On Thu, May 17, 2018 at 08:20:23PM -0500, Kim Phillips wrote:
> Necessary prior to enabling to be built as modules.
>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-dynamic-replicator.c | 4 ++++
> drivers/hwtracing/coresight/coresight-etb10.c | 5 +++++
> drivers/hwtracing/coresight/coresight-etm-cp14.c | 4 ++++
> drivers/hwtracing/coresight/coresight-etm-perf.c | 4 ++++
> drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 5 +++++
> drivers/hwtracing/coresight/coresight-etm3x.c | 5 +++++
> drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 4 ++++
> drivers/hwtracing/coresight/coresight-etm4x.c | 5 +++++
> drivers/hwtracing/coresight/coresight-funnel.c | 4 ++++
> drivers/hwtracing/coresight/coresight-replicator.c | 5 +++++
> drivers/hwtracing/coresight/coresight-stm.c | 4 ++++
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 4 ++++
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 ++++
> drivers/hwtracing/coresight/coresight-tmc.c | 4 ++++
> drivers/hwtracing/coresight/coresight-tpiu.c | 5 +++++
> drivers/hwtracing/coresight/coresight.c | 4 ++++
> 16 files changed, 70 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-dynamic-replicator.c b/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
> index f6d0571ab9dd..fc742215ab05 100644
> --- a/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-dynamic-replicator.c
> @@ -210,3 +210,7 @@ static struct amba_driver replicator_driver = {
> .id_table = replicator_ids,
> };
> builtin_amba_driver(replicator_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_DESCRIPTION("ARM Coresight Dynamic Replicator Driver");
s/ARM/Arm
s/Coresight/CoreSight
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> index 9b6c55523c58..a3dac5a8b37c 100644
> --- a/drivers/hwtracing/coresight/coresight-etb10.c
> +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> @@ -758,3 +758,8 @@ static struct amba_driver etb_driver = {
> .id_table = etb_ids,
> };
> builtin_amba_driver(etb_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Embedded Trace Buffer driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etm-cp14.c b/drivers/hwtracing/coresight/coresight-etm-cp14.c
> index 4174a8d355d2..68ca423aa088 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-cp14.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-cp14.c
> @@ -582,3 +582,7 @@ int etm_writel_cp14(u32 reg, u32 val)
>
> return 0;
> }
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_DESCRIPTION("Arm CoreSight ETM CP14 driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 677695635211..ad0ef8d27111 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -494,3 +494,7 @@ static int __init etm_perf_init(void)
> return ret;
> }
> device_initcall(etm_perf_init);
> +
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight tracer perf driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index 75487b3fad86..91a2a23143d8 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -1294,3 +1294,8 @@ const struct attribute_group *coresight_etm_groups[] = {
> &coresight_etm_mgmt_group,
> NULL,
> };
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace sysfs driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
> index 7c74263c333d..7ca73a15c735 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x.c
> @@ -935,3 +935,8 @@ static struct amba_driver etm_driver = {
> .id_table = etm_ids,
> };
> builtin_amba_driver(etm_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index a0365e23678e..577a38673444 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -2173,3 +2173,7 @@ const struct attribute_group *coresight_etmv4_groups[] = {
> &coresight_etmv4_trcidr_group,
> NULL,
> };
> +
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace v4 sysfs driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 9bc04c50d45b..ba10f5302a55 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -1073,3 +1073,8 @@ static struct amba_driver etm4x_driver = {
> .id_table = etm4_ids,
> };
> builtin_amba_driver(etm4x_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Program Flow Trace v4 driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
> index 448145a36675..1e497a75b956 100644
> --- a/drivers/hwtracing/coresight/coresight-funnel.c
> +++ b/drivers/hwtracing/coresight/coresight-funnel.c
> @@ -261,3 +261,7 @@ static struct amba_driver funnel_driver = {
> .id_table = funnel_ids,
> };
> builtin_amba_driver(funnel_driver);
> +
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("ARM Coresight Funnel Driver");
s/ARM/Arm
s/Coresight/CoreSight
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
> index 8d2eaaab6c2f..9ef539893eaa 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -154,3 +154,8 @@ static struct platform_driver replicator_driver = {
> },
> };
> builtin_platform_driver(replicator_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("ARM Coresight Replicator Driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> index c46c70aec1d5..30eae52a8757 100644
> --- a/drivers/hwtracing/coresight/coresight-stm.c
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -934,3 +934,7 @@ static struct amba_driver stm_driver = {
> };
>
> builtin_amba_driver(stm_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_DESCRIPTION("Arm CoreSight System Trace Macrocell driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 61d849b11c26..94cd6c00fcc9 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -617,3 +617,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
>
> return 0;
> }
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Trace Memory Controller ETB/ETF mode driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 02f747afa2ba..e612896e92a7 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -330,3 +330,7 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
>
> return 0;
> }
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Trace Memory Controller ETR mode driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index 456f122df74f..176a5aeab20e 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -463,3 +463,7 @@ static struct amba_driver tmc_driver = {
> .id_table = tmc_ids,
> };
> builtin_amba_driver(tmc_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_DESCRIPTION("Arm CoreSight Trace Memory Controller driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
> index 01b7457fe8fc..f3b154e150b3 100644
> --- a/drivers/hwtracing/coresight/coresight-tpiu.c
> +++ b/drivers/hwtracing/coresight/coresight-tpiu.c
> @@ -218,3 +218,8 @@ static struct amba_driver tpiu_driver = {
> .id_table = tpiu_ids,
> };
> builtin_amba_driver(tpiu_driver);
> +
> +MODULE_AUTHOR("Pratik Patel <pratikp@codeaurora.org>");
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight TPIU (Trace Port Interface Unit) driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 0cbc2948defc..406899f316e4 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -1041,3 +1041,7 @@ void coresight_unregister(struct coresight_device *csdev)
> device_unregister(&csdev->dev);
> }
> EXPORT_SYMBOL_GPL(coresight_unregister);
> +
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("ARM Coresight Driver");
s/ARM/Arm
s/Coresight/CoreSight
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v2 1/3] input: touchscreen: edt-ft5x06: don't make device a wakeup source by default
From: Rob Herring @ 2018-05-22 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517090552.5704-2-daniel@zonque.org>
On Thu, May 17, 2018 at 11:05:50AM +0200, Daniel Mack wrote:
> Allow configuring the device as wakeup source through device properties, as
> not all platforms want to wake up on touch screen activity.
>
> The I2C core automatically reads the "wakeup-source" DT property to
> configure a device's wakeup capability, and board supports files can set
> I2C_CLIENT_WAKE in the flags.
This will break wake-up on working systems. Looks like mostly i.MX, but
there's one AM437x board. If that board doesn't care, then it is up to
Shawn.
Rob
^ permalink raw reply
* [PATCH 08/14] ARM: spectre-v2: harden user aborts in kernel space
From: Russell King - ARM Linux @ 2018-05-22 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e52b3541-7106-a6dc-5851-01b091bec38f@arm.com>
On Tue, May 22, 2018 at 06:15:02PM +0100, Marc Zyngier wrote:
> On 21/05/18 12:45, Russell King wrote:
> > In order to prevent aliasing attacks on the branch predictor,
> > invalidate the BTB or instruction cache on CPUs that are known to be
> > affected when taking an abort on a address that is outside of a user
> > task limit:
> >
> > Cortex A8, A9, A12, A17, A73, A75: flush BTB.
> > Cortex A15, Brahma B15: invalidate icache.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > ---
> > arch/arm/include/asm/cp15.h | 3 +++
> > arch/arm/include/asm/system_misc.h | 8 ++++++
> > arch/arm/mm/fault.c | 3 +++
> > arch/arm/mm/proc-v7-bugs.c | 51 ++++++++++++++++++++++++++++++++++++++
> > arch/arm/mm/proc-v7.S | 8 +++---
> > 5 files changed, 70 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> > index 4c9fa72b59f5..07e27f212dc7 100644
> > --- a/arch/arm/include/asm/cp15.h
> > +++ b/arch/arm/include/asm/cp15.h
> > @@ -65,6 +65,9 @@
> > #define __write_sysreg(v, r, w, c, t) asm volatile(w " " c : : "r" ((t)(v)))
> > #define write_sysreg(v, ...) __write_sysreg(v, __VA_ARGS__)
> >
> > +#define BPIALL __ACCESS_CP15(c7, 0, c5, 6)
> > +#define ICIALLU __ACCESS_CP15(c7, 0, c5, 0)
> > +
> > extern unsigned long cr_alignment; /* defined in entry-armv.S */
> >
> > static inline unsigned long get_cr(void)
> > diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
> > index 78f6db114faf..3cfe010c5734 100644
> > --- a/arch/arm/include/asm/system_misc.h
> > +++ b/arch/arm/include/asm/system_misc.h
> > @@ -15,6 +15,14 @@ void soft_restart(unsigned long);
> > extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
> > extern void (*arm_pm_idle)(void);
> >
> > +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > +extern void (*harden_branch_predictor)(void);
> > +#define harden_branch_predictor() \
> > + do { if (harden_branch_predictor) harden_branch_predictor(); } while (0)
> > +#else
> > +#define harden_branch_predictor() do { } while (0)
> > +#endif
> > +
> > #define UDBG_UNDEFINED (1 << 0)
> > #define UDBG_SYSCALL (1 << 1)
> > #define UDBG_BADABORT (1 << 2)
> > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> > index b75eada23d0a..3b1ba003c4f9 100644
> > --- a/arch/arm/mm/fault.c
> > +++ b/arch/arm/mm/fault.c
> > @@ -163,6 +163,9 @@ __do_user_fault(struct task_struct *tsk, unsigned long addr,
> > {
> > struct siginfo si;
> >
> > + if (addr > TASK_SIZE)
> > + harden_branch_predictor();
> > +
> > #ifdef CONFIG_DEBUG_USER
> > if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
> > ((user_debug & UDBG_BUS) && (sig == SIGBUS))) {
> > diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
> > index a32ce13479d9..65a9b8141f86 100644
> > --- a/arch/arm/mm/proc-v7-bugs.c
> > +++ b/arch/arm/mm/proc-v7-bugs.c
> > @@ -2,6 +2,12 @@
> > #include <linux/kernel.h>
> > #include <linux/smp.h>
> >
> > +#include <asm/cp15.h>
> > +#include <asm/cputype.h>
> > +#include <asm/system_misc.h>
> > +
> > +void cpu_v7_bugs_init(void);
> > +
> > static __maybe_unused void cpu_v7_check_auxcr_set(u32 mask, const char *msg)
> > {
> > u32 aux_cr;
> > @@ -21,9 +27,54 @@ static void check_spectre_auxcr(u32 bit)
> > void cpu_v7_ca8_ibe(void)
> > {
> > check_spectre_auxcr(BIT(6));
> > + cpu_v7_bugs_init();
> > }
> >
> > void cpu_v7_ca15_ibe(void)
> > {
> > check_spectre_auxcr(BIT(0));
> > + cpu_v7_bugs_init();
> > +}
> > +
> > +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > +void (*harden_branch_predictor)(void);
> > +
> > +static void harden_branch_predictor_bpiall(void)
> > +{
> > + write_sysreg(0, BPIALL);
> > +}
> > +
> > +static void harden_branch_predictor_iciallu(void)
> > +{
> > + write_sysreg(0, ICIALLU);
> > +}
> > +
> > +void cpu_v7_bugs_init(void)
> > +{
> > + const char *spectre_v2_method = NULL;
> > +
> > + if (harden_branch_predictor)
> > + return;
>
> How does it work on a big-little systems where two CPUs have diverging
> mitigation methods? Let's say an hypothetical A15/A17 system? Or even a
> more common A15/A7 system, where the small core doesn't require the
> mitigation?
Hmm, I'd forgotten about those, because I don't have them.
We don't have the ability to mitigate this on such systems at all at
present, it would require a per-CPU cpu_switch_mm() implementation, and
the code has no structure to support that at present without considerable
rewrite of the CPU glue support.
I'm not even sure it could without checking deeper - I think there's some
situations where we call this before we're sufficiently setup.
I'll drop this series from the for-next branch, I suspect it won't be
making this merge window as a result, sorry.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH V2 2/3] clk: imx7d: correct enet clock CCGR registers
From: Rob Herring @ 2018-05-22 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526605266-18464-2-git-send-email-Anson.Huang@nxp.com>
On Fri, May 18, 2018 at 09:01:05AM +0800, Anson Huang wrote:
> Correct enet clock gates as below:
>
> CCGR6: IMX7D_ENET_AXI_ROOT_CLK (enet1 and enet2 bus clocks)
> CCGR112: IMX7D_ENET1_TIME_ROOT_CLK, IMX7D_ENET1_IPG_ROOT_CLK
> CCGR113: IMX7D_ENET2_TIME_ROOT_CLK, IMX7D_ENET2_IPG_ROOT_CLK
>
> Just rename unused IMX7D_ENETx_REF_ROOT_CLK for
> IMX7D_ENETx_IPG_ROOT_CLK instead of adding new clocks.
>
> Based on Andy Duan's patch from the NXP kernel tree.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> drivers/clk/imx/clk-imx7d.c | 10 ++++++----
> include/dt-bindings/clock/imx7d-clock.h | 4 ++--
Acked-by: Rob Herring <robh@kernel.org>
> 2 files changed, 8 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Russell King - ARM Linux @ 2018-05-22 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35edb3df-fed4-b6e6-be0c-ee758618c92e@arm.com>
On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
> On 21/05/18 12:45, Russell King wrote:
> > Add PSCI based hardening for cores that require more complex handling in
> > firmware.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> > arch/arm/mm/proc-v7-bugs.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++
> > arch/arm/mm/proc-v7.S | 21 +++++++++++++++++++
> > 2 files changed, 71 insertions(+)
> >
> > diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
> > index 65a9b8141f86..0c37e6a2830d 100644
> > --- a/arch/arm/mm/proc-v7-bugs.c
> > +++ b/arch/arm/mm/proc-v7-bugs.c
> > @@ -1,9 +1,12 @@
> > // SPDX-License-Identifier: GPL-2.0
> > +#include <linux/arm-smccc.h>
> > #include <linux/kernel.h>
> > +#include <linux/psci.h>
> > #include <linux/smp.h>
> >
> > #include <asm/cp15.h>
> > #include <asm/cputype.h>
> > +#include <asm/proc-fns.h>
> > #include <asm/system_misc.h>
> >
> > void cpu_v7_bugs_init(void);
> > @@ -39,6 +42,9 @@ void cpu_v7_ca15_ibe(void)
> > #ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > void (*harden_branch_predictor)(void);
> >
> > +extern void cpu_v7_smc_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm);
> > +extern void cpu_v7_hvc_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm);
> > +
> > static void harden_branch_predictor_bpiall(void)
> > {
> > write_sysreg(0, BPIALL);
> > @@ -49,6 +55,18 @@ static void harden_branch_predictor_iciallu(void)
> > write_sysreg(0, ICIALLU);
> > }
> >
> > +#ifdef CONFIG_ARM_PSCI
> > +static void call_smc_arch_workaround_1(void)
> > +{
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
> > +}
> > +
> > +static void call_hvc_arch_workaround_1(void)
> > +{
> > + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
> > +}
> > +#endif
> > +
> > void cpu_v7_bugs_init(void)
> > {
> > const char *spectre_v2_method = NULL;
> > @@ -73,6 +91,38 @@ void cpu_v7_bugs_init(void)
> > spectre_v2_method = "ICIALLU";
> > break;
> > }
> > +
> > +#ifdef CONFIG_ARM_PSCI
> > + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
> > + struct arm_smccc_res res;
> > +
> > + switch (psci_ops.conduit) {
> > + case PSCI_CONDUIT_HVC:
> > + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> > + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> > + if ((int)res.a0 < 0)
> > + break;
>
> I just realised that there is a small, but significant difference
> between this and the arm64 version: On arm64, we have a table of
> vulnerable implementations, and we try the mitigation on a per-cpu
> basis. Here, you entirely rely on the firmware to discover whether the
> CPU needs mitigation or not. You then need to check for a return value
> of 1, which indicates that although the mitigation is implemented, it is
> not required on this particular CPU.
>
> But that's probably moot if you don't support BL systems.
>
> > + harden_branch_predictor = call_hvc_arch_workaround_1;
> > + processor.switch_mm = cpu_v7_hvc_switch_mm;
> > + spectre_v2_method = "hypervisor";
> > + break;
> > +
> > + case PSCI_CONDUIT_SMC:
> > + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> > + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> > + if ((int)res.a0 < 0)
> > + break;
> > + harden_branch_predictor = call_smc_arch_workaround_1;
> > + processor.switch_mm = cpu_v7_smc_switch_mm;
> > + spectre_v2_method = "firmware PSCI";
>
> My previous remark still stands: this is not really PSCI.
Sorry, no. Your comment was for the HVC call, not the SMC. You said
nothing about this one.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v7 0/9] Add support for SAMA5D2 touchscreen
From: Jonathan Cameron @ 2018-05-22 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526975559-18966-1-git-send-email-eugen.hristev@microchip.com>
On Tue, 22 May 2018 10:52:30 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:
> Hello,
>
> This patch series is a rework of my previous series named:
> [PATCH 00/14] iio: triggers: add consumer support
>
> This is the version 7 of the series, and addresses the received feedback
> on the v2 series named:
> [PATCH v2 00/10] Add support for SAMA5D2 touchscreen
> and the v3 series named
> [PATCH v3 00/11] Add support for SAMA5D2 touchscreen
> and the v4 series named
> [PATCH v4 0/9] Add support for SAMA5D2 touchscreen
> and fixes one bug found in series named
> [PATCH v5 0/9] Add support for SAMA5D2 touchscreen
> and addresses comments in series named
> [PATCH v6 0/9] Add support for SAMA5D2 touchscreen
>
> This series applies on top of fixes-togreg branch of iio.git,
> specifically on top of commit:
> "f0c8d1f" : iio: adc: at91-sama5d2_adc:
> fix channel configuration for differential channels
>
> Jonathan, if you need me to rebase this on top of testing, let me know.
>
> Changes in previous versions are presented at the end of the cover letter below.
> Thanks everyone for the feedback. Below is the original v2 cover letter:
>
> In few words, this is the implementation of splitting the functionality
> of the IP block ADC device in SAMA5D2 SoC from ADC with touchscreen
> support. In order to avoid having a MFD device, two separate
> drivers that would work on same register base and split the IRQ,etc,
> as advised on the mailing list, I created a consumer driver for the
> channels, that will connect to the ADC as described in the device tree.
>
> I have collected feedback from everyone and here is the result:
> I have added a new generic resistive touchscreen driver, which acts
> as a iio consumer for the given channels and will create an input
> device and report the events. It uses a callback buffer to register
> to the IIO device and waits for data to be pushed.
> Inside the IIO device, I have kept a similar approach with the first version
> of the series, except that now the driver can take multiple buffers, and
> will configure the touchscreen part of the hardware device if the specific
> channels are requested.
>
> The SAMA5D2 ADC driver registers three new channels: two for the
> position on the X and Y axis, and one for the touch pressure.
> When channels are requested, it will check if the touchscreen channel mask
> includes the requested channels (it is possible that the consumer driver
> will not request pressure for example). If it's the case, it will work
> in touchscreen mode, and will refuse to do usual analog-digital conversion,
> because we have a single trigger and the touchscreen needs it.
> When the scan mask will include only old channels, the driver will function
> in the same way as before. If the scan mask somehow is a mix of the two (the
> masks intersect), the driver will refuse to work whatsoever (cannot have both
> in the same time).
> The driver allows reading raw data for the new channels, if claim direct
> mode works: no touchscreen driver requested anything. The new channels can
> act like the old ones. However, when requesting these channels, the usual
> trigger will not work and will not be enabled. The touchscreen channels
> require special trigger and irq configuration: pen detect, no pen detect
> and a periodic trigger to sample the touchscreen position and pressure.
> If the user attempts to use another trigger while there is a buffer
> that already requested the touchscreen channels (thus the trigger), the
> driver will refuse to comply.
>
> In order to have defines for the channel numbers, I added a bindings include
> file that goes on a separate commit :
> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info
> This should go in the same tree with the following commits :
> ARM: dts: at91: sama5d2: add channel cells for ADC device
> ARM: dts: at91: sama5d2: Add resistive touch device
>
> as build will break because these commits depend on the binding one
> which creates the included header file.
> V5 update: After discussing with Alexandre Belloni on Mailing list, the two
> DTS patches are to be taken in the next version after bindings reach mainline.
>
> Changes in v7:
> - Addressed some feedback from Dmitry, explained in input driver patch
> changelog.
> - Added Acked-by Dmitry.
>
> Changes in v6:
> - Fixed a crash in ADC driver , explained in driver patch changelog.
> - changed a dev_err to dev_dbg in input driver.
> - added Reviewed-by Rob Herring.
>
> Changes in v5:
> - renamed property touchscreen-threshold-pressure to touchscreen-min-pressure
> - added one return in touchscreen driver
>
> Changes in v4:
> - removed patch for inkern module get/set kref
> - addressed feedback on both the ADC and the touchscreen driver. each
> patch has a history inside the patch file for the specific changes.
> - patch that fixes the channel fix
> [PATCH v3 01/11] iio: adc: at91-sama5d2_adc:
> fix channel configuration for differential channels
> was accepted in fixes-togreg branch thus removed from this series.
> - added Reviewed-by for the bindings by Rob Herring
>
> Changes in v3:
> - changed input driver name according to feedback and reworked in commits
> to adapt to binding changes and new name.
> - moved channel index fix in at91-sama5d2_adc at the beginning of the series
> (PATCH 01/11)
> - created a new optional binding for the touchscreen as a separate commit
> and added it to the series :
> [PATCH v3 04/11] dt-bindings: input: touchscreen: add pressure
> threshold touchscreen property
> - changed at91-sama5d2_adc driver patch to address the comments. Exact changes
> are in the patch file for the driver source file.
>
> Eugen Hristev (9):
> MAINTAINERS: add generic resistive touchscreen adc
> iio: Add channel for Position Relative
> dt-bindings: input: touchscreen: add minimum pressure touchscreen
> property
> dt-bindings: input: touchscreen: resistive-adc-touch: create bindings
> iio: adc: at91-sama5d2_adc: add support for position and pressure
> channels
> input: touchscreen: resistive-adc-touch: add generic resistive ADC
> touchscreen
> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer
> info
> ARM: dts: at91: sama5d2: add channel cells for ADC device
> ARM: dts: at91: sama5d2: Add resistive touch device
>
> Documentation/ABI/testing/sysfs-bus-iio | 12 +
> .../bindings/iio/adc/at91-sama5d2_adc.txt | 9 +
> .../input/touchscreen/resistive-adc-touch.txt | 30 +
> .../bindings/input/touchscreen/touchscreen.txt | 3 +
> MAINTAINERS | 6 +
> arch/arm/boot/dts/sama5d2.dtsi | 12 +
> drivers/iio/adc/at91-sama5d2_adc.c | 609 +++++++++++++++++++--
> drivers/iio/industrialio-core.c | 1 +
> drivers/input/touchscreen/Kconfig | 13 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/resistive-adc-touch.c | 204 +++++++
> include/dt-bindings/iio/adc/at91-sama5d2_adc.h | 16 +
> include/uapi/linux/iio/types.h | 1 +
> tools/iio/iio_event_monitor.c | 2 +
> 14 files changed, 861 insertions(+), 58 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> create mode 100644 drivers/input/touchscreen/resistive-adc-touch.c
> create mode 100644 include/dt-bindings/iio/adc/at91-sama5d2_adc.h
>
Hi All,
I'm happy to take this, but there is a slight issue that we have a fix working
it's way in which this is dependent on.
I'll see if we can get this sorted before the merge window, but we may be
cutting it fine.
Jonathan
^ permalink raw reply
* [PATCH] PCI/portdrv: do not disable device on remove()
From: Sinan Kaya @ 2018-05-22 17:58 UTC (permalink / raw)
To: linux-arm-kernel
'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during
shutdown")' has been added to kernel to shutdown pending PCIe port
service interrupts during reboot so that a newly started kexec kernel
wouldn't observe pending interrupts.
pcie_port_device_remove() is disabling the root port and switches by
calling pci_disable_device() after all PCIe service drivers are shutdown.
pci_disable_device() has a much wider impact then port service itself and
it prevents all inbound transactions to reach to the system and impacts
the entire PCI traffic behind the bridge.
Issue is that pcie_port_device_remove() doesn't maintain any coordination
with the rest of the PCI device drivers in the system before clearing the
bus master bit.
This has been found to cause crashes on HP DL360 Gen9 machines during
reboot. Besides, kexec is already clearing the bus master bit in
pci_device_shutdown() after all PCI drivers are removed.
Just remove the extra clear here.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
Cc: stable at vger.kernel.org
Reported-by: Ryan Finnie <ryan@finnie.org>
---
drivers/pci/pcie/portdrv_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index c9c0663..d22a95d 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -409,7 +409,6 @@ void pcie_port_device_remove(struct pci_dev *dev)
{
device_for_each_child(&dev->dev, NULL, remove_iter);
pci_free_irq_vectors(dev);
- pci_disable_device(dev);
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Andrey Konovalov @ 2018-05-22 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86k1rzc4ba.wl-marc.zyngier@arm.com>
On Sat, May 19, 2018 at 12:44 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> That would definitely be the right thing to do. Make sure you (or
> Andrey tests with the latest released mainline kernel (4.16 for now)
> or (even better) the tip of Linus' tree.
Hi!
I can confirm that after applying this patch onto 4.17-rc4 kernel the
Odroid C2 board that I have boots (it doesn't without the patch).
This is the result of running KVM tests that I was able to find [1]:
root at odroid64:/home/odroid/kvm-unit-tests# ./run_tests.sh
PASS selftest-setup (2 tests)
PASS selftest-vectors-kernel (2 tests)
PASS selftest-vectors-user (2 tests)
PASS selftest-smp (5 tests)
PASS pci-test (1 tests)
FAIL pmu (3 tests, 3 unexpected failures)
PASS gicv2-ipi (3 tests)
SKIP gicv3-ipi (qemu-system-aarch64: Initialization of device
kvm-arm-gicv3 failed: error creating in-kernel VGIC: No such device)
PASS gicv2-active (1 tests)
SKIP gicv3-active (qemu-system-aarch64: Initialization of device
kvm-arm-gicv3 failed: error creating in-kernel VGIC: No such device)
PASS psci (4 tests)
PASS timer (8 tests)
Here is the result of running the same tests on GCC compiled kernel
(looks the same):
root at odroid64:/home/odroid/kvm-unit-tests# ./run_tests.sh
PASS selftest-setup (2 tests)
PASS selftest-vectors-kernel (2 tests)
PASS selftest-vectors-user (2 tests)
PASS selftest-smp (5 tests)
PASS pci-test (1 tests)
FAIL pmu (3 tests, 3 unexpected failures)
PASS gicv2-ipi (3 tests)
SKIP gicv3-ipi (qemu-system-aarch64: Initialization of device
kvm-arm-gicv3 failed: error creating in-kernel VGIC: No such device)
PASS gicv2-active (1 tests)
SKIP gicv3-active (qemu-system-aarch64: Initialization of device
kvm-arm-gicv3 failed: error creating in-kernel VGIC: No such device)
PASS psci (4 tests)
PASS timer (8 tests)
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Thanks!
[1] https://www.linux-kvm.org/page/KVM-unit-tests
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Rob Herring @ 2018-05-22 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526615528-9707-2-git-send-email-djw@t-chip.com.cn>
On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> which do not belong to the general pinctrl.
>
> Adding gpio-syscon support makes controlling regulator or
> LED using these special pins very easy by reusing existing
> drivers, such as gpio-regulator and led-gpio.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v2:
> - Rename gpio_syscon10 to gpio_mute in doc
>
> Changes in v1:
> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> - Add doc rockchip,gpio-syscon.txt
>
> .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
> drivers/gpio/gpio-syscon.c | 30 ++++++++++++++++
> 2 files changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> new file mode 100644
> index 0000000..b1b2a67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> @@ -0,0 +1,41 @@
> +* Rockchip GPIO support for GRF_SOC_CON registers
> +
> +Required properties:
> +- compatible: Should contain "rockchip,gpio-syscon".
> +- gpio-controller: Marks the device node as a gpio controller.
> +- #gpio-cells: Should be two. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = Active high,
> + 1 = Active low.
There's no need for this child node. Just make the parent node a gpio
controller.
Rob
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-22 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <959d826d-1a98-ca22-acee-a4548427fcd3@microchip.com>
On 2018-04-11 17:34, Nicolas Ferre wrote:
> On 11/04/2018 at 16:44, Peter Rosin wrote:
>> Hi Nicolas,
>>
>> Boris asked for your input on this (the datasheet difference appears to
>> have no bearing on the issue) elsewhere in the tree of messages. It's
>> now been a week or so and I'm starting to wonder if you missed this
>> altogether or if you are simply out of office or something?
>
> Hi Peter,
>
> I didn't dig into this issue with matrix datasheet reset values and your
> findings below. I'll try to move forward with your detailed explanation
> and with my contacts within the "product" team internally.
Hi again, just checking in to see if there is any progress? If not, maybe
it's time to just take the patch as-is, warts and imperfections included,
and even if we all hate it. But what to do...
Cheers,
Peter
^ 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