The Jetson TX1 Development Kit is the successor of the Jetson TK1. The
Jetson TX1 is composed of the Jetson TX1 module (P2180) that connects to
the P2597 I/O board. It comes with a 1200x1920 MIPI DSI panel connected
via the P2597's display connector.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The NVIDIA P2597 I/O board is a carrier board for the Jetson TX1 module
and together they are also known as the Jetson TX1 Developer Kit. The
I/O board provides an RJ45 connector routed to the network adapter that
is part of the Jetson TX1 module. It exposes many other connectors such
as SATA, USB 3.0, HDMI, JTAG and PCIe, among others, as well. Dedicated
connectors allow display and camera modules to be attached. A full-size
SD slot is provided to extend storage beyond the 32 GiB of eMMC found
on the Jetson TX1 module.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The NVIDIA Jetson TX1 is a processor module that features a Tegra210 SoC
with 4 GiB of LPDDR4 RAM attached, a 32 GiB eMMC and other essentials.

It is typically connected to some I/O board (such as the P2597) that has
the connectors needed to hook it up to the outside world.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The NVIDIA P2571 is an internal reference design that's very similar to
the P2371, but targetting different use-cases.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The NVIDIA P2371 is an internal reference design that uses a P2530
processor module hooked up to a P2595 I/O board and an optional display
module for a 1200x1920 MIPI DSI panel.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The NVIDIA P2595 I/O board is used in several reference designs and has
the connectors to connect the P2530 compute module to the outside world.
It features a USB 3.0 network adapter, a USB 3.0 port, an HDMI port, a
SATA port, an audio codec, a microSD card slot and a display connector,
among others.
Signed-off-by: NThierry Reding <treding@nvidia.com>

The NVIDIA P2530 is a processor module used in several reference designs
that features a Tegra210 SoC, 4 GiB of LPDDR4 RAM, 16 GiB eMMC and other
essentials. It is typically connected to some I/O board that provides
the connectors needed to hook it up to the outside world.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Also known as Tegra X1, the Tegra210 has four Cortex-A57 cores paired
with four Cortex-A53 cores in a switched configuration. It features a
GPU using the Maxwell architecture with support for DX11, SM4, OpenGL
4.5, OpenGL ES 3.1 and providing 256 CUDA cores. It supports hardware
accelerated en- and decoding of various video standards including
H.265, H.264 and VP8 at 4K resolutions and up to 60 fps.

Besides the multimedia features it also comes with a variety of I/O
controllers such as GPIO, I2C, SPI, SDHCI, PCIe, SATA and XHCI, to
name only a few.

Add a SoC-level device tree file that describes most of the hardware
available on the SoC. This includes only hardware for which a device
tree binding already exists or which is trivial to describe.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Norrin is a Tegra132-based FFD used as reference platform within NVIDIA.

Based on work by Allen Martin <amartin@nvidia.com>

Cc: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Allen Martin <amartin@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

NVIDIA Tegra132 (also known as Tegra K1 64-bit) is a variant of Tegra124
but with 2 Denver CPUs instead of the 4+1 Cortex-A15. This adds the DTSI
file for the SoC, which is mostly similar to the one for Tegra124.

Based on work by Allen Martin <amartin@nvidia.com>

Cc: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Allen Martin <amartin@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Move per-SoC generation Kconfig symbols to drivers/soc/tegra/Kconfig to
gather them all in a single place. This directory is a natural location
for these options since it already contains the drivers that are shared
across 32-bit and 64-bit ARM architectures.
Signed-off-by: NThierry Reding <treding@nvidia.com>

hw_breakpoint_restore is only used within suspend.c, so it can be
declared static.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

split_pud and fixup_executable are only called from within mmu.c, so
they can be declared static.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

of_parse_and_init_cpus is only called from within smp.c, so it can be
declared static.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

We should always use linux/types.h instead of asm/types.h for
consistency, and Kbuild actually warns about it:

./usr/include/asm/kvm.h:35: include of <linux/types.h> is preferred over <asm/types.h>

This patch does as Kbuild asks us.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

On a cross-toolchain without glibc support, libgcov may not be
available, and attempting to build an arm64 kernel with GCOV
enabled then results in a build error:

/home/arnd/cross-gcc/lib/gcc/aarch64-linux/5.2.1/../../../../aarch64-linux/bin/ld: cannot find -lgcov

We don't really want to link libgcov into the vdso anyway, so
this patch just disables GCOV in the vdso directory, just as
we do for most other architectures.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

cpus_have_hwcap() is defined as a 'static' function an only used in
one place that is inside of an #ifdef, so we get a warning when
the only user is disabled:

arch/arm64/kernel/cpufeature.c:699:13: warning: 'cpus_have_hwcap' defined but not used [-Wunused-function]

This marks the function as __maybe_unused, so the compiler knows that
it can drop the function definition without warning about it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 37b01d53 ("arm64/HWCAP: Use system wide safe values")
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

FRAME_POINTER is defined in lib/Kconfig.debug, it is unnecessary to redefine it
in arch/arm64/Kconfig.debug.

ARM64 depends on frame pointer to get correct stack trace (also selecting
ARCH_WANT_FRAME_POINTERS). However, the lib/Kconfig.debug definition allows
such option to be disabled. This patch forces FRAME_POINTER always on on arm64.
Signed-off-by: NYang Shi <yang.shi@linaro.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The mapping permissions of the FDT are set to 'PAGE_KERNEL | PTE_RDONLY'
in an attempt to map the FDT as read-only. However, not only does this
break at build time under STRICT_MM_TYPECHECKS (since the two terms are
of different types in that case), it also results in both the PTE_WRITE
and PTE_RDONLY attributes to be set, which means the region is still
writable under ARMv8.1 DBM (and an attempted write will simply clear the
PT_RDONLY bit).

So instead, define PAGE_KERNEL_RO (which already has an established
meaning across architectures) and use that instead.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The new page table code that manipulates the PTE_CONT flags does so
in a way that is inconsistent with STRICT_MM_TYPECHECKS. Fix it by
using the correct combination of __pgprot() and pgprot_val().
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

__GFP_WAIT was renamed for __GFP_RECLAIM and the gfpflags_allow_blocking()
helper was added.

Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts.  They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve".  __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".

Over time, callers had a requirement to not block when fallback options
were available.  Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative.  High priority users continue to use
__GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress clear
  __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
  into this category where kswapd will still be woken but atomic reserves
  are not used as there is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL.  They may
now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Acked-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Turns out in the case of modulo by zero in a BPF program:
	A = A % X;  (X == 0)
the expected behavior is to terminate with return value 0.

The bug in JIT is exposed by a new test case [1].

[1] https://lkml.org/lkml/2015/11/4/499Signed-off-by: NZi Shen Lim <zlim.lnx@gmail.com>
Reported-by: NYang Shi <yang.shi@linaro.org>
Reported-by: NXi Wang <xi.wang@gmail.com>
CC: Alexei Starovoitov <ast@plumgrid.com>
Fixes: e54bcde3 ("arm64: eBPF JIT compiler")
Cc: <stable@vger.kernel.org> # 3.18+
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

In the case of division by zero in a BPF program:
	A = A / X;  (X == 0)
the expected behavior is to terminate with return value 0.

This is confirmed by the test case introduced in commit 86bf1721
("test_bpf: add tests checking that JIT/interpreter sets A and X to 0.").
Reported-by: NYang Shi <yang.shi@linaro.org>
Tested-by: NYang Shi <yang.shi@linaro.org>
CC: Xi Wang <xi.wang@gmail.com>
CC: Alexei Starovoitov <ast@plumgrid.com>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-kernel@vger.kernel.org
Fixes: e54bcde3 ("arm64: eBPF JIT compiler")
Cc: <stable@vger.kernel.org> # 3.18+
Signed-off-by: NZi Shen Lim <zlim.lnx@gmail.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

CONFIG_CRYPTO_CRC32_ARM64 has been around since commit f6f203fa
("crypto: crc32 - Add ARM64 CRC32 hw accelerated module") but defconfig
did not automatically enable it.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The current arm64 __cmpxchg_double{_mb} implementations carry out the
compare exchange by first comparing the old values passed in to the
values read from the pointer provided and by stashing the cumulative
bitwise difference in a 64-bit register.

By comparing the register content against 0, it is possible to detect if
the values read differ from the old values passed in, so that the compare
exchange detects whether it has to bail out or carry on completing the
operation with the exchange.

Given the current implementation, to detect the cmpxchg operation
status, the __cmpxchg_double{_mb} functions should return the 64-bit
stashed bitwise difference so that the caller can detect cmpxchg failure
by comparing the return value content against 0. The current implementation
declares the return value as an int, which means that the 64-bit
value stashing the bitwise difference is truncated before being
returned to the __cmpxchg_double{_mb} callers, which means that
any bitwise difference present in the top 32 bits goes undetected,
triggering false positives and subsequent kernel failures.

This patch fixes the issue by declaring the arm64 __cmpxchg_double{_mb}
return values as a long, so that the bitwise difference is
properly propagated on failure, restoring the expected behaviour.

Fixes: e9a4b795 ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU")
Cc: <stable@vger.kernel.org> # 4.3+
Cc: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

After discussing on the mailing list it turns out that
accessing the flash memory from the kernel can disrupt CPU
sleep states and CPU hotplugging, so let's disable this
DT node by default. Setups that want to access the flash
can modify this entry to enable the flash again.

Quoting Sudeep Holla: "the firmware assumes the flash is
always in read mode while Linux leaves NOR flash in
"read id" mode after initialization."
Reported-by: NSudeep Holla <sudeep.holla@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@arm.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Fixes: 5078f77e "ARM64: juno: add NOR flash to device tree"
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Make sure that the task scheduler domain hierarchy is set-up correctly
on systems with single or multi-cluster topology.
Signed-off-by: NDietmar Eggemann <dietmar.eggemann@arm.com>
Acked-by: NPunit Agrawal <punit.agrawal@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Now that we added special handling to the C files in libstub, move
the one remaining arm64 specific EFI stub C file to libstub as
well, so that it gets the same treatment. This should prevent future
changes from resulting in binaries that may execute incorrectly in
UEFI context.

With efi-entry.S the only remaining EFI stub source file under
arch/arm64, we can also simplify the Makefile logic somewhat.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk>
Tested-by: NJeremy Linton <jeremy.linton@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

A kernel built with DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA doesn't
have .text aligned to a page boundary, though fixup_executable works at
page-granularity thanks to its use of create_mapping. If .text is not
page-aligned, the first page it exists in may be marked non-executable,
leading to failures when an attempt is made to execute code in said
page.

This patch upgrades ALIGN_DEBUG_RO and ALIGN_DEBUG_RO_MIN to force page
alignment for DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA kernels,
ensuring that all sections with specific RWX permission requirements are
mapped with the correct permissions.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Reported-by: NJeremy Linton <jeremy.linton@arm.com>
Reviewed-by: NLaura Abbott <laura@labbott.name>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: da141706 ("arm64: add better page protections to arm64")
Cc: <stable@vger.kernel.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Trying to build with CONFIG_ZONE_DMA=n leaves visible references
to the now-undefined ZONE_DMA, resulting in a syntax error.

Hide the references behind an #ifdef instead of using IS_ENABLED.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_<mode> and LR_<mode> backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.

Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The current arm64 Image relocation code in the UEFI stub assumes that
the dram_base argument it receives is always a multiple of 2 MB. In
reality, it is simply the lowest start address of all RAM entries in
the UEFI memory map, which means it could be any multiple of 4 KB.

Since the arm64 kernel Image needs to reside TEXT_OFFSET bytes beyond
a 2 MB aligned base, or it will fail to boot, make sure we round dram_base
to 2 MB before using it to calculate the relocation address.

Fixes: e38457c3 ("arm64: efi: prefer AllocatePages() over efi_low_alloc() for vmlinux")
Reported-by: NTimur Tabi <timur@codeaurora.org>
Tested-by: NTimur Tabi <timur@codeaurora.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Increase the standard cacheline size to avoid having locks in the same
cacheline.

Cavium's ThunderX core implements cache lines of 128 byte size. With
current granulare size of 64 bytes (L1_CACHE_SHIFT=6) two locks could
share the same cache line leading a performance degradation.
Increasing the size fixes that.

Increasing the size has no negative impact to cache invalidation on
systems with a smaller cache line. There is an impact on memory usage,
but that's not too important for arm64 use cases.
Signed-off-by: NTirumalesh Chalamarla <tchalamarla@cavium.com>
Signed-off-by: NRobert Richter <rrichter@cavium.com>
Acked-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The comparison between TASK_SIZE_64 and MODULES_VADDR does not
make any sense on arm64, it is simply something that has been
carried over from the ARM port which arm64 is based on. So drop it.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

It allows a selectable timer interrupt frequency of 100, 250, 300 and 1000 HZ.
We will get better performance when choose a suitable frequency in some scene.

Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

The <linux/mm.h> already provides the PAGE_ALIGNED macro. Let's
use this macro instead of IS_ALIGNED and passing PAGE_SIZE directly.
Signed-off-by: NAlexander Kuleshov <kuleshovmail@gmail.com>
Acked-by: NLaura Abbott <laura@labbott.name>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

test_bit and set_bit take the bit number to operate on, rather than a
mask. This patch fixes the ICACHEF_* definitions so that they represent
the bit index in __icache_flags as opposed to the mask returned by the
BIT macro.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

enable_cpu_capabilities is only called from within cpufeature.c, so it
can be declared static.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

This reverts commit e306dfd0.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Cc: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>