* [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 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 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 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 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 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
* [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
* [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 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 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 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 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
* [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 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
* [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 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 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 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 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] 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
* 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 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
* [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Krzysztof Kozlowski @ 2016-11-03 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478151727-20250-6-git-send-email-anurup.m@huawei.com>
On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
> 1) Device tree bindings for Hisilicon SoC PMU.
> 2) Add example for Hisilicon L3 cache, MN and DDRC PMU.
Get rid of this weird indentation in all patches.
>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
> ---
> .../devicetree/bindings/arm/hisilicon/pmu.txt | 127 +++++++++++++++++++++
> 1 file changed, 127 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 0000000..e7b35e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,127 @@
> +Hisilicon SoC hip05/06/07 ARMv8 PMU
> +===================================
> +
> +The Hisilicon SoC chips like hip05/06/07 etc. consist of varous independent
> +system device PMU's such as L3 cache (L3C), Miscellaneous Nodes(MN) and DDR
> +comtroller. These PMU devices are independent and have hardware logic to
> +gather statistics and performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO die's. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
> +e.g. In the case of hip05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
> +
> +The Hisilicon SoC PMU DT node bindigs for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die(SCCL).
> +
> +For uncore PMU devices there are some common required properties as detailed
> +below.
> +
> +Required properties:
> + - compatible : This field contain two values. The first value is
> + always "hisilicon" and second value is the Module type as shown
> + in below examples:
Over-complicated sentence. Just:
- compatible : One of:
"hisilicon,hisi-pmu-l3c-v1" for Hisilicon SoC L3C PMU
device (Version 1)
...
...
BTW, No need of CC-ing me. I am not a maintainer of relevant subsystems.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Nipun Gupta @ 2016-11-03 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05d13b82-6fb6-95c0-8e64-54bcf57b3221@arm.com>
Hi Robin,
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Thursday, November 03, 2016 16:39
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; linux-arm-
> kernel at lists.infradead.org; iommu at lists.linux-foundation.org
> Cc: Stuart Yoder <stuart.yoder@nxp.com>
> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> caching of bypass entries
>
> On 02/11/16 19:26, Nipun Gupta wrote:
> >
> > Hi Robin,
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy at arm.com]
> >> Sent: Wednesday, November 02, 2016 16:51
> >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; linux-arm-
> >> kernel at lists.infradead.org; iommu at lists.linux-foundation.org
> >> Cc: Stuart Yoder <stuart.yoder@nxp.com>
> >> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to
> enable
> >> caching of bypass entries
> >>
> >> Hi Nipun,
> >>
> >> On 02/11/16 13:35, Nipun Gupta wrote:
> >>> The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR)
> >>> provides an option to enable the updation of TLB in case of bypass
> >>> transactions due to no stream match in the stream match table. This
> >>> reduces the latencies of the subsequent transactions with the same stream-
> id
> >> which bypasses the SMMU.
> >>> This provides a significant performance benefit for certain networking
> >>> workloads.
> >>
> >> ...at the cost of increased TLB contention against other workloads.
> >> However, in the general case we'd expect the system to be fully described, so
> if
> >> there aren't any unmatched Stream IDs there hopefully shouldn't be an
> impact
> >> to leaving this switched on. I'd be interested to see some actual performance
> >> numbers, though - you already know my opinion about unsubstantiated
> quotes
> >> from the MMU-500 TRM.
> >
> > With this change we have seen substantial performance improvement of ~9-
> 10%
> > with DPDK l3fwd application
> (http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
> > on NXP's LS2088a platform (single core as well as multi-core). Also, with ODP
> reflector application
> > (loopback mode - NXP in-house) we have seen 5% improvement in
> performance on
> > LS1088 platform.
> >
> > W.r.t. the read latencies, they are reduced to avg. ~50 platform cycles from
> avg. ~140
> > platform cycles per memory read transactions which follow this bypass path
> (on LS2088
> > with DPDK l3fwd application).
> >
> > (Apologies, I cannot share the DPDK/ODP exact performance numbers on the
> mailing list).
>
> That's understandable, and I'm not sure I'd know how to interpret them
> anyway ;) I reckon the percentages make a sufficiently compelling
> qualification of the improvement, so it would be good to have that
> summarised in the commit log.
Sure, I'll add a part of it in the commit log.
>
> >>
> >>> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> >>> ---
> >>> drivers/iommu/arm-smmu.c | 21 +++++++++++++++------
> >>> 1 file changed, 15 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> >>> ce2a9d4..7010a5c 100644
> >>> --- a/drivers/iommu/arm-smmu.c
> >>> +++ b/drivers/iommu/arm-smmu.c
> >>> @@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
> >>>
> >>> #define ARM_MMU500_ACTLR_CPRE (1 << 1)
> >>>
> >>> +#define ACR_SMTNMB_TLBEN (1 << 8)
> >>
> >> ACR is entirely implementation-defined, so there are no generic field names.
> >> Please follow the naming convention handily demonstrated in the subsequent
> >> context line.
> >>
> >>> #define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
> >>
> >> Actually, can we also please keep these in descending order of bit position
> like
> >> everything else?
> >>
> >>> #define CB_PAR_F (1 << 0)
> >>> @@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct
> >> arm_smmu_device *smmu)
> >>> for (i = 0; i < smmu->num_mapping_groups; ++i)
> >>> arm_smmu_write_sme(smmu, i);
> >>>
> >>> + /* Get the major rev required for configuring ACR */
> >>
> >> That comment is nonsense.
> >>
> >>> + reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> >>> + major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> >>> +
> >>> /*
> >>> * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> >>> * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> >>> * bit is only present in MMU-500r2 onwards.
> >>> */
> >>> - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> >>> - major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> >>> - if ((smmu->model == ARM_MMU500) && (major >= 2)) {
> >>> - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> >>> + reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> >>> + if ((smmu->model == ARM_MMU500) && (major >= 2))
> >>> reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> >>> - writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> >>> - }
> >>> +
> >>> + /*
> >>> + * Set the SMTNMB_TLBEN in ACR so that the transactions which
> >>> + * bypass with SMMU due to no stream match found in the SMR table
> >>> + * are updated in the TLB's.
> >>
> >> Or simply, e.g. "Allow unmatched Stream IDs to allocate bypass TLB entries
> for
> >> reduced latency". It's already clear from the code what bit's being set where,
> we
> >> only need to remember *why*.
> >>
> >>> + */
> >>> + reg |= ACR_SMTNMB_TLBEN;
> >>> + writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> >>
> >> Are you sure it's perfectly fine to set that implementation-defined bit on any
> >> SMMU implementation other than the two-and-a-half ARM Ltd. ones which
> >> happen to share the same meaning? I'm certainly not.
> >>
> >> The correct flow would be something like this:
> >>
> >> if (smmu->model == ARM_MMU500) {
> >> reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> >> major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> >> reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> >> if (major >= 2)
> >> reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> >> reg |= ACR_SMTNMB_TLBEN;
> >> writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> >> }
> >>
> >> The shape of the current code avoids an extra level of indentation, but once
> you
> >> have to have the nested conditional anyway, it might as well all be predicated
> >> appropriately.
> >>
> >
> > Thank you for providing the useful comments. I would incorporate them all in
> next version :).
>
> Cool. Just for clarity (I realise I was thinking it, but never said it
> outright), whilst MMU-40x do share the same feature with the same ACR
> bit definition as MMU-500, I'd be inclined not to bother with them.
> Since the monolithic microarchitecture means there's normally a separate
> MMU-40x per device, if you don't want translation for that device you
> can simply not probe the thing to turn it on in the first place.
>
This seems a pretty decent reason to have this bit set only for MMU-500.
I'll send a patch v2 soon.
Thanks,
Nipun
> Robin.
>
> >
> > Regards,
> > Nipun
> >
> >> Robin.
> >>
> >>> /* Make sure all context banks are disabled and clear CB_FSR */
> >>> for (i = 0; i < smmu->num_context_banks; ++i) {
> >>>
> >
^ permalink raw reply
* [PATCH v2 3/3] reset: Add the TI SCI reset driver
From: Andrew F. Davis @ 2016-11-03 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477647364.3010.28.camel@pengutronix.de>
On 10/28/2016 04:36 AM, Philipp Zabel wrote:
> Hi Andrew,
>
> is there (going to be) as stable branch I can base these on, or should I
> just wait until the prerequisite patches appear in arm-soc/for-next?
>
> Am Donnerstag, den 27.10.2016, 16:49 -0500 schrieb Andrew F. Davis:
>> Some TI Keystone family of SoCs contain a system controller (like the
>> Power Management Micro Controller (PMMC) on K2G SoCs) that manage the
>> low-level device control (like clocks, resets etc) for the various
>> hardware modules present on the SoC. These device control operations
>> are provided to the host processor OS through a communication protocol
>> called the TI System Control Interface (TI SCI) protocol.
>>
>> This patch adds a reset driver that communicates to the system
>> controller over the TI SCI protocol for performing reset management
>> of various devices present on the SoC. Various reset functionalities
>> are achieved by the means of different TI SCI device operations
>> provided by the TI SCI framework.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> [s-anna at ti.com: documentation changes, revised commit message]
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> MAINTAINERS | 1 +
>> drivers/reset/Kconfig | 9 ++
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-ti-sci.c | 262 +++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 273 insertions(+)
>> create mode 100644 drivers/reset/reset-ti-sci.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index accf991..b93d91a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11901,6 +11901,7 @@ F: include/dt-bindings/clock/k2g.h
>> F: drivers/clk/keystone/sci-clk.c
>> F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>> F: include/dt-bindings/reset/k2g.h
>> +F: drivers/reset/reset-ti-sci.c
>>
>> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
>> M: Hans Verkuil <hverkuil@xs4all.nl>
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>> index 06d9fa2..4c21c9d 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -66,6 +66,15 @@ config RESET_SUNXI
>> help
>> This enables the reset driver for Allwinner SoCs.
>>
>> +config RESET_TI_SCI
>> + tristate "TI System Control Interface (TI-SCI) reset driver"
>> + depends on RESET_CONTROLLER
>> + depends on TI_SCI_PROTOCOL
>> + help
>> + This enables the reset driver support over TI System Control Interface
>> + available on some new TI SoCs. If you wish to use reset resources
>> + managed by the TI System Controller, say Y here. Otherwise, say N.
>> +
>> config TI_SYSCON_RESET
>> tristate "TI SYSCON Reset Driver"
>> depends on HAS_IOMEM
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index bbe7026..36321f2 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
>> obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
>> obj-$(CONFIG_RESET_STM32) += reset-stm32.o
>> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
>> +obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
>> obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
>> obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
>> obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
>> diff --git a/drivers/reset/reset-ti-sci.c b/drivers/reset/reset-ti-sci.c
>> new file mode 100644
>> index 0000000..42ccf12
>> --- /dev/null
>> +++ b/drivers/reset/reset-ti-sci.c
>> @@ -0,0 +1,262 @@
>> +/*
>> + * Texas Instrument's System Control Interface (TI-SCI) reset driver
>> + *
>> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
>> + * Andrew F. Davis <afd@ti.com>
>> + *
>> + * 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 "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/idr.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset-controller.h>
>> +#include <linux/soc/ti/ti_sci_protocol.h>
>> +
>> +/**
>> + * struct ti_sci_reset_control - reset control structure
>> + * @dev_id: SoC-specific device identifier
>> + * @reset_mask: reset mask to use for toggling reset
>> + */
>> +struct ti_sci_reset_control {
>> + u32 dev_id;
>> + u32 reset_mask;
>> +};
>> +
>> +/**
>> + * struct ti_sci_reset_data - reset controller information structure
>> + * @rcdev: reset controller entity
>> + * @dev: reset controller device pointer
>> + * @sci: TI SCI handle used for communication with system controller
>> + * @idr: idr structure for mapping ids to reset control structures
>> + */
>> +struct ti_sci_reset_data {
>> + struct reset_controller_dev rcdev;
>> + struct device *dev;
>> + const struct ti_sci_handle *sci;
>> + struct idr idr;
>> +};
>> +
>> +#define to_ti_sci_reset_data(p) \
>> + container_of((p), struct ti_sci_reset_data, rcdev)
>> +
>> +/**
>> + * ti_sci_reset_set() - program a device's reset
>> + * @rcdev: reset controller entity
>> + * @id: ID of the reset to toggle
>> + * @assert: boolean flag to indicate assert or deassert
>> + *
>> + * This is a common internal function used to assert or deassert a device's
>> + * reset using the TI SCI protocol. The device's reset is asserted if the
>> + * @assert argument is true, or deasserted if @assert argument is false.
>> + * The mechanism itself is a read-modify-write procedure, the current device
>> + * reset register is read using a TI SCI device operation, the new value is
>> + * set or un-set using the reset's mask, and the new reset value written by
>> + * using another TI SCI device operation.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_set(struct reset_controller_dev *rcdev,
>> + unsigned long id, bool assert)
>> +{
>> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
>> + const struct ti_sci_handle *sci = data->sci;
>> + const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
>> + struct ti_sci_reset_control *control;
>> + u32 reset_state;
>> + int ret;
>> +
>> + control = idr_find(&data->idr, id);
>> + if (!control)
>> + return -EINVAL;
>> +
>> + ret = dev_ops->get_device_resets(sci, control->dev_id,
>> + &reset_state);
>> + if (ret)
>> + return ret;
>> +
>> + if (assert)
>> + reset_state |= control->reset_mask;
>> + else
>> + reset_state &= ~control->reset_mask;
>> +
>> + return dev_ops->set_device_resets(sci, control->dev_id,
>> + reset_state);
>
> Without any locking? Maybe the read-modify-write could just be moved one
> level down with an update_bits type of callback in the ti_sci_dev_ops.
>
That may be useful to add at some point, for now I want to work with the
existing framework, it can always be moved later. I'll add some
per-control locks for v3.
Thanks,
Andrew
>> +}
>> +
>> +/**
>> + * ti_sci_reset_assert() - assert device reset
>> + * @rcdev: reset controller entity
>> + * @id: ID of the reset to be asserted
>> + *
>> + * This function implements the reset driver op to assert a device's reset
>> + * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
>> + * with the corresponding parameters as passed in, but with the @assert
>> + * argument set to true for asserting the reset.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + return ti_sci_reset_set(rcdev, id, true);
>> +}
>> +
>> +/**
>> + * ti_sci_reset_deassert() - deassert device reset
>> + * @rcdev: reset controller entity
>> + * @id: ID of the reset to be deasserted
>> + *
>> + * This function implements the reset driver op to deassert a device's reset
>> + * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
>> + * with the corresponding parameters as passed in, but with the @assert
>> + * argument set to false for deasserting the reset.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_deassert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + return ti_sci_reset_set(rcdev, id, false);
>> +}
>> +
>> +/**
>> + * ti_sci_reset_status() - check device reset status
>> + * @rcdev: reset controller entity
>> + * @id: ID of reset to be checked
>> + *
>> + * This function implements the reset driver op to return the status of a
>> + * device's reset using the TI SCI protocol. The reset register value is read
>> + * by invoking the TI SCI device opertation .get_device_resets(), and the
>> + * status of the specific reset is extracted and returned using this reset's
>> + * reset mask.
>> + *
>> + * Return: 0 if reset is deasserted, or a non-zero value if reset is asserted
>> + */
>> +static int ti_sci_reset_status(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
>> + const struct ti_sci_handle *sci = data->sci;
>> + const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
>> + struct ti_sci_reset_control *control;
>> + u32 reset_state;
>> + int ret;
>> +
>> + control = idr_find(&data->idr, id);
>> + if (!control)
>> + return -EINVAL;
>> +
>> + ret = dev_ops->get_device_resets(sci, control->dev_id,
>> + &reset_state);
>> + if (ret)
>> + return ret;
>> +
>> + return reset_state & control->reset_mask;
>> +}
>> +
>> +static struct reset_control_ops ti_sci_reset_ops = {
>> + .assert = ti_sci_reset_assert,
>> + .deassert = ti_sci_reset_deassert,
>> + .status = ti_sci_reset_status,
>> +};
>> +
>> +/**
>> + * ti_sci_reset_of_xlate() - translate a set of OF arguments to a reset ID
>> + * @rcdev: reset controller entity
>> + * @reset_spec: OF reset argument specifier
>> + *
>> + * This function performs the translation of the reset argument specifier
>> + * values defined in a reset consumer device node. The function allocates a
>> + * reset control structure for that device reset, and will be used by the
>> + * driver for performing any reset functions on that reset. An idr structure
>> + * is allocated and used to map to the reset control structure. This idr
>> + * is used by the driver to do reset lookups.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_of_xlate(struct reset_controller_dev *rcdev,
>> + const struct of_phandle_args *reset_spec)
>> +{
>> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
>> + struct ti_sci_reset_control *control;
>> +
>> + if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
>> + return -EINVAL;
>> +
>> + control = devm_kzalloc(data->dev, sizeof(*control), GFP_KERNEL);
>> + if (!control)
>> + return -ENOMEM;
>> +
>> + control->dev_id = reset_spec->args[0];
>> + control->reset_mask = reset_spec->args[1];
>> +
>> + return idr_alloc(&data->idr, control, 0, 0, GFP_KERNEL);
>> +}
>> +
>> +static const struct of_device_id ti_sci_reset_of_match[] = {
>> + { .compatible = "ti,sci-reset", },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, ti_sci_reset_of_match);
>> +
>> +static int ti_sci_reset_probe(struct platform_device *pdev)
>> +{
>> + struct ti_sci_reset_data *data;
>> +
>> + if (!pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + data->sci = devm_ti_sci_get_handle(&pdev->dev);
>> + if (IS_ERR(data->sci))
>> + return PTR_ERR(data->sci);
>> +
>> + data->rcdev.ops = &ti_sci_reset_ops;
>> + data->rcdev.owner = THIS_MODULE;
>> + data->rcdev.of_node = pdev->dev.of_node;
>> + data->rcdev.of_reset_n_cells = 2;
>> + data->rcdev.of_xlate = ti_sci_reset_of_xlate;
>> + data->dev = &pdev->dev;
>> + idr_init(&data->idr);
>> +
>> + platform_set_drvdata(pdev, data);
>> +
>> + return reset_controller_register(&data->rcdev);
>> +}
>> +
>> +static int ti_sci_reset_remove(struct platform_device *pdev)
>> +{
>> + struct ti_sci_reset_data *data = platform_get_drvdata(pdev);
>> +
>> + reset_controller_unregister(&data->rcdev);
>> +
>> + idr_destroy(&data->idr);
>> +
>> + return 0;
>> +}
>> +
>> +static struct platform_driver ti_sci_reset_driver = {
>> + .probe = ti_sci_reset_probe,
>> + .remove = ti_sci_reset_remove,
>> + .driver = {
>> + .name = "ti-sci-reset",
>> + .of_match_table = ti_sci_reset_of_match,
>> + },
>> +};
>> +module_platform_driver(ti_sci_reset_driver);
>> +
>> +MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
>> +MODULE_DESCRIPTION("TI System Control Interface (TI SCI) Reset driver");
>> +MODULE_LICENSE("GPL v2");
>
> regards
> Philipp
>
^ 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