* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Peter Zijlstra @ 2016-10-20 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020104417.GD10234@leverpostej>
On Thu, Oct 20, 2016 at 11:44:18AM +0100, Mark Rutland wrote:
> On Thu, Oct 20, 2016 at 12:37:07PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> > > Note:
> > > I'm using perf_sw_context in difference to perf_invalid_context
> > > (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> > > add() is never called and the counter results are shown as "unsupported" by
> > > perf. With perf_sw_context everything works as expected.
> >
> > What?! All the uncore PMUs use perf_invalid_context. What doesn't work
> > for you?
>
> I think there's general confusion over the use of invalid context.
> Perhaps we could clear that up with:
>
> #define perf_uncore_context perf_invalid_context
>
> and
>
> s/perf_hw_context/perf_cpu_hw_context/
What might be missing is the fact that these are _TASK_ contexts.
New names might clarify things a little though.
^ permalink raw reply
* [PATCH 2/2] arm64/numa: fix incorrect print of end_pfn
From: Will Deacon @ 2016-10-20 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476935576-59941-2-git-send-email-guohanjun@huawei.com>
On Thu, Oct 20, 2016 at 11:52:56AM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> When booting on NUMA system with memory-less node (no
> memory dimm on this memory controller), the print
> for setup_node_data() is incorrect:
>
> NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
>
> It should be 0, not 0xffffffffffffffff as there is
> no memory on that node.
Wouldn't it make more sense to print something useful, like "memory-less
node"?
Will
^ permalink raw reply
* [PATCH 1/2] arm64/numa: fix pcpu_cpu_distance() to get correct CPU proximity
From: Will Deacon @ 2016-10-20 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476935576-59941-1-git-send-email-guohanjun@huawei.com>
On Thu, Oct 20, 2016 at 11:52:55AM +0800, Hanjun Guo wrote:
> From: Yisheng Xie <xieyisheng1@huawei.com>
>
> The pcpu_build_alloc_info() function group CPUs according to their
> proximity, by call callback function @cpu_distance_fn from different
> ARCHs.
>
> For arm64 the callback of @cpu_distance_fn is
> pcpu_cpu_distance(from, to)
> -> node_distance(from, to)
> The @from and @to for function node_distance() should be nid.
>
> However, pcpu_cpu_distance() in arch/arm64/mm/numa.c just past the
> cpu id for @from and @to.
>
> For this incorrect cpu proximity get from ARCH, it may cause each CPU
> in one group and make group_cnt out of bound:
>
> setup_per_cpu_areas()
> pcpu_embed_first_chunk()
> pcpu_build_alloc_info()
> in pcpu_build_alloc_info, since cpu_distance_fn will return
> REMOTE_DISTANCE if we pass cpu ids (0,1,2...), so
> cpu_distance_fn(cpu, tcpu) > LOCAL_DISTANCE will wrongly be ture.
>
> This may results in triggering the BUG_ON(unit != nr_units) later:
>
> [ 0.000000] kernel BUG at mm/percpu.c:1916!
> [ 0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc1-00003-g14155ca-dirty #26
> [ 0.000000] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
> [ 0.000000] task: ffff000008d6e900 task.stack: ffff000008d60000
> [ 0.000000] PC is at pcpu_embed_first_chunk+0x420/0x704
> [ 0.000000] LR is at pcpu_embed_first_chunk+0x3bc/0x704
> [ 0.000000] pc : [<ffff000008c754f4>] lr : [<ffff000008c75490>] pstate: 800000c5
> [ 0.000000] sp : ffff000008d63eb0
> [ 0.000000] x29: ffff000008d63eb0 [ 0.000000] x28: 0000000000000000
> [ 0.000000] x27: 0000000000000040 [ 0.000000] x26: ffff8413fbfcef00
> [ 0.000000] x25: 0000000000000042 [ 0.000000] x24: 0000000000000042
> [ 0.000000] x23: 0000000000001000 [ 0.000000] x22: 0000000000000046
> [ 0.000000] x21: 0000000000000001 [ 0.000000] x20: ffff000008cb3bc8
> [ 0.000000] x19: ffff8413fbfcf570 [ 0.000000] x18: 0000000000000000
> [ 0.000000] x17: ffff000008e49ae0 [ 0.000000] x16: 0000000000000003
> [ 0.000000] x15: 000000000000001e [ 0.000000] x14: 0000000000000004
> [ 0.000000] x13: 0000000000000000 [ 0.000000] x12: 000000000000006f
> [ 0.000000] x11: 00000413fbffff00 [ 0.000000] x10: 0000000000000004
> [ 0.000000] x9 : 0000000000000000 [ 0.000000] x8 : 0000000000000001
> [ 0.000000] x7 : ffff8413fbfcf63c [ 0.000000] x6 : ffff000008d65d28
> [ 0.000000] x5 : ffff000008d65e50 [ 0.000000] x4 : 0000000000000000
> [ 0.000000] x3 : ffff000008cb3cc8 [ 0.000000] x2 : 0000000000000040
> [ 0.000000] x1 : 0000000000000040 [ 0.000000] x0 : 0000000000000000
> [...]
> [ 0.000000] Call trace:
> [ 0.000000] Exception stack(0xffff000008d63ce0 to 0xffff000008d63e10)
> [ 0.000000] 3ce0: ffff8413fbfcf570 0001000000000000 ffff000008d63eb0 ffff000008c754f4
> [ 0.000000] 3d00: ffff000008d63d50 ffff0000081af210 00000413fbfff010 0000000000001000
> [ 0.000000] 3d20: ffff000008d63d50 ffff0000081af220 00000413fbfff010 0000000000001000
> [ 0.000000] 3d40: 00000413fbfcef00 0000000000000004 ffff000008d63db0 ffff0000081af390
> [ 0.000000] 3d60: 00000413fbfcef00 0000000000001000 0000000000000000 0000000000001000
> [ 0.000000] 3d80: 0000000000000000 0000000000000040 0000000000000040 ffff000008cb3cc8
> [ 0.000000] 3da0: 0000000000000000 ffff000008d65e50 ffff000008d65d28 ffff8413fbfcf63c
> [ 0.000000] 3dc0: 0000000000000001 0000000000000000 0000000000000004 00000413fbffff00
> [ 0.000000] 3de0: 000000000000006f 0000000000000000 0000000000000004 000000000000001e
> [ 0.000000] 3e00: 0000000000000003 ffff000008e49ae0
> [ 0.000000] [<ffff000008c754f4>] pcpu_embed_first_chunk+0x420/0x704
> [ 0.000000] [<ffff000008c6658c>] setup_per_cpu_areas+0x38/0xc8
> [ 0.000000] [<ffff000008c608d8>] start_kernel+0x10c/0x390
> [ 0.000000] [<ffff000008c601d8>] __primary_switched+0x5c/0x64
> [ 0.000000] Code: b8018660 17ffffd7 6b16037f 54000080 (d4210000)
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>
> Fix by getting CPUs proximity through its node. We only care about
> whether it is LOCAL_DISTANCE or not, for pcpu_build_alloc_info() only
> use this to group CPUs.
>
> Fixes: 7af3a0a99252 ("arm64/numa: support HAVE_SETUP_PER_CPU_AREA")
> Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> arch/arm64/mm/numa.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 778a985..34415fc 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -147,7 +147,10 @@ static int __init early_cpu_to_node(int cpu)
>
> static int __init pcpu_cpu_distance(unsigned int from, unsigned int to)
> {
> - return node_distance(from, to);
> + if (early_cpu_to_node(from) == early_cpu_to_node(to))
> + return LOCAL_DISTANCE;
> + else
> + return REMOTE_DISTANCE;
Why can't this be node_distance(early_cpu_to_node(from), early_cpu_to_node(to))?
Will
^ permalink raw reply
* [PATCH 4/4] ARM: at91/dt: sama5d4: Add new MA5D4EVK manufacturer compat
From: Alexandre Belloni @ 2016-10-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-4-marex@denx.de>
On 19/09/2016 at 23:40:44 +0200, Marek Vasut wrote :
> The board is now manufactured by Aries Embedded GmbH, update compat string.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 ++--
> arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Mark Rutland @ 2016-10-20 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020103707.GB3175@twins.programming.kicks-ass.net>
On Thu, Oct 20, 2016 at 12:37:07PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> > Note:
> > I'm using perf_sw_context in difference to perf_invalid_context
> > (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> > add() is never called and the counter results are shown as "unsupported" by
> > perf. With perf_sw_context everything works as expected.
>
> What?! All the uncore PMUs use perf_invalid_context. What doesn't work
> for you?
I think there's general confusion over the use of invalid context.
Perhaps we could clear that up with:
#define perf_uncore_context perf_invalid_context
and
s/perf_hw_context/perf_cpu_hw_context/
Mark.
^ permalink raw reply
* [PATCH v2] arm64: Add support for additional relocations in the kexec purgatory code
From: Catalin Marinas @ 2016-10-20 10:43 UTC (permalink / raw)
To: linux-arm-kernel
When compiling the kexec-tools with gcc6, the following additional
reolcations are generated in the purgatory.ro file:
R_AARCH64_ADR_PREL_PG_HI21
R_AARCH64_ADD_ABS_LO12_NC
R_AARCH64_LDST64_ABS_LO12_NC
This patch modifies the arm64 machine_apply_elf_rel() function to handle
these relocations.
Cc: Geoff Levand <geoff@infradead.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
Changes for v2:
- Fixed the type string to drop the "R_AARCH64_" prefix
kexec/arch/arm64/kexec-arm64.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 2e8839a..e067a23 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -550,6 +550,14 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
# define R_AARCH64_ADR_PREL_LO21 274
#endif
+#if !defined(R_AARCH64_ADR_PREL_PG_HI21)
+# define R_AARCH64_ADR_PREL_PG_HI21 275
+#endif
+
+#if !defined(R_AARCH64_ADD_ABS_LO12_NC)
+# define R_AARCH64_ADD_ABS_LO12_NC 277
+#endif
+
#if !defined(R_AARCH64_JUMP26)
# define R_AARCH64_JUMP26 282
#endif
@@ -558,10 +566,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
# define R_AARCH64_CALL26 283
#endif
+#if !defined(R_AARCH64_LDST64_ABS_LO12_NC)
+# define R_AARCH64_LDST64_ABS_LO12_NC 286
+#endif
+
uint64_t *loc64;
uint32_t *loc32;
uint64_t *location = (uint64_t *)ptr;
uint64_t data = *location;
+ uint64_t imm;
const char *type = NULL;
switch(r_type) {
@@ -585,6 +598,19 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
*loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ (((value - address) << 3) & 0xffffe0));
break;
+ case R_AARCH64_ADR_PREL_PG_HI21:
+ type = "ADR_PREL_PG_HI21";
+ imm = ((value & ~0xfff) - (address & ~0xfff)) >> 12;
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((imm & 3) << 29) + ((imm & 0x1ffffc) << (5 - 2)));
+ break;
+ case R_AARCH64_ADD_ABS_LO12_NC:
+ type = "ADD_ABS_LO12_NC";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((value & 0xfff) << 10));
+ break;
case R_AARCH64_JUMP26:
type = "JUMP26";
loc32 = ptr;
@@ -597,6 +623,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
*loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ (((value - address) >> 2) & 0x3ffffff));
break;
+ case R_AARCH64_LDST64_ABS_LO12_NC:
+ if (value & 7)
+ die("%s: ERROR Unaligned value: %lx\n", __func__,
+ value);
+ type = "LDST64_ABS_LO12_NC";
+ loc32 = ptr;
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((value & 0xff8) << (10 - 3)));
+ break;
default:
die("%s: ERROR Unknown type: %lu\n", __func__, r_type);
break;
--
2.10.0
^ permalink raw reply related
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Mark Rutland @ 2016-10-20 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476955841-27898-1-git-send-email-jglauber@cavium.com>
On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> Sorry for the long time it took for re-cooking this patch set.
> The v3 should address all of Marks previous comments, things I didn't
> change are listed below.
>
> Not changed:
> - Stick to NUMA node ID to detect the socket a device belongs to but made
> uncore depend on CONFIG_NUMA.
> - Stick to initcall for uncore framework because it is easier to do the
> scanning for the same type of PCI devices, also I don't know if the PCI layer
> would allow for several drivers to register for the same device ID.
>
> Note:
> I'm using perf_sw_context in difference to perf_invalid_context
> (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> add() is never called and the counter results are shown as "unsupported" by
> perf. With perf_sw_context everything works as expected.
I take it you were tryign to open per-task, non system-wide events?
As a shared resource, per-task events do not make sense, and thus using
perf_sw_context does not make sense.
I take it If you expose a cpumask, and open the event in system-wide
mode (passing '-a' to perf tool), things should work even if using
perf_invalid_context.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/5] Cavium ThunderX uncore PMU support
From: Peter Zijlstra @ 2016-10-20 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476955841-27898-1-git-send-email-jglauber@cavium.com>
On Thu, Oct 20, 2016 at 11:30:36AM +0200, Jan Glauber wrote:
> Note:
> I'm using perf_sw_context in difference to perf_invalid_context
> (see WARN_ON in perf_pmu_register). Reason is that with perf_invalid_context
> add() is never called and the counter results are shown as "unsupported" by
> perf. With perf_sw_context everything works as expected.
What?! All the uncore PMUs use perf_invalid_context. What doesn't work
for you?
^ permalink raw reply
* [PATCH 15/19] reset: sti: Remove STiH415/6 reset support
From: Philipp Zabel @ 2016-10-20 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9a50ba1-9932-0d71-6b61-efccee587d74@st.com>
Am Dienstag, den 11.10.2016, 09:05 +0200 schrieb Patrice Chotard:
> Hi Philipp
>
> On 09/27/2016 10:02 AM, Philipp Zabel wrote:
> > Hi Peter,
> >
> > Am Mittwoch, den 14.09.2016, 14:27 +0100 schrieb Peter Griffin:
> >> Support for STiH415/6 SoCs is being removed from the
> >> kernel because the platforms are obsolete. This patch removes
> >> the reset drivers for these SoC's.
> >>
> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >> Cc: <p.zabel@pengutronix.de>
> >> ---
>
> [...]
>
> >> - .driver = {
> >> - .name = "reset-stih416",
> >> - .of_match_table = stih416_reset_match,
> >> - },
> >> -};
> >> -
> >> -static int __init stih416_reset_init(void)
> >> -{
> >> - return platform_driver_register(&stih416_reset_driver);
> >> -}
> >> -arch_initcall(stih416_reset_init);
> >
> > Can I pick up patches 15 and 19, or are there dependencies in the
> > series?
>
> Yes, you can pick up patches 15 and 19
Done.
regards
Philipp
^ permalink raw reply
* [PATCHv3 4/4] arm64: dump: Add checking for writable and exectuable pages
From: Ard Biesheuvel @ 2016-10-20 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476828091-17802-5-git-send-email-labbott@redhat.com>
On 18 October 2016 at 23:01, Laura Abbott <labbott@redhat.com> wrote:
>
> Page mappings with full RWX permissions are a security risk. x86
> has an option to walk the page tables and dump any bad pages.
> (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
> implementation for arm64.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Rebased for header guard fixup, whitespace fixes
> ---
> arch/arm64/Kconfig.debug | 29 +++++++++++++++++++++++
> arch/arm64/include/asm/ptdump.h | 8 +++++++
> arch/arm64/mm/dump.c | 52 +++++++++++++++++++++++++++++++++++++++++
> arch/arm64/mm/mmu.c | 2 ++
> 4 files changed, 91 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 21a5b74..d1ebd46 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -42,6 +42,35 @@ config ARM64_RANDOMIZE_TEXT_OFFSET
> of TEXT_OFFSET and platforms must not require a specific
> value.
>
> +config DEBUG_WX
> + bool "Warn on W+X mappings at boot"
> + select ARM64_PTDUMP_CORE
> + ---help---
> + Generate a warning if any W+X mappings are found at boot.
> +
> + This is useful for discovering cases where the kernel is leaving
> + W+X mappings after applying NX, as such mappings are a security risk.
> + This check also includes UXN, which should be set on all kernel
> + mappings.
> +
> + Look for a message in dmesg output like this:
> +
> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
> +
> + or like this, if the check failed:
> +
> + arm64/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
> +
> + Note that even if the check fails, your kernel is possibly
> + still fine, as W+X mappings are not a security hole in
> + themselves, what they do is that they make the exploitation
> + of other unfixed kernel bugs easier.
> +
> + There is no runtime or memory usage effect of this option
> + once the kernel has booted up - it's a one time check.
> +
> + If in doubt, say "Y".
> +
> config DEBUG_SET_MODULE_RONX
> bool "Set loadable kernel module data as NX and text as RO"
> depends on MODULES
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index f72ee69..6afd847 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
> return 0;
> }
> #endif
> +void ptdump_check_wx(void);
> #endif /* CONFIG_ARM64_PTDUMP_CORE */
> +
> +#ifdef CONFIG_DEBUG_WX
> +#define debug_checkwx() ptdump_check_wx()
> +#else
> +#define debug_checkwx() do { } while (0)
> +#endif
> +
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index bb36649..4913af5 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -74,6 +74,8 @@ struct pg_state {
> unsigned long start_address;
> unsigned level;
> u64 current_prot;
> + bool check_wx;
> + unsigned long wx_pages;
> };
>
> struct prot_bits {
> @@ -202,6 +204,35 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits,
> }
> }
>
> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> +
> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
> +static void note_prot_wx(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> + if ((st->current_prot & PTE_RDONLY) == PTE_RDONLY)
> + return;
> + if ((st->current_prot & PTE_PXN) == PTE_PXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
Why are these separate functions, and why is wx_pages increased twice,
potentially?
Given how rare non-UXN kernel mappings should be, could we not just add
if ((st->current_prot & PTE_UXN) == 0)
WARN(xxx)
(without the _ONCE) to note_prot_wx(), and drop note_prot_uxn() entirely?
> static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> u64 val)
> {
> @@ -219,6 +250,8 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> unsigned long delta;
>
> if (st->current_prot) {
> + note_prot_uxn(st, addr);
> + note_prot_wx(st, addr);
> pt_dump_seq_printf(st->seq, "0x%016lx-0x%016lx ",
> st->start_address, addr);
>
> @@ -344,6 +377,25 @@ static struct ptdump_info kernel_ptdump_info = {
> .base_addr = VA_START,
> };
>
> +void ptdump_check_wx(void)
> +{
> + struct pg_state st = {
> + .seq = NULL,
> + .marker = (struct addr_marker[]) {
> + { -1, NULL},
> + },
> + .check_wx = true,
> + };
> +
> + walk_pgd(&st, &init_mm, 0);
> + note_page(&st, 0, 0, 0);
> + if (st.wx_pages)
> + pr_info("Checked W+X mappings: FAILED, %lu W+X pages found\n",
> + st.wx_pages);
Could we upgrade this to pr_warn?
> + else
> + pr_info("Checked W+X mappings: passed, no W+X pages found\n");
> +}
> +
> static int ptdump_init(void)
> {
> ptdump_initialize();
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 05615a3..2cbe2fe 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -42,6 +42,7 @@
> #include <asm/tlb.h>
> #include <asm/memblock.h>
> #include <asm/mmu_context.h>
> +#include <asm/ptdump.h>
>
> u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>
> @@ -396,6 +397,7 @@ void mark_rodata_ro(void)
> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
> create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> section_size, PAGE_KERNEL_RO);
> + debug_checkwx();
> }
>
> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-10-20 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb7bac91-8eb1-fe23-ca9c-857e0fda6ecd@ti.com>
On Thursday 20 October 2016 03:51 PM, Tomi Valkeinen wrote:
> On 20/10/16 13:07, Sekhar Nori wrote:
>
>> Per me, compatible property is an ordered list precisely for the reason
>> that things should continue to "work" with as closely matched driver as
>> possible. So even if someone is running a kernel which does not
>> recognize "ti,da850-tilcdc", it should still be able to probe the driver
>> based on "ti,am33xx-tilcdc" and provide as close to full functionality
>> as possible.
>>
>> That said, I will not insist on keeping it around if Tomi is
>> uncomfortable. And having read the binding documentation accepted by
>> Jyri, it actually says the compatible property should be __one of__
>> "ti,am33xx-tilcdc" or "ti,da850-tilcdc".
>
> Well, they are just not compatible as far as I know. If the LCDC on
> DA850 would be identified as AM335x LCDC, and used as such, it would not
> work at all. They have different registers, AM335x LCDC has registers
> that do not exist on DA850.
>
> With our driver it happens to work, because the driver looks at the IP
> revision in the registers, and then decides that this IP is not AM335x
> LCDC even if the dts says so. But I see that as a driver "feature",
> nothing that the .dts can depend on.
>
> Perhaps it might work the other way around, using DA850 driver on
> AM335x, as DA850 LCDC is a kind of subset of AM335x LCDC. But I'm not
> sure even about that.
Alright, thanks for the detailed explanation. I dropped the "ti,am33xx-
tilcdc" from the list and here is the updated patch I am queuing for
reference.
Thanks,
Sekhar
--8<--
Author: Karl Beldan <kbeldan@baylibre.com>
AuthorDate: Wed Oct 5 15:05:32 2016 +0200
Commit: Sekhar Nori <nsekhar@ti.com>
CommitDate: Thu Oct 20 15:57:21 2016 +0530
ARM: dts: da850: add a node for the LCD controller
Add pins used by the LCD controller and a disabled LCDC node to be
reused in device trees including da850.dtsi.
Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz:
- added the commit description
- changed the dt node name to a generic one
- added a da850-specific compatible string
- removed the tilcdc,panel node
- moved the pins definitions to da850.dtsi as suggested by
Sekhar Nori (was in: da850-lcdk.dts)]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[nsekhar at ti.com: fix compatible property and remove interrupt-parent]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b91c680..901d5c98d5f0 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -186,6 +186,27 @@
0xc 0x88888888 0xffffffff
>;
};
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,bits = <
+ /*
+ * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
+ * LCD_D[6], LCD_D[7]
+ */
+ 0x40 0x22222200 0xffffff00
+ /*
+ * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
+ * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
+ */
+ 0x44 0x22222222 0xffffffff
+ /* LCD_D[8], LCD_D[9] */
+ 0x48 0x00000022 0x000000ff
+
+ /* LCD_PCLK */
+ 0x48 0x02000000 0x0f000000
+ /* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
+ 0x4c 0x02000022 0x0f0000ff
+ >;
+ };
};
edma0: edma at 0 {
@@ -399,6 +420,13 @@
<&edma0 0 1>;
dma-names = "tx", "rx";
};
+
+ display: display at 213000 {
+ compatible = "ti,da850-tilcdc";
+ reg = <0x213000 0x1000>;
+ interrupts = <52>;
+ status = "disabled";
+ };
};
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
^ permalink raw reply related
* [PATCH v2 3/6] ARM: at91: Add armv7m support
From: Alexandre Belloni @ 2016-10-20 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5506721.HBUId2vnJb@wuerfel>
Hi,
On 20/10/2016 at 11:52:20 +0200, Arnd Bergmann wrote :
> On Thursday, October 20, 2016 11:41:32 AM CEST Alexandre Belloni wrote:
> > +
> > +static void __init samx7_dt_device_init(void)
> > +{
> > + struct soc_device *soc;
> > + struct device *soc_dev = NULL;
> > +
> > + soc = at91_soc_init(samx7_socs);
> > + if (soc)
> > + soc_dev = soc_device_to_device(soc);
> > +
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> > +}
>
> This was initially the idea for the soc_device, but we've stopped
> using it as the parent for the on-chip devices a while ago.
>
> Just register the device for identification here, and use
> of_platform_default_populate with a NULL parent as most others do.
>
> We should also investigate whether we can convert the three other
> at91 variants to do the same without breaking expectations in user space.
>
My opinion is that we could just remove the whole at91_soc_init stuff
but I think Nicolas still wants the two info lines to be printed for
debugging/support purposes. I'm not sure how much this is used anyway
and I don't find the sysfs attributes to be particularly useful.
Also, removing soc.c is a 10% reduction of the code in mach-at91 ;)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Tomi Valkeinen @ 2016-10-20 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c6fcceb-c6f2-219d-492a-a8b38fd83093@ti.com>
On 20/10/16 13:07, Sekhar Nori wrote:
> Per me, compatible property is an ordered list precisely for the reason
> that things should continue to "work" with as closely matched driver as
> possible. So even if someone is running a kernel which does not
> recognize "ti,da850-tilcdc", it should still be able to probe the driver
> based on "ti,am33xx-tilcdc" and provide as close to full functionality
> as possible.
>
> That said, I will not insist on keeping it around if Tomi is
> uncomfortable. And having read the binding documentation accepted by
> Jyri, it actually says the compatible property should be __one of__
> "ti,am33xx-tilcdc" or "ti,da850-tilcdc".
Well, they are just not compatible as far as I know. If the LCDC on
DA850 would be identified as AM335x LCDC, and used as such, it would not
work at all. They have different registers, AM335x LCDC has registers
that do not exist on DA850.
With our driver it happens to work, because the driver looks at the IP
revision in the registers, and then decides that this IP is not AM335x
LCDC even if the dts says so. But I see that as a driver "feature",
nothing that the .dts can depend on.
Perhaps it might work the other way around, using DA850 driver on
AM335x, as DA850 LCDC is a kind of subset of AM335x LCDC. But I'm not
sure even about that.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/b0a52fc5/attachment.sig>
^ permalink raw reply
* [PATCHv3 1/4] arm64: dump: Make ptdump debugfs a separate option
From: Ard Biesheuvel @ 2016-10-20 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476828091-17802-2-git-send-email-labbott@redhat.com>
On 18 October 2016 at 23:01, Laura Abbott <labbott@redhat.com> wrote:
>
> ptdump_register currently initializes a set of page table information and
> registers debugfs. There are uses for the ptdump option without wanting the
> debugfs options. Split this out to make it a separate option.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Minor header guard fixup.
>
> Mark Rutland pointed out that this needs to be reviewed by the EFI maintainers
> so I'm explicitly adding appropriate people/lists.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/Kconfig.debug | 6 +++++-
> arch/arm64/include/asm/ptdump.h | 15 +++++++++------
> arch/arm64/mm/Makefile | 3 ++-
> arch/arm64/mm/dump.c | 26 +++++---------------------
> arch/arm64/mm/ptdump_debugfs.c | 31 +++++++++++++++++++++++++++++++
> drivers/firmware/efi/arm-runtime.c | 4 ++--
> 6 files changed, 54 insertions(+), 31 deletions(-)
> create mode 100644 arch/arm64/mm/ptdump_debugfs.c
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index b661fe7..21a5b74 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -2,9 +2,13 @@ menu "Kernel hacking"
>
> source "lib/Kconfig.debug"
>
> -config ARM64_PTDUMP
> +config ARM64_PTDUMP_CORE
> + def_bool n
> +
> +config ARM64_PTDUMP_DEBUGFS
> bool "Export kernel pagetable layout to userspace via debugfs"
> depends on DEBUG_KERNEL
> + select ARM64_PTDUMP_CORE
> select DEBUG_FS
> help
> Say Y here if you want to show the kernel pagetable layout in a
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 07b8ed0..16335da 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -16,9 +16,10 @@
> #ifndef __ASM_PTDUMP_H
> #define __ASM_PTDUMP_H
>
> -#ifdef CONFIG_ARM64_PTDUMP
> +#ifdef CONFIG_ARM64_PTDUMP_CORE
>
> #include <linux/mm_types.h>
> +#include <linux/seq_file.h>
>
> struct addr_marker {
> unsigned long start_address;
> @@ -32,13 +33,15 @@ struct ptdump_info {
> unsigned long max_addr;
> };
>
> -int ptdump_register(struct ptdump_info *info, const char *name);
> -
> +void ptdump_walk_pgd(struct seq_file *s, struct ptdump_info *info);
> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name);
> #else
> -static inline int ptdump_register(struct ptdump_info *info, const char *name)
> +static inline int ptdump_debugfs_register(struct ptdump_info *info,
> + const char *name)
> {
> return 0;
> }
> -#endif /* CONFIG_ARM64_PTDUMP */
> -
> +#endif
> +#endif /* CONFIG_ARM64_PTDUMP_CORE */
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index 54bb209..e703fb9 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -3,7 +3,8 @@ obj-y := dma-mapping.o extable.o fault.o init.o \
> ioremap.o mmap.o pgd.o mmu.o \
> context.o proc.o pageattr.o
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> -obj-$(CONFIG_ARM64_PTDUMP) += dump.o
> +obj-$(CONFIG_ARM64_PTDUMP_CORE) += dump.o
> +obj-$(CONFIG_ARM64_PTDUMP_DEBUGFS) += ptdump_debugfs.o
> obj-$(CONFIG_NUMA) += numa.o
>
> obj-$(CONFIG_KASAN) += kasan_init.o
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 9c3e75d..f0f0be7 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -304,9 +304,8 @@ static void walk_pgd(struct pg_state *st, struct mm_struct *mm,
> }
> }
>
> -static int ptdump_show(struct seq_file *m, void *v)
> +void ptdump_walk_pgd(struct seq_file *m, struct ptdump_info *info)
> {
> - struct ptdump_info *info = m->private;
> struct pg_state st = {
> .seq = m,
> .marker = info->markers,
> @@ -315,33 +314,16 @@ static int ptdump_show(struct seq_file *m, void *v)
> walk_pgd(&st, info->mm, info->base_addr);
>
> note_page(&st, 0, 0, 0);
> - return 0;
> }
>
> -static int ptdump_open(struct inode *inode, struct file *file)
> +static void ptdump_initialize(void)
> {
> - return single_open(file, ptdump_show, inode->i_private);
> -}
> -
> -static const struct file_operations ptdump_fops = {
> - .open = ptdump_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> -
> -int ptdump_register(struct ptdump_info *info, const char *name)
> -{
> - struct dentry *pe;
> unsigned i, j;
>
> for (i = 0; i < ARRAY_SIZE(pg_level); i++)
> if (pg_level[i].bits)
> for (j = 0; j < pg_level[i].num; j++)
> pg_level[i].mask |= pg_level[i].bits[j].mask;
> -
> - pe = debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
> - return pe ? 0 : -ENOMEM;
> }
>
> static struct ptdump_info kernel_ptdump_info = {
> @@ -352,6 +334,8 @@ static struct ptdump_info kernel_ptdump_info = {
>
> static int ptdump_init(void)
> {
> - return ptdump_register(&kernel_ptdump_info, "kernel_page_tables");
> + ptdump_initialize();
> + return ptdump_debugfs_register(&kernel_ptdump_info,
> + "kernel_page_tables");
> }
> device_initcall(ptdump_init);
> diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
> new file mode 100644
> index 0000000..eee4d86
> --- /dev/null
> +++ b/arch/arm64/mm/ptdump_debugfs.c
> @@ -0,0 +1,31 @@
> +#include <linux/debugfs.h>
> +#include <linux/seq_file.h>
> +
> +#include <asm/ptdump.h>
> +
> +static int ptdump_show(struct seq_file *m, void *v)
> +{
> + struct ptdump_info *info = m->private;
> + ptdump_walk_pgd(m, info);
> + return 0;
> +}
> +
> +static int ptdump_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, ptdump_show, inode->i_private);
> +}
> +
> +static const struct file_operations ptdump_fops = {
> + .open = ptdump_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> +int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
> +{
> + struct dentry *pe;
> + pe = debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
> + return pe ? 0 : -ENOMEM;
> +
> +}
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 7c75a8d..349dc3e 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -39,7 +39,7 @@ static struct mm_struct efi_mm = {
> .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
> };
>
> -#ifdef CONFIG_ARM64_PTDUMP
> +#ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
> #include <asm/ptdump.h>
>
> static struct ptdump_info efi_ptdump_info = {
> @@ -53,7 +53,7 @@ static struct ptdump_info efi_ptdump_info = {
>
> static int __init ptdump_init(void)
> {
> - return ptdump_register(&efi_ptdump_info, "efi_page_tables");
> + return ptdump_debugfs_register(&efi_ptdump_info, "efi_page_tables");
> }
> device_initcall(ptdump_init);
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=y
From: Ard Biesheuvel @ 2016-10-20 10:12 UTC (permalink / raw)
To: linux-arm-kernel
GNU ld used to set the ELF file type to ET_DYN for PIE executables, which
is the same file type used for shared libraries. However, this was changed
recently, and now PIE executables are emitted as ET_EXEC instead.
The distinction is only relevant for ELF loaders, and so there is little
reason to care about the difference when building the kernel, which is
why the change has gone unnoticed until now.
However, debuggers do use the ELF binary, and expect ET_EXEC type files
to appear in memory at the exact offset described in the ELF metadata.
This means source level debugging is no longer possible when KASLR is in
effect or when executing the stub.
So add the -shared LD option when building with CONFIG_RELOCATABLE=y. This
forces the ELF file type to be set to ET_DYN (which is what you get when
building with binutils 2.24 and earlier anyway), and has no other ill
effects.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
The difference in output between ET_EXEC and ET_DYN file types for
'readelf -a vmlinux':
--- /tmp/exec 2016-10-19 17:46:51.368841538 +0100
+++ /tmp/dyn 2016-10-19 17:46:01.774879088 +0100
@@ -5,7 +5,7 @@
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
- Type: EXEC (Executable file)
+ Type: DYN (Shared object file)
Machine: AArch64
Version: 0x1
Entry point address: 0xffff000008080000
@@ -239199,7 +239199,7 @@
108973: 0000000000000000 0 FILE LOCAL DEFAULT ABS
108974: ffff0000089800a0 0 OBJECT LOCAL DEFAULT ABS _GLOBAL_OFFSET_TABLE_
108975: ffff0000081a7c70 0 NOTYPE LOCAL DEFAULT 2 $x
-108976: ffff0000081a7c74 8 FUNC LOCAL DEFAULT 2 e843419 at 001a_00000473_99c
+108976: ffff0000081a7c74 8 FUNC LOCAL DEFAULT 2 e843419 at 001a_00000472_99c
108977: ffff0000081a7c74 0 NOTYPE LOCAL DEFAULT 2 $x
108978: ffff000008d7c118 136 FUNC GLOBAL DEFAULT 19 __efistub_fdt_delprop
108979: ffff000008819db8 36 FUNC GLOBAL DEFAULT 2 arch_timer_get_kvm_info
@@ -269256,4 +269256,4 @@
Displaying notes found at file offset 0x00cf5740 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
- Build ID: a63334609e04d620ea175bb9e88bc68989dc0402
+ Build ID: 7f489d756b1799111b0128ffa61546c2ac1f6e2a
arch/arm64/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index ab51aed6b6c1..3635b8662724 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -15,7 +15,7 @@ CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
GZFLAGS :=-9
ifneq ($(CONFIG_RELOCATABLE),)
-LDFLAGS_vmlinux += -pie -Bsymbolic
+LDFLAGS_vmlinux += -pie -shared -Bsymbolic
endif
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: Add support for additional relocations in the kexec purgatory code
From: Catalin Marinas @ 2016-10-20 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15f9c4d2-34a8-fd74-05ec-0a8df41bc93a@infradead.org>
On Wed, Oct 19, 2016 at 03:52:30PM -0700, Geoff Levand wrote:
> Hi Catalin,
>
> On 10/19/2016 08:58 AM, Catalin Marinas wrote:
> > diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> > index 2e8839a..e067a23 100644
> > --- a/kexec/arch/arm64/kexec-arm64.c
> > +++ b/kexec/arch/arm64/kexec-arm64.c
> > @@ -585,6 +598,19 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> > *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> > + (((value - address) << 3) & 0xffffe0));
> > break;
> > + case R_AARCH64_ADR_PREL_PG_HI21:
> > + type = "ADR_PREL_PG_HI21";
> > + imm = ((value & ~0xfff) - (address & ~0xfff)) >> 12;
> > + loc32 = ptr;
> > + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> > + + ((imm & 3) << 29) + ((imm & 0x1ffffc) << (5 - 2)));
> > + break;
> > + case R_AARCH64_ADD_ABS_LO12_NC:
> > + type = "R_AARCH64_ADD_ABS_LO12_NC";
>
> Following with the others, this should be 'type = "ADD_ABS_LO12_NC"'.
Ah, I missed this detail. I'll post a v2 shortly.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Peter Chen @ 2016-10-20 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147694652997.28344.1048935134595924905@sboyd-linaro>
On Wed, Oct 19, 2016 at 11:55:29PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-19 01:02:11)
> > On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> > > If you're asking if I've made modifications to extcon-usb-gpio, then the
> > > answer is no. The branch on linaro.org git server from the cover-letter
> > > is the branch I've used to test this with. This patch is specifically to
> > > fix issues with that design on the db410c board that has only one pin
> > > for ID and vbus detection. It's the schematic that we've discussed in
> > > another thread.
> > >
> > > extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> > > pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> > > events.
> > >
> >
> > Hmm, in fact, your ID event is the same with vbus event, you take
> > external vbus event as ID event for extcon-usb-gpio handling. Yes,
> > it can work due to it sends EXTCON_USB_HOST event first.
> >
> > Where you change the USB_SW_SEL_PM pin?
>
> Currently that is done with the mux driver I sent based on the extcon
> event. We don't know if that's before or after the controller handles
> the extcon event though, so the pin should probably be changed from the
> chipidea driver instead to be more explicit. Why do you ask though?
I was just curious how you handle it, now I am clear. From my point,
the suitable way may be: mux driver + user app (echo role through
debugfs). The extcon-usb-gpio is not necessary, since you have already
known role at mux driver.
The current kernel has no framework to handle dual-role switch at kernel
space.
> > At some situations, the vbus may already be there before starting
> > gadget. So we need to check vbus event after switch to gadget in
> > order to handle missing vbus event. The typical use cases are plugging
> > vbus cable before driver load or the vbus has already been there
> > after stopping host but before starting gadget.
> >
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
>
> Yes this should work. Light testing doesn't show any problems so far.
>
> > ---
> > drivers/usb/chipidea/core.c | 4 ----
> > drivers/usb/chipidea/otg.c | 10 ++++++----
> > drivers/usb/chipidea/udc.c | 2 ++
> > 3 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index b814d91..a7d2c68 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -992,10 +992,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > }
> >
> > if (!ci_otg_is_fsm_mode(ci)) {
> > - /* only update vbus status for peripheral */
> > - if (ci->role == CI_ROLE_GADGET)
> > - ci_handle_vbus_change(ci);
> > -
> > ret = ci_role_start(ci, ci->role);
> > if (ret) {
> > dev_err(dev, "can't start %s role\n",
> > diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> > index 695f3fe..99c0709 100644
> > --- a/drivers/usb/chipidea/otg.c
> > +++ b/drivers/usb/chipidea/otg.c
> > @@ -134,9 +134,9 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
> > if (!ci->is_otg)
> > return;
> >
> > - if (hw_read_otgsc(ci, OTGSC_BSV))
> > + if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
> > usb_gadget_vbus_connect(&ci->gadget);
> > - else
> > + else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
> > usb_gadget_vbus_disconnect(&ci->gadget);
> > }
> >
> > @@ -175,10 +175,12 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
> >
> > ci_role_stop(ci);
> >
> > - if (role == CI_ROLE_GADGET)
> > + if (role == CI_ROLE_GADGET &&
> > + IS_ERR(ci->platdata->vbus_extcon.edev))
> > /*
> > * wait vbus lower than OTGSC_BSV before connecting
> > - * to host
> > + * to host. And if vbus's status is an external
> > + * connector, it doesn't need to wait here.
>
> because OTGSC_BSV will toggle based on the extcon state and not when the
> phy connects to the host? It would be good to explain why it's not
> needed instead of just repeating what the code is doing.
>
Thanks, will change like below
"
If connecting status is from an external connector instead of register,
we don't need to care vbus on the board, since it will not affect external
connector status.
"
> > */
> > hw_wait_vbus_lower_bsv(ci);
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 001c2fa..184ffba 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > /* Clear and enable BSV irq */
> > hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > OTGSC_BSVIS | OTGSC_BSVIE);
> > + /* vbus change may has already been occurred */
>
> "vbus change may have already occurred"?
Yes, will change.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-10-20 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJXT8hcSc0-svbwAq5r_JOFsYV852gtE0vuXL8hHykXnRQ@mail.gmail.com>
On Monday 17 October 2016 07:31 PM, Bartosz Golaszewski wrote:
> 2016-10-17 14:29 GMT+02:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
>> On 17/10/16 14:40, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>>>> On 17/10/16 10:12, Sekhar Nori wrote:
>>>>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>>>>> On 15/10/16 20:42, Sekhar Nori wrote:
>>>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>>>> index f79e1b9..32908ae 100644
>>>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>>>> @@ -399,6 +420,14 @@
>>>>>>>> <&edma0 0 1>;
>>>>>>>> dma-names = "tx", "rx";
>>>>>>>> };
>>>>>>>> +
>>>>>>>> + display: display at 213000 {
>>>>>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>>>>>
>>>>>>> This should instead be:
>>>>>>>
>>>>>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>>>>>
>>>>>>> as the closest match should appear first in the list.
>>>>>>
>>>>>> Actually I don't think that's correct. The LCDC on da850 is not
>>>>>> compatible with the LCDC on AM335x. I think it should be just
>>>>>> "ti,da850-tilcdc".
>>>>>
>>>>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>>>>> the case, I wonder how the patch passed testing. Bartosz?
>>>>
>>>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>>>> similar, but different.
>>>>
>>>> The driver gets the version number from LCDC's register, and acts based
>>>> on that, so afaik the compatible string doesn't really affect the
>>>> functionality (as long as it matches).
>>>>
>>>> But even if it works with the current driver, I don't think
>>>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
>>>
>>> If the hardware provides IP revision information, how about just "ti,lcdc" ?
>>
>> Maybe, and I agree that's the "correct" way, but looking at the history,
>> it's not just once or twice when we've suddenly found out some
>> difference or bug or such in an IP revision, or the integration to a
>> SoC, that can't be found based on the IP revision.
>>
>> That's why I feel it's usually safer to have the SoC revision there in
>> the compatible string.
I agree with Tomi here. Lets keep the soc part number in the compatible
string. More often than not, some undocumented, undiscovered issue pops
up over time. Its much safer to have the SoC revision in there.
>>
>> That said, we have only a few different old SoCs with LCDC (compared to,
>> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
>>
>> Tomi
>>
>
> I Sekhar is ok with this, I'll send a follow-up patch for that.
Per me, compatible property is an ordered list precisely for the reason
that things should continue to "work" with as closely matched driver as
possible. So even if someone is running a kernel which does not
recognize "ti,da850-tilcdc", it should still be able to probe the driver
based on "ti,am33xx-tilcdc" and provide as close to full functionality
as possible.
That said, I will not insist on keeping it around if Tomi is
uncomfortable. And having read the binding documentation accepted by
Jyri, it actually says the compatible property should be __one of__
"ti,am33xx-tilcdc" or "ti,da850-tilcdc".
Thanks,
Sekhar
^ permalink raw reply
* [RESEND PATCH v2 1/3] reset: oxnas: Add OX820 support
From: Philipp Zabel @ 2016-10-20 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005152710.2898-2-narmstrong@baylibre.com>
Am Mittwoch, den 05.10.2016, 17:27 +0200 schrieb Neil Armstrong:
> In order to support the Oxford Semiconductor OX820 SoC, add a new
> compatible string.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/reset/reset-oxnas.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/reset/reset-oxnas.c b/drivers/reset/reset-oxnas.c
> index 9449805..0d9036d 100644
> --- a/drivers/reset/reset-oxnas.c
> +++ b/drivers/reset/reset-oxnas.c
> @@ -80,6 +80,7 @@ static const struct reset_control_ops oxnas_reset_ops = {
>
> static const struct of_device_id oxnas_reset_dt_ids[] = {
> { .compatible = "oxsemi,ox810se-reset", },
> + { .compatible = "oxsemi,ox820-reset", },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, oxnas_reset_dt_ids);
Applied all three, thanks.
regards
Philipp
^ permalink raw reply
* [PATCH v3 0/11] Add R8A7743/SK-RZG1M board support
From: Geert Uytterhoeven @ 2016-10-20 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020092459.GM4612@verge.net.au>
Hi Simon,
On Thu, Oct 20, 2016 at 11:24 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 12, 2016 at 11:29:56AM +0300, Sergei Shtylyov wrote:
>> On 10/12/2016 11:09 AM, Simon Horman wrote:
>> >>> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
>> >>>'renesas-devel-20161003-v4.8' tag. I'm adding the device tree support for
>> >>>the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
>> >>>seems identical to the R8A7791/Porter board. The device tree patches depend on
>> >>>the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>> >>
>> >> Forgot to mention that this version causes a regression with the sh_eth
>> >>driver (well, actually with phylib): since IRQC now gets a deferred probing,
>> >>PHY IRQ doesn't work anymore -- phylib falls back to polling.
>> >
>> >Is there a resolution to that problem?
>>
>> Geert has posted his IRQC driver patch recently. Not sure if it was
>> intended for merging but it solves the issue.
>
> Ok. I think it is ok to merge support for a new board even if there are
> problems as its not regressing (can't break something that previously
> didn't exist imho). But of course it would be best if things did work.
>
> Geert, do you have any comments on the relevance of your IRQC driver patch?
That patch is relevant, until the MDIO framework is fixed.
It will start to matter more when migrating more (R-Car Gen2) SoCs to the new
CPG/MSSR driver.
It would be good to give that patch some testing on more R-Car Gen2 boards
with NFS root (difficult for me with remote access and network latencies).
After that I can submit it to the irqchip maintainers, as I don't believe MDIO
will be fixed soonish...
Thanks for testing ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 3/6] ARM: at91: Add armv7m support
From: Arnd Bergmann @ 2016-10-20 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020094135.18221-4-alexandre.belloni@free-electrons.com>
On Thursday, October 20, 2016 11:41:32 AM CEST Alexandre Belloni wrote:
> +
> +static void __init samx7_dt_device_init(void)
> +{
> + struct soc_device *soc;
> + struct device *soc_dev = NULL;
> +
> + soc = at91_soc_init(samx7_socs);
> + if (soc)
> + soc_dev = soc_device_to_device(soc);
> +
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> +}
This was initially the idea for the soc_device, but we've stopped
using it as the parent for the on-chip devices a while ago.
Just register the device for identification here, and use
of_platform_default_populate with a NULL parent as most others do.
We should also investigate whether we can convert the three other
at91 variants to do the same without breaking expectations in user space.
Arnd
^ permalink raw reply
* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Vinod Koul @ 2016-10-20 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-1-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 01:51:42PM -0400, Sinan Kaya wrote:
> The new version of the HW supports MSI interrupts instead of wired
> interrupts. The MSI interrupts are especially useful for the guest machine
> execution. The wired interrupts usually trap to the hypervisor and then are
> relayed to the actual interrupt.
>
> The MSI interrupts can be directly fed into the interrupt controller.
>
> Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
> to distinguish newer HW from the older ones.
>
> v6:
> * rebase 4.9 kernel
Why???
I already told you that I have applied 6 in the last version, please dont
send me stuff which is already applied :(
--
~Vinod
^ permalink raw reply
* [PATCH v2 6/6] ARM: at91: debug: add samx7 support
From: Alexandre Belloni @ 2016-10-20 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020094135.18221-1-alexandre.belloni@free-electrons.com>
From: Szemz? Andr?s <sza@esh.hu>
Add support for low level debugging on Atmel samx7.
Signed-off-by: Szemz? Andr?s <sza@esh.hu>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/Kconfig.debug | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c369e51..219e65c85289 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -145,6 +145,15 @@ choice
Say Y here if you want kernel low-level debugging support
on the USART3 port of sama5d4.
+ config DEBUG_AT91_SAMX7_USART1
+ bool "Kernel low-level debugging via SAMX7 USART1"
+ select DEBUG_AT91_UART
+ depends on SOC_SAMX7
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the USART1 port on SAMX7 based
+ machines.
+
config DEBUG_BCM2835
bool "Kernel low-level debugging on BCM2835 PL011 UART"
depends on ARCH_BCM2835 && ARCH_MULTI_V6
@@ -1481,6 +1490,7 @@ config DEBUG_UART_PHYS
default 0x3f201000 if DEBUG_BCM2836
default 0x3e000000 if DEBUG_BCM_KONA_UART
default 0x4000e400 if DEBUG_LL_UART_EFM32
+ default 0x40028000 if DEBUG_AT91_SAMX7_USART1
default 0x40081000 if DEBUG_LPC18XX_UART0
default 0x40090000 if DEBUG_LPC32XX
default 0x40100000 if DEBUG_PXA_UART1
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: at91: add samx7 dtsi
From: Alexandre Belloni @ 2016-10-20 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020094135.18221-1-alexandre.belloni@free-electrons.com>
From: Szemz? Andr?s <sza@esh.hu>
Add device tree support for Atmel samx7 SoCs family.
Signed-off-by: Szemz? Andr?s <sza@esh.hu>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/boot/dts/samx7.dtsi | 1128 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 1128 insertions(+)
create mode 100644 arch/arm/boot/dts/samx7.dtsi
diff --git a/arch/arm/boot/dts/samx7.dtsi b/arch/arm/boot/dts/samx7.dtsi
new file mode 100644
index 000000000000..a4b36586d108
--- /dev/null
+++ b/arch/arm/boot/dts/samx7.dtsi
@@ -0,0 +1,1128 @@
+/*
+ * samx7.dtsi - Device Tree Include file for SAMx7 family SoCs
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "armv7-m.dtsi"
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/dma/at91.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/clock/at91.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "Atmel SAMx7 family SoC";
+ compatible = "atmel,samx7";
+
+ aliases {
+ serial0 = &usart0;
+ serial1 = &usart1;
+ serial2 = &usart2;
+ serial3 = &uart0;
+ serial4 = &uart1;
+ serial5 = &uart2;
+ serial6 = &uart3;
+ serial7 = &uart4;
+ gpio0 = &pioA;
+ gpio1 = &pioB;
+ gpio2 = &pioC;
+ gpio3 = &pioD;
+ gpio4 = &pioE;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ tcb0 = &tcb0;
+ tcb1 = &tcb1;
+ tcb2 = &tcb2;
+ tcb3 = &tcb3;
+ pwm0 = &pwm0;
+ pwm1 = &pwm1;
+ };
+
+ clocks {
+
+ clk_slck: clk-slck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ };
+
+ clk_mck: clk-mck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ };
+ };
+
+ soc {
+
+ pmc: pmc at 0x400e0600 {
+ compatible = "atmel,at91sam9x5-pmc", "syscon";
+ reg = <0x400e0600 0x200>;
+ interrupts = <5>;
+ interrupt-controller;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+
+ periphck {
+ compatible = "atmel,at91sam9x5-clk-peripheral";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk_mck>;
+
+ uart0_clk: uart0_clk {
+ #clock-cells = <0>;
+ reg = <7>;
+ };
+
+ uart1_clk: uart1_clk {
+ #clock-cells = <0>;
+ reg = <8>;
+ };
+
+ smc_clk: smc_clk {
+ #clock-cells = <0>;
+ reg = <9>;
+ };
+
+ pioA_clk: pioA_clk {
+ #clock-cells = <0>;
+ reg = <10>;
+ };
+
+ pioB_clk: pioB_clk {
+ #clock-cells = <0>;
+ reg = <11>;
+ };
+
+ pioC_clk: pioC_clk {
+ #clock-cells = <0>;
+ reg = <12>;
+ };
+
+ usart0_clk: usart0_clk {
+ #clock-cells = <0>;
+ reg = <13>;
+ };
+
+ usart1_clk: usart1_clk {
+ #clock-cells = <0>;
+ reg = <14>;
+ };
+
+ usart2_clk: usart2_clk {
+ #clock-cells = <0>;
+ reg = <15>;
+ };
+
+ pioD_clk: pioD_clk {
+ #clock-cells = <0>;
+ reg = <16>;
+ };
+
+ pioE_clk: pioE_clk {
+ #clock-cells = <0>;
+ reg = <17>;
+ };
+
+ mci_clk: mci_clk {
+ #clock-cells = <0>;
+ reg = <18>;
+ };
+
+ twi0_clk: twi0_clk {
+ #clock-cells = <0>;
+ reg = <19>;
+ };
+
+ twi1_clk: twi1_clk {
+ #clock-cells = <0>;
+ reg = <20>;
+ };
+
+ spi0_clk: spi0_clk {
+ #clock-cells = <0>;
+ reg = <21>;
+ };
+
+ ssc_clk: ssc_clk {
+ #clock-cells = <0>;
+ reg = <22>;
+ };
+
+ tcb0_clk: tcb0_clk {
+ #clock-cells = <0>;
+ reg = <23>;
+ };
+
+ tcb1_clk: tcb1_clk {
+ #clock-cells = <0>;
+ reg = <24>;
+ };
+
+ tcb2_clk: tcb2_clk {
+ #clock-cells = <0>;
+ reg = <25>;
+ };
+
+ tcb3_clk: tcb3_clk {
+ #clock-cells = <0>;
+ reg = <26>;
+ };
+
+ tcb4_clk: tcb4_clk {
+ #clock-cells = <0>;
+ reg = <27>;
+ };
+
+ tcb5_clk: tcb5_clk {
+ #clock-cells = <0>;
+ reg = <28>;
+ };
+
+ afec0_clk: afec0_clk {
+ #clock-cells = <0>;
+ reg = <29>;
+ };
+
+ dacc_clk: dacc_clk {
+ #clock-cells = <0>;
+ reg = <30>;
+ };
+
+ pwm0_clk: pwm0_clk {
+ #clock-cells = <0>;
+ reg = <31>;
+ };
+
+ icm_clk: cim_clk {
+ #clock-cells = <0>;
+ reg = <32>;
+ };
+
+ acc_clk: acc_clk {
+ #clock-cells = <0>;
+ reg = <33>;
+ };
+
+ usbhs_clk: usbhs_clk {
+ #clock-cells = <0>;
+ reg = <34>;
+ };
+
+ can0_clk: can0_clk {
+ #clock-cells = <0>;
+ reg = <35>;
+ };
+
+ can1_clk: can1_clk {
+ #clock-cells = <0>;
+ reg = <37>;
+ };
+
+ macb_clk: macb_clk {
+ #clock-cells = <0>;
+ reg = <39>;
+ };
+
+ afec1_clk: afec1_clk {
+ #clock-cells = <0>;
+ reg = <40>;
+ };
+
+ twi2_clk: twi2_clk {
+ #clock-cells = <0>;
+ reg = <41>;
+ };
+
+ spi1_clk: spi1_clk {
+ #clock-cells = <0>;
+ reg = <42>;
+ };
+
+ qspi_clk: qspi_clk {
+ #clock-cells = <0>;
+ reg = <43>;
+ };
+
+ uart2_clk: uart2_clk {
+ #clock-cells = <0>;
+ reg = <44>;
+ };
+
+ uart3_clk: uart3_clk {
+ #clock-cells = <0>;
+ reg = <45>;
+ };
+
+ uart4_clk: uart4_clk {
+ #clock-cells = <0>;
+ reg = <46>;
+ };
+
+ tcb6_clk: tcb6_clk {
+ #clock-cells = <0>;
+ reg = <47>;
+ };
+
+ tcb7_clk: tcb7_clk {
+ #clock-cells = <0>;
+ reg = <48>;
+ };
+
+ tcb8_clk: tcb8_clk {
+ #clock-cells = <0>;
+ reg = <49>;
+ };
+
+ tcb9_clk: tcb9_clk {
+ #clock-cells = <0>;
+ reg = <50>;
+ };
+
+ tcb10_clk: tcb10_clk {
+ #clock-cells = <0>;
+ reg = <51>;
+ };
+
+ tcb11_clk: tcb11_clk {
+ #clock-cells = <0>;
+ reg = <52>;
+ };
+
+ aes_clk: aes_clk {
+ #clock-cells = <0>;
+ reg = <56>;
+ };
+
+ trng_clk: trng_clk {
+ #clock-cells = <0>;
+ reg = <57>;
+ };
+
+ dma_clk: dma_clk {
+ #clock-cells = <0>;
+ reg = <58>;
+ };
+
+ isi_clk: isi_clk {
+ #clock-cells = <0>;
+ reg = <59>;
+ };
+
+ pwm1_clk: pwm1_clk {
+ #clock-cells = <0>;
+ reg = <60>;
+ };
+
+ i2sc0_clk: i2sc0_clk {
+ #clock-cells = <0>;
+ reg = <69>;
+ };
+
+ i2sc1_clk: i2sc1_clk {
+ #clock-cells = <0>;
+ reg = <70>;
+ };
+ };
+ };
+
+ pinctrl at 0x400e0e00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "atmel,sama5d3-pinctrl", "atmel,at91sam9x5-pinctrl", "simple-bus";
+ ranges = <0x400e0e00 0x400e0e00 0xa00>;
+
+ pioA: gpio at 0x400e0e00 {
+ compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
+ reg = <0x400e0e00 0x200>;
+ interrupts = <10>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pioA_clk>;
+ };
+
+ pioB: gpio at 0x400e1000 {
+ compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
+ reg = <0x400e1000 0x200>;
+ interrupts = <11>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pioB_clk>;
+ };
+
+ pioC: gpio at 0x400e1200 {
+ compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
+ reg = <0x400e1200 0x200>;
+ interrupts = <12>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pioC_clk>;
+ };
+
+ pioD: gpio at 0x400e1400 {
+ compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
+ reg = <0x400e1400 0x200>;
+ interrupts = <16>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pioD_clk>;
+ };
+
+ pioE: gpio at 0x400e1600 {
+ compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
+ reg = <0x400e1600 0x200>;
+ interrupts = <17>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pioE_clk>;
+ };
+
+ macb {
+ pinctrl_macb_rmii: macb_rmii-0 {
+ atmel,pins =
+ <AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 1 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 2 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 3 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 4 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 5 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 6 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 7 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 8 AT91_PERIPH_A AT91_PINCTRL_NONE
+ AT91_PIOD 9 AT91_PERIPH_A AT91_PINCTRL_NONE
+ >;
+ };
+ };
+
+ mmc {
+ pinctrl_mmc_clk_cmd_dat0: mmc_clk_cmd_dat0 {
+ atmel,pins =
+ <AT91_PIOA 25 AT91_PERIPH_D AT91_PINCTRL_NONE /* MCI_CK */
+ AT91_PIOA 28 AT91_PERIPH_C AT91_PINCTRL_PULL_UP /* MCI_CDA */
+ AT91_PIOA 30 AT91_PERIPH_C AT91_PINCTRL_PULL_UP /* MCI_DB0 */
+ >;
+ };
+ pinctrl_mmc_dat1_3: mmc_dat1_3 {
+ atmel,pins =
+ <AT91_PIOA 31 AT91_PERIPH_C AT91_PINCTRL_PULL_UP /* MCI_DB1 */
+ AT91_PIOA 26 AT91_PERIPH_C AT91_PINCTRL_PULL_UP /* MCI_DB2 */
+ AT91_PIOA 27 AT91_PERIPH_C AT91_PINCTRL_PULL_UP /* MCI_DB3 */
+ >;
+ };
+ };
+
+ i2c0 {
+ pinctrl_i2c0: i2c0-0 {
+ atmel,pins =
+ <AT91_PIOA 3 AT91_PERIPH_A AT91_PINCTRL_NONE /* I2C0 data */
+ AT91_PIOA 4 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* I2C0 clock */
+ };
+ };
+
+ i2c1 {
+ pinctrl_i2c1: i2c1-0 {
+ atmel,pins =
+ <AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE /* I2C1 data */
+ AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* I2C1 clock */
+ };
+ };
+
+ i2c2 {
+ pinctrl_i2c2: i2c2-0 {
+ atmel,pins =
+ <AT91_PIOD 27 AT91_PERIPH_C AT91_PINCTRL_NONE /* I2C2 data */
+ AT91_PIOD 28 AT91_PERIPH_C AT91_PINCTRL_NONE>; /* I2C2 clock */
+ };
+ };
+
+ qspi {
+ pinctrl_qspi: qspi-0 {
+ atmel,pins =
+ <AT91_PIOA 14 AT91_PERIPH_A AT91_PINCTRL_NONE /* QSCK */
+ AT91_PIOA 11 AT91_PERIPH_A AT91_PINCTRL_NONE /* QCS */
+ AT91_PIOA 13 AT91_PERIPH_A AT91_PINCTRL_NONE /* QIO0 */
+ AT91_PIOA 12 AT91_PERIPH_A AT91_PINCTRL_NONE /* QIO1 */
+ AT91_PIOA 17 AT91_PERIPH_A AT91_PINCTRL_NONE /* QIO2 */
+ AT91_PIOD 31 AT91_PERIPH_A AT91_PINCTRL_NONE /* QIO3 */
+ >;
+ };
+ };
+
+ usart0 {
+ pinctrl_usart0: usart0-0 {
+ atmel,pins =
+ <AT91_PIOB 0 AT91_PERIPH_C AT91_PINCTRL_NONE /* RXD */
+ AT91_PIOB 1 AT91_PERIPH_C AT91_PINCTRL_PULL_UP /* TXD */
+ >;
+ };
+
+ pinctrl_usart0_rts: usart0_rts-0 {
+ atmel,pins = <AT91_PIOB 3 AT91_PERIPH_C AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_usart0_cts: usart0_cts-0 {
+ atmel,pins = <AT91_PIOB 2 AT91_PERIPH_C AT91_PINCTRL_NONE>;
+ };
+ };
+
+ usart1 {
+ pinctrl_usart1: usart1-0 {
+ atmel,pins =
+ <AT91_PIOA 21 AT91_PERIPH_A AT91_PINCTRL_NONE /* RXD */
+ AT91_PIOB 4 AT91_PERIPH_D AT91_PINCTRL_PULL_UP /* TXD */
+ >;
+ };
+
+ pinctrl_usart1_rts: usart1_rts-0 {
+ atmel,pins = <AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_usart1_cts: usart1_cts-0 {
+ atmel,pins = <AT91_PIOA 25 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ };
+
+ usart2 {
+ pinctrl_usart2: usart2-0 {
+ atmel,pins =
+ <AT91_PIOD 15 AT91_PERIPH_B AT91_PINCTRL_NONE /* RXD */
+ AT91_PIOD 16 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* TXD */
+ >;
+ };
+
+ pinctrl_usart2_rts: usart2_rts-0 {
+ atmel,pins = <AT91_PIOD 18 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_usart2_cts: usart2_cts-0 {
+ atmel,pins = <AT91_PIOD 19 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ };
+
+ spi0 {
+ pinctrl_spi0: spi0-0 {
+ atmel,pins =
+ <AT91_PIOD 20 AT91_PERIPH_B AT91_PINCTRL_NONE /* SPI0_MISO */
+ AT91_PIOD 21 AT91_PERIPH_B AT91_PINCTRL_NONE /* SPI0_MOSI */
+ AT91_PIOD 22 AT91_PERIPH_B AT91_PINCTRL_NONE /* SPI0_SPCK */
+ >;
+ };
+ };
+
+ spi1 {
+ pinctrl_spi1: spi1-0 {
+ atmel,pins =
+ <AT91_PIOC 26 AT91_PERIPH_C AT91_PINCTRL_NONE /* SPI1_MISO */
+ AT91_PIOC 27 AT91_PERIPH_C AT91_PINCTRL_NONE /* SPI1_MOSI */
+ AT91_PIOC 24 AT91_PERIPH_C AT91_PINCTRL_NONE /* SPI1_SPCK */
+ >;
+ };
+ };
+
+ can0 {
+ pinctrl_can0_rx_tx: can0_rx_tx {
+ atmel,pins =
+ <AT91_PIOB 3 AT91_PERIPH_A AT91_PINCTRL_NONE /* RX */
+ AT91_PIOB 2 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* TX */
+ };
+ };
+
+ can1 {
+ pinctrl_can1_rx_tx: can1_rx_tx {
+ atmel,pins =
+ <AT91_PIOC 12 AT91_PERIPH_C AT91_PINCTRL_NONE /* RX */
+ AT91_PIOC 14 AT91_PERIPH_C AT91_PINCTRL_NONE>; /* TX */
+ };
+ };
+
+ pwm0 {
+ pinctrl_pwm0_pwmh0_0: pwm0_pwmh0-0 {
+ atmel,pins =
+ <AT91_PIOA 0 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh0_1: pwm0_pwmh0-1 {
+ atmel,pins =
+ <AT91_PIOA 11 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh0_2: pwm0_pwmh0-2 {
+ atmel,pins =
+ <AT91_PIOA 23 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh0_3: pwm0_pwmh0-3 {
+ atmel,pins =
+ <AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh0_4: pwm0_pwmh0-4 {
+ atmel,pins =
+ <AT91_PIOD 11 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh0_5: pwm0_pwmh0-5 {
+ atmel,pins =
+ <AT91_PIOD 20 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pwm0_pwmh1_0: pwm0_pwmh1-0 {
+ atmel,pins =
+ <AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh1_1: pwm0_pwmh1-1 {
+ atmel,pins =
+ <AT91_PIOA 12 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh1_2: pwm0_pwmh1-2 {
+ atmel,pins =
+ <AT91_PIOA 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh1_3: pwm0_pwmh1-3 {
+ atmel,pins =
+ <AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh1_4: pwm0_pwmh1-4 {
+ atmel,pins =
+ <AT91_PIOD 21 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pwm0_pwmh2_0: pwm0_pwmh2-0 {
+ atmel,pins =
+ <AT91_PIOA 13 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh2_1: pwm0_pwmh2-1 {
+ atmel,pins =
+ <AT91_PIOA 25 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh2_2: pwm0_pwmh2-2 {
+ atmel,pins =
+ <AT91_PIOB 4 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh2_3: pwm0_pwmh2-3 {
+ atmel,pins =
+ <AT91_PIOC 19 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh2_4: pwm0_pwmh2-4 {
+ atmel,pins =
+ <AT91_PIOD 22 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pwm0_pwmh3_0: pwm0_pwmh3-0 {
+ atmel,pins =
+ <AT91_PIOA 7 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh3_1: pwm0_pwmh3-1 {
+ atmel,pins =
+ <AT91_PIOA 14 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh3_2: pwm0_pwmh3-2 {
+ atmel,pins =
+ <AT91_PIOA 17 AT91_PERIPH_C AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh3_3: pwm0_pwmh3-3 {
+ atmel,pins =
+ <AT91_PIOC 13 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh3_4: pwm0_pwmh3-4 {
+ atmel,pins =
+ <AT91_PIOC 21 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm0_pwmh3_5: pwm0_pwmh3-5 {
+ atmel,pins =
+ <AT91_PIOD 23 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ };
+
+ pwm1 {
+ pinctrl_pwm1_pwmh0_0: pwm1_pwmh0-0 {
+ atmel,pins =
+ <AT91_PIOA 12 AT91_PERIPH_C AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm1_pwmh0_1: pwm1_pwmh0-1 {
+ atmel,pins =
+ <AT91_PIOD 1 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pwm1_pwmh1_0: pwm1_pwmh1-0 {
+ atmel,pins =
+ <AT91_PIOA 14 AT91_PERIPH_C AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm1_pwmh1_1: pwm1_pwmh1-1 {
+ atmel,pins =
+ <AT91_PIOD 3 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pwm1_pwmh2_0: pwm1_pwmh2-0 {
+ atmel,pins =
+ <AT91_PIOA 31 AT91_PERIPH_D AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm1_pwmh2_1: pwm1_pwmh2-1 {
+ atmel,pins =
+ <AT91_PIOD 5 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+
+ pinctrl_pwm1_pwmh3_0: pwm1_pwmh3-0 {
+ atmel,pins =
+ <AT91_PIOA 8 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ pinctrl_pwm1_pwmh3_1: pwm1_pwmh3-1 {
+ atmel,pins =
+ <AT91_PIOD 7 AT91_PERIPH_B AT91_PINCTRL_NONE>;
+ };
+ };
+
+ ssc {
+ pinctrl_ssc_tx: ssc_tx {
+ atmel,pins =
+ <AT91_PIOB 1 AT91_PERIPH_D AT91_PINCTRL_NONE /* TK */
+ AT91_PIOB 0 AT91_PERIPH_D AT91_PINCTRL_NONE /* TF */
+ AT91_PIOD 26 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* TD */
+ };
+
+ pinctrl_ssc_rx: ssc_rx {
+ atmel,pins =
+ <AT91_PIOA 22 AT91_PERIPH_A AT91_PINCTRL_NONE /* RK */
+ AT91_PIOD 24 AT91_PERIPH_B AT91_PINCTRL_NONE /* RF */
+ AT91_PIOA 10 AT91_PERIPH_C AT91_PINCTRL_NONE>; /* RD */
+ };
+ };
+ };
+
+ chipid: chipid at 0x400e0940 {
+ compatible = "atmel,sama5d2-chipid";
+ reg = <0x400e0940 0xc0>;
+ };
+
+ rstc at 400e1800 {
+ compatible = "atmel,samx7-rstc";
+ reg = <0x400e1800 0x10>;
+ clocks = <&clk_slck>;
+ };
+
+ ssc: ssc at 40004000 {
+ compatible = "atmel,at91sam9g45-ssc";
+ reg = <0x40004000 0x4000>;
+ interrupts = <22>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(32))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(33))>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc_tx &pinctrl_ssc_rx>;
+ clocks = <&ssc_clk>;
+ clock-names = "pclk";
+ status = "disabled";
+ };
+
+ pwm0: pwm at 40020000 {
+ compatible = "atmel,sama5d3-pwm";
+ reg = <0x40020000 0x4000>;
+ interrupts = <31>;
+ #pwm-cells = <3>;
+ clocks = <&pwm0_clk>;
+ status = "disabled";
+ };
+
+ pwm1: pwm at 4005c000 {
+ compatible = "atmel,sama5d3-pwm";
+ reg = <0x4005c000 0x4000>;
+ interrupts = <60>;
+ #pwm-cells = <3>;
+ clocks = <&pwm1_clk>;
+ status = "disabled";
+ };
+
+ watchdog at 400e1850 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0x400e1850 0x10>;
+ interrupts = <4>;
+ clocks = <&clk_slck>;
+ atmel,watchdog-type = "hardware";
+ atmel,reset-type = "all";
+ atmel,dbg-halt;
+ status = "disabled";
+ };
+
+ tcb0: timer at 4000c000 {
+ compatible = "atmel,at91rm9200-tcb";
+ reg = <0x4000c000 0x4000>;
+ interrupts = <23 24 25>;
+ clocks = <&tcb0_clk>, <&tcb1_clk>, <&tcb2_clk>, <&clk_slck>;
+ clock-names = "t0_clk", "t1_clk", "t2_clk", "slow_clk";
+ status = "disabled";
+ };
+
+ tcb1: timer at 40010000 {
+ compatible = "atmel,at91rm9200-tcb";
+ reg = <0x40010000 0x4000>;
+ interrupts = <26 27 28>;
+ clocks = <&tcb3_clk>, <&tcb4_clk>, <&tcb5_clk>, <&clk_slck>;
+ clock-names = "t0_clk", "t1_clk", "t2_clk", "slow_clk";
+ status = "disabled";
+ };
+
+ tcb2: timer at 40014000 {
+ compatible = "atmel,at91rm9200-tcb";
+ reg = <0x40014000 0x4000>;
+ interrupts = <47 48 49>;
+ clocks = <&tcb6_clk>, <&tcb7_clk>, <&tcb8_clk>, <&clk_slck>;
+ clock-names = "t0_clk", "t1_clk", "t2_clk", "slow_clk";
+ status = "disabled";
+ };
+
+ tcb3: timer at 40054000 {
+ compatible = "atmel,at91rm9200-tcb";
+ reg = <0x40054000 0x4000>;
+ interrupts = <50 51 52>;
+ clocks = <&tcb9_clk>, <&tcb10_clk>, <&tcb11_clk>, <&clk_slck>;
+ clock-names = "t0_clk", "t1_clk", "t2_clk", "slow_clk";
+ status = "disabled";
+ };
+
+ dma: dma-controller at 40078000 {
+ compatible = "atmel,sama5d4-dma";
+ reg = <0x40078000 0x4000>;
+ interrupts = <58>;
+ #dma-cells = <1>;
+ clocks = <&dma_clk>;
+ clock-names = "dma_clk";
+ status = "disabled";
+ };
+
+ qspi: qspi at 4007c000 {
+ compatible = "atmel,sama5d2-qspi";
+ reg = <0x4007c000 0x4000>, <0x80000000 0x20000000>;
+ reg-names = "qspi_base", "qspi_mmap";
+ interrupts = <43>;
+ clocks = <&qspi_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi>;
+ status = "disabled";
+ };
+
+ aes at 4006c000 {
+ compatible = "atmel,at91sam9g46-aes";
+ reg = <0x4006c000 0x4000>;
+ interrupts = <56>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(37))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(38))>;
+ dma-names = "tx", "rx";
+ clocks = <&aes_clk>;
+ clock-names = "aes_clk";
+ status = "disabled";
+ };
+
+ i2c0: i2c at 40018000 {
+ compatible = "atmel,sama5d2-i2c";
+ reg = <0x40018000 0x4000>;
+ interrupts = <19>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(14))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(15))>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&twi0_clk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 4001c000 {
+ compatible = "atmel,sama5d2-i2c";
+ reg = <0x4001c000 0x4000>;
+ interrupts = <20>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(16))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(17))>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&twi1_clk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at 40060000 {
+ compatible = "atmel,sama5d2-i2c";
+ reg = <0x40060000 0x4000>;
+ interrupts = <41>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(18))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(19))>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&twi2_clk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "disabled";
+ };
+
+ mmc0: mmc at 40000000 {
+ compatible = "atmel,hsmci";
+ reg = <0x40000000 0x4000>;
+ interrupts = <18>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
+ | AT91_XDMAC_DT_PERID(0))>;
+ dma-names = "rxtx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc_clk_cmd_dat0 &pinctrl_mmc_dat1_3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&mci_clk>;
+ clock-names = "mci_clk";
+ status = "disabled";
+ };
+
+ spi0: spi at 40008000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-spi";
+ reg = <0x40008000 0x4000>;
+ interrupts = <21>;
+ atmel,fifo-size = <0>;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(1))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(2))>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi0>;
+ clocks = <&spi0_clk>;
+ clock-names = "spi_clk";
+ status = "disabled";
+ };
+
+ trng at 4007000 {
+ compatible = "atmel,at91sam9g45-trng";
+ reg = <0x40070000 0x4000>;
+ interrupts = <57>;
+ clocks = <&trng_clk>;
+ status = "disabled";
+ };
+
+ rtc at 400e1860 {
+ compatible = "atmel,at91rm9200-rtc";
+ reg = <0x400e1860 0x30>;
+ interrupts = <2>;
+ clocks = <&clk_slck>;
+ status = "disabled";
+ };
+
+ usart0: serial at 40024000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x40024000 0x4000>;
+ interrupts = <13>;
+ clocks = <&usart0_clk>;
+ clock-names = "usart";
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(7))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(8))>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart0>;
+ status = "disabled";
+ };
+
+ usart1: serial at 40028000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x40028000 0x4000>;
+ interrupts = <14>;
+ clocks = <&usart1_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(9))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(10))>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1>;
+ status = "disabled";
+ };
+
+ usart2: serial at 4002c000 {
+ compatible = "atmel,same70-usart";
+ reg = <0x4002c000 0x4000>;
+ interrupts = <15>;
+ clocks = <&usart2_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(11))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(12))>;
+ dma-names = "tx", "rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart2>;
+ status = "disabled";
+ };
+
+ uart0: serial at 400e0800 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x400e0800 0x140>;
+ interrupts = <7>;
+ clocks = <&uart0_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(20))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(21))>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart1: serial at 400e0a00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x400e0a00 0x200>;
+ interrupts = <8>;
+ clocks = <&uart1_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(22))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(23))>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart2: serial at 400e1a00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x400e1a00 0x200>;
+ interrupts = <44>;
+ clocks = <&uart2_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(24))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(25))>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart3: serial at 400e1c00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x400e1c00 0x200>;
+ interrupts = <45>;
+ clocks = <&uart3_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(26))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(27))>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ uart4: serial at 400e1e00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0x400e1e00 0x200>;
+ interrupts = <46>;
+ clocks = <&uart4_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(28))>,
+ <&dma
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(29))>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/6] ARM: at91: handle CONFIG_PM for armv7m configurations
From: Alexandre Belloni @ 2016-10-20 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020094135.18221-1-alexandre.belloni@free-electrons.com>
There is currently no PM support for samx7 but the symbol can still be
selected. This avoids compilation issues.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/mach-at91/Kconfig | 6 ++++++
arch/arm/mach-at91/Makefile | 3 +--
arch/arm/mach-at91/samx7.c | 9 +++++++++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index bade64e0cb49..34fa561aa853 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -59,6 +59,7 @@ config SOC_AT91RM9200
bool "AT91RM9200"
depends on ARCH_MULTI_V4T
select ATMEL_AIC_IRQ
+ select ATMEL_PM if PM
select ATMEL_ST
select CPU_ARM920T
select HAVE_AT91_USB_CLK
@@ -72,6 +73,7 @@ config SOC_AT91SAM9
bool "AT91SAM9"
depends on ARCH_MULTI_V5
select ATMEL_AIC_IRQ
+ select ATMEL_PM if PM
select ATMEL_SDRAMC
select CPU_ARM926T
select HAVE_AT91_SMD
@@ -130,9 +132,13 @@ config SOC_SAM_V7
config SOC_SAMA5
bool
select ATMEL_AIC5_IRQ
+ select ATMEL_PM if PM
select ATMEL_SDRAMC
select MEMORY
select SOC_SAM_V7
select SRAM if PM
+config ATMEL_PM
+ bool
+
endif
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 84956a18d604..116691714bb8 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -10,8 +10,7 @@ obj-$(CONFIG_SOC_SAMA5) += sama5.o
obj-$(CONFIG_SOC_SAMX7) += samx7.o
# Power Management
-obj-$(CONFIG_PM) += pm.o
-obj-$(CONFIG_PM) += pm_suspend.o
+obj-$(CONFIG_ATMEL_PM) += pm.o pm_suspend.o
ifeq ($(CONFIG_CPU_V7),y)
AFLAGS_pm_suspend.o := -march=armv7-a
diff --git a/arch/arm/mach-at91/samx7.c b/arch/arm/mach-at91/samx7.c
index bd33bc56278e..5bd76cb5076c 100644
--- a/arch/arm/mach-at91/samx7.c
+++ b/arch/arm/mach-at91/samx7.c
@@ -16,6 +16,15 @@
#include "generic.h"
#include "soc.h"
+#ifdef CONFIG_PM
+/* This function has to be defined for various drivers that are using it */
+int at91_suspend_entering_slow_clock(void)
+{
+ return 0;
+}
+EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
+#endif
+
static const struct at91_soc samx7_socs[] = {
AT91_SOC(SAME70Q21_CIDR_MATCH, SAME70Q21_EXID_MATCH,
"same70q21", "samx7"),
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox