path: root/arch/arm64 (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2017-10-06arm64: Ensure fpsimd support is ready before userspace is activeSuzuki K Poulose1-1/+1
We register the pm/hotplug callbacks for FPSIMD as late_initcall, which happens after the userspace is active (from initramfs via populate_rootfs, a rootfs_initcall). Make sure we are ready even before the userspace could potentially use it, by promoting to a core_initcall. Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Dave Martin <dave.martin@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-10-06arm64: Ensure the instruction emulation is ready for userspaceSuzuki K Poulose2-2/+2
We trap and emulate some instructions (e.g, mrs, deprecated instructions) for the userspace. However the handlers for these are registered as late_initcalls and the userspace could be up and running from the initramfs by that time (with populate_rootfs, which is a rootfs_initcall()). This could cause problems for the early applications ending up in failure like : [ 11.152061] modprobe[93]: undefined instruction: pc=0000ffff8ca48ff4 This patch promotes the specific calls to core_initcalls, which are guaranteed to be completed before we hit userspace. Cc: stable@vger.kernel.org Cc: Dave Martin <dave.martin@arm.com> Cc: Matthias Brugger <mbrugger@suse.com> Cc: James Morse <james.morse@arm.com> Reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-10-04arm64: Use larger stacks when KASAN is selectedMark Rutland1-3/+6
AddressSanitizer instrumentation can significantly bloat the stack, and with GCC 7 this can result in stack overflows at boot time in some configurations. We can avoid this by doubling our stack size when KASAN is in use, as is already done on x86 (and has been since KASAN was introduced). Regardless of other patches to decrease KASAN's stack utilization, kernels built with KASAN will always require more stack space than those built without, and we should take this into account. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-10-02arm64: fix misleading data abort decodingMark Rutland1-1/+1
Currently data_abort_decode() dumps the ISS field as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print as hexadecimal, as was intended. Fixes: 1f9b8936f36f4a8e ("arm64: Decode information from ESR upon mem faults") Reviewed-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Julien Thierry <julien.thierry@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-29arm64: fault: Route pte translation faults via do_translation_faultWill Deacon1-1/+1
We currently route pte translation faults via do_page_fault, which elides the address check against TASK_SIZE before invoking the mm fault handling code. However, this can cause issues with the path walking code in conjunction with our word-at-a-time implementation because load_unaligned_zeropad can end up faulting in kernel space if it reads across a page boundary and runs into a page fault (e.g. by attempting to read from a guard region). In the case of such a fault, load_unaligned_zeropad has registered a fixup to shift the valid data and pad with zeroes, however the abort is reported as a level 3 translation fault and we dispatch it straight to do_page_fault, despite it being a kernel address. This results in calling a sleeping function from atomic context: BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:313 in_atomic(): 0, irqs_disabled(): 0, pid: 10290 Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [...] [<ffffff8e016cd0cc>] ___might_sleep+0x134/0x144 [<ffffff8e016cd158>] __might_sleep+0x7c/0x8c [<ffffff8e016977f0>] do_page_fault+0x140/0x330 [<ffffff8e01681328>] do_mem_abort+0x54/0xb0 Exception stack(0xfffffffb20247a70 to 0xfffffffb20247ba0) [...] [<ffffff8e016844fc>] el1_da+0x18/0x78 [<ffffff8e017f399c>] path_parentat+0x44/0x88 [<ffffff8e017f4c9c>] filename_parentat+0x5c/0xd8 [<ffffff8e017f5044>] filename_create+0x4c/0x128 [<ffffff8e017f59e4>] SyS_mkdirat+0x50/0xc8 [<ffffff8e01684e30>] el0_svc_naked+0x24/0x28 Code: 36380080 d5384100 f9400800 9402566d (d4210000) ---[ end trace 2d01889f2bca9b9f ]--- Fix this by dispatching all translation faults to do_translation_faults, which avoids invoking the page fault logic for faults on kernel addresses. Cc: <stable@vger.kernel.org> Reported-by: Ankit Jain <ankijain@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-29arm64: mm: Use READ_ONCE when dereferencing pointer to pte tableWill Deacon1-1/+1
On kernels built with support for transparent huge pages, different CPUs can access the PMD concurrently due to e.g. fast GUP or page_vma_mapped_walk and they must take care to use READ_ONCE to avoid value tearing or caching of stale values by the compiler. Unfortunately, these functions call into our pgtable macros, which don't use READ_ONCE, and compiler caching has been observed to cause the following crash during ext4 writeback: PC is at check_pte+0x20/0x170 LR is at page_vma_mapped_walk+0x2e0/0x540 [...] Process doio (pid: 2463, stack limit = 0xffff00000f2e8000) Call trace: [<ffff000008233328>] check_pte+0x20/0x170 [<ffff000008233758>] page_vma_mapped_walk+0x2e0/0x540 [<ffff000008234adc>] page_mkclean_one+0xac/0x278 [<ffff000008234d98>] rmap_walk_file+0xf0/0x238 [<ffff000008236e74>] rmap_walk+0x64/0xa0 [<ffff0000082370c8>] page_mkclean+0x90/0xa8 [<ffff0000081f3c64>] clear_page_dirty_for_io+0x84/0x2a8 [<ffff00000832f984>] mpage_submit_page+0x34/0x98 [<ffff00000832fb4c>] mpage_process_page_bufs+0x164/0x170 [<ffff00000832fc8c>] mpage_prepare_extent_to_map+0x134/0x2b8 [<ffff00000833530c>] ext4_writepages+0x484/0xe30 [<ffff0000081f6ab4>] do_writepages+0x44/0xe8 [<ffff0000081e5bd4>] __filemap_fdatawrite_range+0xbc/0x110 [<ffff0000081e5e68>] file_write_and_wait_range+0x48/0xd8 [<ffff000008324310>] ext4_sync_file+0x80/0x4b8 [<ffff0000082bd434>] vfs_fsync_range+0x64/0xc0 [<ffff0000082332b4>] SyS_msync+0x194/0x1e8 This is because page_vma_mapped_walk loads the PMD twice before calling pte_offset_map: the first time without READ_ONCE (where it gets all zeroes due to a concurrent pmdp_invalidate) and the second time with READ_ONCE (where it sees a valid table pointer due to a concurrent pmd_populate). However, the compiler inlines everything and caches the first value in a register, which is subsequently used in pte_offset_phys which returns a junk pointer that is later dereferenced when attempting to access the relevant pte. This patch fixes the issue by using READ_ONCE in pte_offset_phys to ensure that a stale value is not used. Whilst this is a point fix for a known failure (and simple to backport), a full fix moving all of our page table accessors over to {READ,WRITE}_ONCE and consistently using READ_ONCE in page_vma_mapped_walk is in the works for a future kernel release. Cc: Jon Masters <jcm@redhat.com> Cc: Timur Tabi <timur@codeaurora.org> Cc: <stable@vger.kernel.org> Fixes: f27176cfc363 ("mm: convert page_mkclean_one() to use page_vma_mapped_walk()") Tested-by: Richard Ruigrok <rruigrok@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-27arm64: Make sure SPsel is always setMarc Zyngier1-0/+1
When the kernel is entered at EL2 on an ARMv8.0 system, we construct the EL1 pstate and make sure this uses the the EL1 stack pointer (we perform an exception return to EL1h). But if the kernel is either entered at EL1 or stays at EL2 (because we're on a VHE-capable system), we fail to set SPsel, and use whatever stack selection the higher exception level has choosen for us. Let's not take any chance, and make sure that SPsel is set to one before we decide the mode we're going to run in. Cc: <stable@vger.kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-26arm64: dts: rockchip: add the grf clk for dw-mipi-dsi on rk3399Nickey Yang1-2/+2
The clk of grf must be enabled before writing grf register for rk3399. Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> [the grf clock is already part of the binding since march 2017] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-09-19arm64: dts: rockchip: Correct MIPI DPHY PLL clock on rk3399Nickey Yang1-1/+1
There is a further gate in between the mipidphy reference clock and the actual ref-clock input to the dsi host, making the clock hirarchy look like clk_24m --> Gate11[14] --> clk_mipidphy_ref --> Gate21[0] --> clk_dphy_pll Fix the clock reference so that the whole clock subtree gets enabled when the dsi host needs it. Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> [amended commit message] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-09-19arm64: dt marvell: Fix AP806 system controller sizeBaruch Siach1-2/+2
Extend the container size to 0x2000 to include the gpio controller at offset 0x1040. While at it, add start address notation to the gpio node name to match its 'offset' property. Fixes: 63dac0f4924b ("arm64: dts: marvell: add gpio support for Armada 7K/8K") Cc: <stable@vger.kernel.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-09-18arm64: ensure the kernel is compiled for LP64Andrew Pinski1-0/+5
The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Andrew Pinski <Andrew.Pinski@caviumnetworks.com> Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com> Reviewed-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-18arm64: relax assembly code alignment from 16 byte to 4 byteMasahiro Yamada1-2/+2
Aarch64 instructions must be word aligned. The current 16 byte alignment is more than enough. Relax it into 4 byte alignment. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-18arm64: efi: Don't include EFI fpsimd save/restore code in non-EFI kernelsDave Martin1-0/+4
__efi_fpsimd_begin()/__efi_fpsimd_end() are for use when making EFI calls only, so using them in non-EFI kernels is not allowed. This patch compiles them out if CONFIG_EFI is not set. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-17arm64/syscalls: Move address limit check in loopThomas Garnier1-3/+3
A bug was reported on ARM where set_fs might be called after it was checked on the work pending function. ARM64 is not affected by this bug but has a similar construct. In order to avoid any similar problems in the future, the addr_limit_user_check function is moved at the beginning of the loop. Fixes: cf7de27ab351 ("arm64/syscalls: Check address limit on user-mode return") Reported-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Thomas Garnier <thgarnie@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Pratyush Anand <panand@redhat.com> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Will Drewry <wad@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Andy Lutomirski <luto@amacapital.net> Cc: David Howells <dhowells@redhat.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-api@vger.kernel.org Cc: Yonghong Song <yhs@fb.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1504798247-48833-5-git-send-email-keescook@chromium.org
2017-09-17Revert "arm64: dts: rockchip: Add basic cpu frequencies for RK3368"Heiko Stuebner1-70/+2
This reverts commit 6f2dea1f5fdb73eb2e050d9ebe990121d557e519. Without accurate cpu regulators being set for boards this will wreak havoc when cpufreq-dt begins to set new frequencies without adjusting the core frequency. Additionally the rk3368 has an unsolved issue in that it has two separate cpu clusters with separate clock lines but only one cpu supply regulator for both clusters, which causes even more problems. While it seems that originally only one cluster was supposed to be active at a time (big or little), talking with real users of the hardware revealed that having all 8 cores accessible at 1.2GHz max is way more liked than having 4 cores at 1.5GHz max. Such an approach needs changes to cpufreq and/or opp though to control the two separate clock lines when setting both clusters to the same frequencies. In any case, having the OPPs in the dts at this point in time is undesireable, so remove them again for now. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-09-13arm64: stacktrace: avoid listing stacktrace functions in stacktracePrakash Gupta1-5/+13
The stacktraces always begin as follows: [<c00117b4>] save_stack_trace_tsk+0x0/0x98 [<c0011870>] save_stack_trace+0x24/0x28 ... This is because the stack trace code includes the stack frames for itself. This is incorrect behaviour, and also leads to "skip" doing the wrong thing (which is the number of stack frames to avoid recording.) Perversely, it does the right thing when passed a non-current thread. Fix this by ensuring that we have a known constant number of frames above the main stack trace function, and always skip these. This was fixed for arch arm by commit 3683f44c42e9 ("ARM: stacktrace: avoid listing stacktrace functions in stacktrace") Link: http://lkml.kernel.org/r/1504078343-28754-1-git-send-email-guptap@codeaurora.org Signed-off-by: Prakash Gupta <guptap@codeaurora.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Michal Hocko <mhocko@suse.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will.deacon@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-08treewide: make "nr_cpu_ids" unsignedAlexey Dobriyan1-1/+1
First, number of CPUs can't be negative number. Second, different signnnedness leads to suboptimal code in the following cases: 1) kmalloc(nr_cpu_ids * sizeof(X)); "int" has to be sign extended to size_t. 2) while (loff_t *pos < nr_cpu_ids) MOVSXD is 1 byte longed than the same MOV. Other cases exist as well. Basically compiler is told that nr_cpu_ids can't be negative which can't be deduced if it is "int". Code savings on allyesconfig kernel: -3KB add/remove: 0/0 grow/shrink: 25/264 up/down: 261/-3631 (-3370) function old new delta coretemp_cpu_online 450 512 +62 rcu_init_one 1234 1272 +38 pci_device_probe 374 399 +25 ... pgdat_reclaimable_pages 628 556 -72 select_fallback_rq 446 369 -77 task_numa_find_cpu 1923 1807 -116 Link: http://lkml.kernel.org/r/20170819114959.GA30580@avx2 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-05ARM64: dts: meson-gxbb: nanopi-k2: enable sdr104 modeJerome Brunet1-1/+2
SDR104 seems to be OK on the nanopi-k2 SBC so enable it Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson-gxbb: nanopi-k2: enable sdcard UHS modesJerome Brunet1-0/+3
Enable UHS modes, up to SDR50, on the nanopi-k2 SBC. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson-gxbb: p20x: enable sdcard UHS modesJerome Brunet1-0/+3
Enable sdcard UHS modes, up to SDR50, on p20x based boards. While the s905 supports SDR104 mode, it appears that the PCB of p20x based boards can't cope with a rate as high as 200Mhz. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson-gxl: libretech-cc: enable high speed modesJerome Brunet1-0/+4
Enable sdcard UHS modes up to SDR50. Unfortunately, it seems the PCB of the libretech-cc cannot handle SDR104 at 200Mhz reliably. Also enable eMMC DDR52 mode. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson-gxl: libretech-cc: add card regulator settle timesJerome Brunet1-0/+3
Changing the card voltage on the cc is not instantaneous, especially when switching from 3.3v to 1.8v. It take at least 30ms for the regulator to go from 3.3v to 1.8v. Add margin to that to make sure we don't upset the sdcard during the voltage switch Fixes: 61ff2af9b278 ("ARM64: dts: fixup libretech cc definition") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson-gxbb: nanopi-k2: add card regulator settle timesJerome Brunet1-0/+3
Changing the card voltage on the nanopi-k2 is not instantaneous, especially when switching from 3.3v to 1.8v. It take at least 3ms for the regulator to go from 3.3v to 1.8v. Add margin to that to make sure we don't upset the sdcard during the voltage switch Fixes: 9bc7ffb08daf ("arm64: dts: amlogic: Add NanoPi K2") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson: add mmc clk gate pinsJerome Brunet13-31/+126
Add the pinctrl to switch mmc clk pins in gpio (pulled down) mode. This is necessary to be able to gate the clk outside of the SoC while keeping it running in the controller Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson: remove cap-sd-highspeed from emmc nodesJerome Brunet11-11/+0
It does not make much sense to define cap-sd-highspeed in the emmc nodes Just remove it. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05ARM64: dts: meson-gx: Use correct mmc clock source 0Jerome Brunet2-6/+6
Now that the clock source 0 is properly described in the CCF, use it instead of assuming the default value (xtal) Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2017-09-05KVM: arm/arm64: Extract GICv3 max APRn index calculationChristoffer Dall1-20/+3
As we are about to access the APRs from the GICv2 uaccess interface, make this logic generally available. Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
2017-09-05KVM: arm/arm64: Fix guest external abort matchingJames Morse1-5/+19
The ARM-ARM has two bits in the ESR/HSR relevant to external aborts. A range of {I,D}FSC values (of which bit 5 is always set) and bit 9 'EA' which provides: > an IMPLEMENTATION DEFINED classification of External Aborts. This bit is in addition to the {I,D}FSC range, and has an implementation defined meaning. KVM should always ignore this bit when handling external aborts from a guest. Remove the ESR_ELx_EA definition and rewrite its helper kvm_vcpu_dabt_isextabt() to check the {I,D}FSC range. This merges kvm_vcpu_dabt_isextabt() and the recently added is_abort_sea() helper. CC: Tyler Baicar <tbaicar@codeaurora.org> Reported-by: gengdongjiu <gengdj.1984@gmail.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@linaro.org>
2017-08-31KVM: update to new mmu_notifier semantic v2Jérôme Glisse1-6/+0
Calls to mmu_notifier_invalidate_page() were replaced by calls to mmu_notifier_invalidate_range() and are now bracketed by calls to mmu_notifier_invalidate_range_start()/end() Remove now useless invalidate_page callback. Changed since v1 (Linus Torvalds) - remove now useless kvm_arch_mmu_notifier_invalidate_page() Signed-off-by: Jérôme Glisse <jglisse@redhat.com> Tested-by: Mike Galbraith <efault@gmx.de> Tested-by: Adam Borowski <kilobyte@angband.pl> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: kvm@vger.kernel.org Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-08-31arm64: dts: ls1046a: Add MSI dts nodeMinghuan Lian1-0/+31
LS1046a includes 3 MSI controllers. Each controller supports 128 interrupts. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31arm64: dts: ls1043a: Share all MSIsMinghuan Lian1-3/+3
In order to maximize the use of MSI, a PCIe controller will share all MSI controllers. The patch changes "msi-parent" to refer to all MSI controller dts nodes. Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31arm64: dts: ls1043a: Fix typo of MSI compatible stringMinghuan Lian1-3/+3
"1" should be replaced by "l". This is a typo. The patch is to fix it. Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE interrupt maskingMarc Zyngier1-0/+2
When masking/unmasking a doorbell interrupt, it is necessary to issue an invalidation to the corresponding redistributor. We use the DirectLPI feature by writting directly to the corresponding redistributor. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPENDBASER/VPROPBASER accessorsMarc Zyngier1-0/+5
V{PEND,PROP}BASER being 64bit registers, they need some ad-hoc accessors on 32bit, specially given that VPENDBASER contains a Valid bit, making the access a bit convoluted. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-30arm64: dts: marvell: fix number of GPIOs in Armada AP806 descriptionThomas Petazzoni1-2/+2
The Armada AP806 has 20 pins, and therefore 20 GPIOs (from 0 to 19 included) and not 19 pins. Therefore, we fix the Device Tree description for the GPIO controller. Before this patch: $ cat /sys/kernel/debug/pinctrl/f06f4000.system-controller:pinctrl/gpio-ranges GPIO ranges handled: 0: mvebu-gpio GPIOS [0 - 19] PINS [0 - 19] 0: f06f4000.system-controller:gpio GPIOS [0 - 18] PINS [0 - 18] After this patch: $ cat /sys/kernel/debug/pinctrl/f06f4000.system-controller:pinctrl/gpio-ranges GPIO ranges handled: 0: mvebu-gpio GPIOS [0 - 19] PINS [0 - 19] 0: f06f4000.system-controller:gpio GPIOS [0 - 19] PINS [0 - 19] Fixes: 63dac0f4924b9 ("arm64: dts: marvell: add gpio support for Armada 7K/8K") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-08-30arm64: dts: marvell: mcbin: enable more networking portsAntoine Tenart1-0/+30
This patch enables the two GE/SFP ports. They are configured in 10GKR mode by default. To do this the cpm_xdmio is enabled as well, and two phy descriptions are added. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Tested-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-08-30arm64: dts: marvell: add a reference to the sysctrl syscon in the ppv2 nodeAntoine Tenart2-0/+2
The network driver on Marvell SoC (7k/8k) needs to access some registers in the system controller to configure its ports at runtime. This patch adds a phandle reference to the syscon system controller node in the ppv2 node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Tested-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-08-30arm64: dts: marvell: add TX interrupts for PPv2.2Thomas Petazzoni2-6/+42
This commit updates the Marvell Armada 7K/8K Device Tree to describe the TX interrupts of the Ethernet controllers, in both the master and slave CP110s. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-08-29arm64: defconfig: enable rockchip graphicsHeiko Stuebner1-0/+8
Enable the graphics-related options needed by Rockchip boards. This includes the pwm-backlight which will be needed by the internal displays used on Gru Chrome-devices. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Mark yao <mark.yao@rock-chips.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2017-08-29arm64: dts: rockchip: convert PCIe to use per-lane PHYs for rk3339Shawn Lin1-3/+5
Convert all RK3399 platforms to use per-lane PHY model in order to save more power by idling unused lane(s). Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Brian Norris <briannorris@chromium.org>
2017-08-29arm64: dts: uniphier: add PXs3 SoC supportMasahiro Yamada3-1/+431
Initial support for PXs3 SoC and its reference development board. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-08-28arm64: dts: uniphier: fix size of sdctrl nodeMasahiro Yamada1-1/+1
All registers are located within 0x400 size from the base address. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-08-28arm64: dts: uniphier: add AIDET nodesMasahiro Yamada2-0/+14
Add UniPhier AIDET (ARM Interrupt Detector) nodes to support active low interrupts. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-08-28arm64: dts: allwinner: Revert EMAC changesMaxime Ripard8-135/+0
Since the discussion is not settled yet for the EMAC, and that the release in getting really close, let's revert the changes for now, and we'll reintroduce them later. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-08-25futex: Remove duplicated code and fix undefined behaviourJiri Slaby1-22/+4
There is code duplicated over all architecture's headers for futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, and comparison of the result. Remove this duplication and leave up to the arches only the needed assembly which is now in arch_futex_atomic_op_inuser. This effectively distributes the Will Deacon's arm64 fix for undefined behaviour reported by UBSAN to all architectures. The fix was done in commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump. And as suggested by Thomas, check for negative oparg too, because it was also reported to cause undefined behaviour report. Note that s390 removed access_ok check in d12a29703 ("s390/uaccess: remove pointless access_ok() checks") as access_ok there returns true. We introduce it back to the helper for the sake of simplicity (it gets optimized away anyway). Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> [s390] Acked-by: Chris Metcalf <cmetcalf@mellanox.com> [for tile] Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org> Reviewed-by: Will Deacon <will.deacon@arm.com> [core/arm64] Cc: linux-mips@linux-mips.org Cc: Rich Felker <dalias@libc.org> Cc: linux-ia64@vger.kernel.org Cc: linux-sh@vger.kernel.org Cc: peterz@infradead.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: sparclinux@vger.kernel.org Cc: Jonas Bonn <jonas@southpole.se> Cc: linux-s390@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: linux-hexagon@vger.kernel.org Cc: Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Matt Turner <mattst88@gmail.com> Cc: linux-snps-arc@lists.infradead.org Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-xtensa@linux-xtensa.org Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Cc: openrisc@lists.librecores.org Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Stafford Horne <shorne@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Richard Henderson <rth@twiddle.net> Cc: Chris Zankel <chris@zankel.net> Cc: Michal Simek <monstr@monstr.eu> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-parisc@vger.kernel.org Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: linux-alpha@vger.kernel.org Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: "David S. Miller" <davem@davemloft.net> Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
2017-08-26arm64: dts: uniphier: add reset controller node of analog amplifierKatsuhiro Suzuki2-0/+22
This patch adds reset controller node of analog signal amplifier core (ADAMV) for UniPhier LD11/LD20 SoCs. Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-08-25arm64: dts: exynos: remove i80-if-timings nodesAndrzej Hajda1-6/+0
Since i80/command mode is determined in runtime by propagating info from panel this property can be removed. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2017-08-24arm64: dts: marvell: add Device Tree files for Armada-8KPHanna Hawa5-0/+388
This commit adds the base Device Tree files for the Armada 8KPlus. The Armada 8KP SoCs include several hardware blocks, and this commit only adds support for the AP810 block, that contains the CPU core and basic peripherals. AP810 is a high-performance die, includes octal core application processor based ARMv8-A architecture, two standard high speed DDR4 interface, and GIC-600 interrupt controller. AP810 Built as part of Marvell’s MoChi AP family products. Armada-8080 (8KPlus family), include an AP810 block that contains the CPU core and basic peripherals. This commit creates the following hierarchy: * armada-ap810-ap0.dtsi - definitions common to AP810 * armada-ap810-ap0-octa-core.dtsi - description of the octa cores * armada-8080.dtsi - description of the 8080 SoC * armada-8080-db.dts - description of the 8080 board Signed-off-by: Hanna Hawa <hannah@marvell.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-08-23arm64: dts: rockchip: add Haikou baseboard with RK3399-Q7 SoMKlaus Goger2-0/+229
Haikou is a Qseven and μQseven baseboard featuring PCIe, USB3 and a video connector for MIPI-DSI/CSI and eDP adapter. This dts is for usage with the RK3399-Q7 SoM Puma. Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-08-23arm64: dts: rockchip: add RK3399-Q7 (Puma) SoMKlaus Goger1-0/+547
The RK3399-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230 connector) system-on-module from Theobroma Systems, featuring the Rockchip RK3399. It provides the following feature set: * up to 4GB DDR3 * on-module SPI-NOR flash * on-module eMMC (with 8-bit 1.8V interface) * SD card (on a baseboad) via edge connector * Gigabit Ethernet with on-module Micrel KSZ9031 GbE PHY * HDMI/eDP/2x MIPI-DSI * 2x MIPI-CSI * USB - 1x USB 3.0 dual-role (direct connection) - 2x USB 3.0 host + 1x USB 2.0 (on-module USB 3.0 hub) * on-module STM32 Cortex-M0 companion controller, implementing: - low-power RTC functionality (ISL1208 emulation) - fan controller (AMC6821 emulation) - USB<->CAN bridge controller Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>