summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
...
* parisc: Bump 64-bit IRQ stack size to 64 KBJohn David Anglin2021-03-071-0/+4
| | | | | | | | | | | | | | [ Upstream commit 31680c1d1595a59e17c14ec036b192a95f8e5f4a ] Bump 64-bit IRQ stack size to 64 KB. I had a kernel IRQ stack overflow on the mx3210 debian buildd machine. This patch increases the 64-bit IRQ stack size to 64 KB. The 64-bit stack size needs to be larger than the 32-bit stack size since registers are twice as big. Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* perf/x86/kvm: Add Cascade Lake Xeon steppings to isolation_ucodes[]Jim Mattson2021-03-071-0/+3
| | | | | | | | | | | | | | | | | | | | [ Upstream commit b3c3361fe325074d4144c29d46daae4fc5a268d5 ] Cascade Lake Xeon parts have the same model number as Skylake Xeon parts, so they are tagged with the intel_pebs_isolation quirk. However, as with Skylake Xeon H0 stepping parts, the PEBS isolation issue is fixed in all microcode versions. Add the Cascade Lake Xeon steppings (5, 6, and 7) to the isolation_ucodes[] table so that these parts benefit from Andi's optimization in commit 9b545c04abd4f ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Signed-off-by: Jim Mattson <jmattson@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Andi Kleen <ak@linux.intel.com> Link: https://lkml.kernel.org/r/20210205191324.2889006-1-jmattson@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* x86/build: Treat R_386_PLT32 relocation as R_386_PC32Fangrui Song2021-03-072-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: https://github.com/ClangBuiltLinux/linux/issues/1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirkHeiner Kallweit2021-03-071-0/+9
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4b2d8ca9208be636b30e924b1cbcb267b0740c93 ] On this system the M.2 PCIe WiFi card isn't detected after reboot, only after cold boot. reboot=pci fixes this behavior. In [0] the same issue is described, although on another system and with another Intel WiFi card. In case it's relevant, both systems have Celeron CPUs. Add a PCI reboot quirk on affected systems until a more generic fix is available. [0] https://bugzilla.kernel.org/show_bug.cgi?id=202399 [ bp: Massage commit message. ] Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/1524eafd-f89c-cfa4-ed70-0bde9e45eec9@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: Drop 32-bit asm string functionsPaul Burton2021-03-071-121/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3c0be5849259b729580c23549330973a2dd513a2 upstream. We have assembly implementations of strcpy(), strncpy(), strcmp() & strncmp() which: - Are simple byte-at-a-time loops with no particular optimizations. As a comment in the code describes, they're "rather naive". - Offer no clear performance advantage over the generic C implementations - in microbenchmarks performed by Alexander Lobakin the asm functions sometimes win & sometimes lose, but generally not by large margins in either direction. - Don't support 64-bit kernels, where we already make use of the generic C implementations. - Tend to bloat kernel code size due to inlining. - Don't support CONFIG_FORTIFY_SOURCE. - Won't support nanoMIPS without rework. For all of these reasons, delete the asm implementations & make use of the generic C implementations for 32-bit kernels just like we already do for 64-bit kernels. Signed-off-by: Paul Burton <paul.burton@mips.com> URL: https://lore.kernel.org/linux-mips/a2a35f1cf58d6db19eb4af9b4ae21e35@dlink.ru/ Cc: Alexander Lobakin <alobakin@dlink.ru> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: linux-mips@vger.kernel.org Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* MIPS: VDSO: Use CLANG_FLAGS instead of filtering out '--target='Nathan Chancellor2021-03-071-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 76d7fff22be3e4185ee5f9da2eecbd8188e76b2c upstream. Commit ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags") allowed the '--target=' flag from the main Makefile to filter through to the vDSO. However, it did not bring any of the other clang specific flags for controlling the integrated assembler and the GNU tools locations (--prefix=, --gcc-toolchain=, and -no-integrated-as). Without these, we will get a warning (visible with tinyconfig): arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports one section per compilation unit .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3: ^ arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports one section per compilation unit .section .mips_abiflags, "a" ^ All of these flags are bundled up under CLANG_FLAGS in the main Makefile and exported so that they can be added to Makefiles that set their own CFLAGS. Use this value instead of filtering out '--target=' so there is no warning and all of the tools are properly used. Cc: stable@vger.kernel.org Fixes: ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags") Link: https://github.com/ClangBuiltLinux/linux/issues/1256 Reported-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> [nc: Fix conflict due to lack of 99570c3da96a in 5.4] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64 module: set plt* section addresses to 0x0Shaoying Xu2021-03-071-3/+3
| | | | | | | | | | | | | | | | | | | | commit f5c6d0fcf90ce07ee0d686d465b19b247ebd5ed7 upstream. These plt* and .text.ftrace_trampoline sections specified for arm64 have non-zero addressses. Non-zero section addresses in a relocatable ELF would confuse GDB when it tries to compute the section offsets and it ends up printing wrong symbol addresses. Therefore, set them to zero, which mirrors the change in commit 5d8591bc0fba ("module: set ksymtab/kcrctab* section addresses to 0x0"). Reported-by: Frank van der Linden <fllinden@amazon.com> Signed-off-by: Shaoying Xu <shaoyi@amazon.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210216183234.GA23876@amazon.com Signed-off-by: Will Deacon <will@kernel.org> [shaoyi@amazon.com: made same changes in arch/arm64/kernel/module.lds for 5.4] Signed-off-by: Shaoying Xu <shaoyi@amazon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: dts: aspeed: Add LCLK to lpc-snoopJohn Wang2021-03-042-0/+2
| | | | | | | | | | commit d050d049f8b8077025292c1ecf456c4ee7f96861 upstream. Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201202051634.490-2-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* sparc32: fix a user-triggerable oops in clear_user()Al Viro2021-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7780918b36489f0b2f9a3749d7be00c2ceaec513 upstream. Back in 2.1.29 the clear_user() guts (__bzero()) had been merged with memset(). Unfortunately, while all exception handlers had been copied, one of the exception table entries got lost. As the result, clear_user() starting at 128*n bytes before the end of page and spanning between 8 and 127 bytes into the next page would oops when the second page is unmapped. It's trivial to reproduce - all it takes is main() { int fd = open("/dev/zero", O_RDONLY); char *p = mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0); munmap(p + 8192, 8192); read(fd, p + 8192 - 128, 192); } which had been oopsing since March 1997. Says something about the quality of test coverage... ;-/ And while today sparc32 port is nearly dead, back in '97 it had been very much alive; in fact, sparc64 had only been in mainline for 3 months by that point... Cc: stable@kernel.org Fixes: v2.1.29 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* um: mm: check more comprehensively for stub changesJohannes Berg2021-03-041-1/+11
| | | | | | | | | | | | | | | | | | | | | commit 47da29763ec9a153b9b685bff9db659e4e09e494 upstream. If userspace tries to change the stub, we need to kill it, because otherwise it can escape the virtual machine. In a few cases the stub checks weren't good, e.g. if userspace just tries to mmap(0x100000 - 0x1000, 0x3000, ...) it could succeed to get a new private/anonymous mapping replacing the stubs. Fix this by checking everywhere, and checking for _overlap_, not just direct changes. Cc: stable@vger.kernel.org Fixes: 3963333fe676 ("uml: cover stubs with a VMA") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* s390/vtime: fix inline assembly clobber listHeiko Carstens2021-03-041-1/+2
| | | | | | | | | | | | | | | | | | commit b29c5093820d333eef22f58cd04ec0d089059c39 upstream. The stck/stckf instruction used within the inline assembly within do_account_vtime() changes the condition code. This is not reflected with the clobber list, and therefore might result in incorrect code generation. It seems unlikely that the compiler could generate incorrect code considering the surrounding C code, but it must still be fixed. Cc: <stable@vger.kernel.org> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* powerpc/32s: Add missing call to kuep_lock on syscall entryChristophe Leroy2021-03-041-0/+3
| | | | | | | | | | | | | | | | | | commit 57fdfbce89137ae85cd5cef48be168040a47dd13 upstream. Userspace Execution protection and fast syscall entry were implemented independently from each other and were both merged in kernel 5.2, leading to syscall entry missing userspace execution protection. On syscall entry, execution of user space memory must be locked in the same way as on exception entry. Fixes: b86fb88855ea ("powerpc/32: implement fast entry for syscalls on non BOOKE") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/c65e105b63aaf74f91a14f845bc77192350b84a6.1612796617.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: Extend workaround for erratum 1024718 to all versions of Cortex-A55Suzuki K Poulose2021-03-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | commit c0b15c25d25171db4b70cc0b7dbc1130ee94017d upstream. The erratum 1024718 affects Cortex-A55 r0p0 to r2p0. However we apply the work around for r0p0 - r1p0. Unfortunately this won't be fixed for the future revisions for the CPU. Thus extend the work around for all versions of A55, to cover for r2p0 and any future revisions. Cc: stable@vger.kernel.org Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20210203230057.3961239-1-suzuki.poulose@arm.com [will: Update Kconfig help text] Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86: fix seq_file iteration for pat/memtype.cNeilBrown2021-03-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 3d2fc4c082448e9c05792f9b2a11c1d5db408b85 upstream. The memtype seq_file iterator allocates a buffer in the ->start and ->next functions and frees it in the ->show function. The preferred handling for such resources is to free them in the subsequent ->next or ->stop function call. Since Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") there is no guarantee that ->show will be called after ->next, so this function can now leak memory. So move the freeing of the buffer to ->next and ->stop. Link: https://lkml.kernel.org/r/161248539022.21478.13874455485854739066.stgit@noble1 Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: NeilBrown <neilb@suse.de> Cc: Xin Long <lucien.xin@gmail.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: uprobe: Return EOPNOTSUPP for AARCH32 instruction probingHe Zhe2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | commit d47422d953e258ad587b5edf2274eb95d08bdc7d upstream. As stated in linux/errno.h, ENOTSUPP should never be seen by user programs. When we set up uprobe with 32-bit perf and arm64 kernel, we would see the following vague error without useful hint. The sys_perf_event_open() syscall returned with 524 (INTERNAL ERROR: strerror_r(524, [buf], 128)=22) Use EOPNOTSUPP instead to indicate such cases. Signed-off-by: He Zhe <zhe.he@windriver.com> Link: https://lore.kernel.org/r/20210223082535.48730-1-zhe.he@windriver.com Cc: <stable@vger.kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: kexec_file: fix memory leakage in create_dtb() when fdt_open_into() failsqiuguorui12021-03-041-1/+3
| | | | | | | | | | | | | | commit 656d1d58d8e0958d372db86c24f0b2ea36f50888 upstream. in function create_dtb(), if fdt_open_into() fails, we need to vfree buf before return. Fixes: 52b2a8af7436 ("arm64: kexec_file: load initrd and device-tree") Cc: stable@vger.kernel.org # v5.0 Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com> Link: https://lore.kernel.org/r/20210218125900.6810-1-qiuguorui1@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* powerpc/prom: Fix "ibm,arch-vec-5-platform-support" scanCédric Le Goater2021-03-041-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit ed5b00a05c2ae95b59adc3442f45944ec632e794 upstream. The "ibm,arch-vec-5-platform-support" property is a list of pairs of bytes representing the options and values supported by the platform firmware. At boot time, Linux scans this list and activates the available features it recognizes : Radix and XIVE. A recent change modified the number of entries to loop on and 8 bytes, 4 pairs of { options, values } entries are always scanned. This is fine on KVM but not on PowerVM which can advertises less. As a consequence on this platform, Linux reads extra entries pointing to random data, interprets these as available features and tries to activate them, leading to a firmware crash in ibm,client-architecture-support. Fix that by using the property length of "ibm,arch-vec-5-platform-support". Fixes: ab91239942a9 ("powerpc/prom: Remove VLA in prom_check_platform_support()") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210122075029.797013-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86/reboot: Force all cpus to exit VMX root if VMX is supportedSean Christopherson2021-03-041-19/+10
| | | | | | | | | | | | | | | | | | | | commit ed72736183c45a413a8d6974dd04be90f514cb6b upstream. Force all CPUs to do VMXOFF (via NMI shootdown) during an emergency reboot if VMX is _supported_, as VMX being off on the current CPU does not prevent other CPUs from being in VMX root (post-VMXON). This fixes a bug where a crash/panic reboot could leave other CPUs in VMX root and prevent them from being woken via INIT-SIPI-SIPI in the new kernel. Fixes: d176720d34c7 ("x86: disable VMX on all CPUs on reboot") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: David P. Reed <dpreed@deepplum.com> [sean: reworked changelog and further tweaked comment] Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20201231002702.2223707-3-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* x86/virt: Eat faults on VMXOFF in reboot flowsSean Christopherson2021-03-041-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | commit aec511ad153556640fb1de38bfe00c69464f997f upstream. Silently ignore all faults on VMXOFF in the reboot flows as such faults are all but guaranteed to be due to the CPU not being in VMX root. Because (a) VMXOFF may be executed in NMI context, e.g. after VMXOFF but before CR4.VMXE is cleared, (b) there's no way to query the CPU's VMX state without faulting, and (c) the whole point is to get out of VMX root, eating faults is the simplest way to achieve the desired behaior. Technically, VMXOFF can fault (or fail) for other reasons, but all other fault and failure scenarios are mode related, i.e. the kernel would have to magically end up in RM, V86, compat mode, at CPL>0, or running with the SMI Transfer Monitor active. The kernel is beyond hosed if any of those scenarios are encountered; trying to do something fancy in the error path to handle them cleanly is pointless. Fixes: 1e9931146c74 ("x86: asm/virtext.h: add cpu_vmxoff() inline function") Reported-by: David P. Reed <dpreed@deepplum.com> Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-Id: <20201231002702.2223707-2-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* dts64: mt7622: fix slow sd card accessFrank Wunderlich2021-03-041-0/+2
| | | | | | | | | | | | | | commit dc2e76175417e69c41d927dba75a966399f18354 upstream. Fix extreme slow speed (200MB takes ~20 min) on writing sdcard on bananapi-r64 by adding reset-control for mmc1 like it's done for mmc0/emmc. Fixes: 2c002a3049f7 ("arm64: dts: mt7622: add mmc related device nodes") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210113180919.49523-1-linux@fw-web.de Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: aesni - prevent misaligned buffers on the stackArd Biesheuvel2021-03-041-12/+16
| | | | | | | | | | | | | | | | | | | commit a13ed1d15b07a04b1f74b2df61ff7a5e47f45dd8 upstream. The GCM mode driver uses 16 byte aligned buffers on the stack to pass the IV to the asm helpers, but unfortunately, the x86 port does not guarantee that the stack pointer is 16 byte aligned upon entry in the first place. Since the compiler is not aware of this, it will not emit the additional stack realignment sequence that is needed, and so the alignment is not guaranteed to be more than 8 bytes. So instead, allocate some padding on the stack, and realign the IV pointer by hand. Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: arm64/sha - add missing module aliasesArd Biesheuvel2021-03-044-0/+9
| | | | | | | | | | | | | | | | | | | | | commit 0df07d8117c3576f1603b05b84089742a118d10a upstream. The accelerated, instruction based implementations of SHA1, SHA2 and SHA3 are autoloaded based on CPU capabilities, given that the code is modest in size, and widely used, which means that resolving the algo name, loading all compatible modules and picking the one with the highest priority is taken to be suboptimal. However, if these algorithms are requested before this CPU feature based matching and autoloading occurs, these modules are not even considered, and we end up with suboptimal performance. So add the missing module aliases for the various SHA implementations. Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* arm64: Add missing ISB after invalidating TLB in __primary_switchMarc Zyngier2021-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9d41053e8dc115c92b8002c3db5f545d7602498b ] Although there has been a bit of back and forth on the subject, it appears that invalidating TLBs requires an ISB instruction when FEAT_ETS is not implemented by the CPU. From the bible: | In an implementation that does not implement FEAT_ETS, a TLB | maintenance instruction executed by a PE, PEx, can complete at any | time after it is issued, but is only guaranteed to be finished for a | PE, PEx, after the execution of DSB by the PEx followed by a Context | synchronization event Add the missing ISB in __primary_switch, just in case. Fixes: 3c5e9f238bc4 ("arm64: head.S: move KASLR processing out of __enable_mmu()") Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20210224093738.3629662-3-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* sparc64: only select COMPAT_BINFMT_ELF if BINFMT_ELF is setRandy Dunlap2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 80bddf5c93a99e11fc9faf7e4b575d01cecd45d3 ] Currently COMPAT on SPARC64 selects COMPAT_BINFMT_ELF unconditionally, even when BINFMT_ELF is not enabled. This causes a kconfig warning. Instead, just select COMPAT_BINFMT_ELF if BINFMT_ELF is enabled. This builds cleanly with no kconfig warnings. WARNING: unmet direct dependencies detected for COMPAT_BINFMT_ELF Depends on [n]: COMPAT [=y] && BINFMT_ELF [=n] Selected by [y]: - COMPAT [=y] && SPARC64 [=y] Fixes: 26b4c912185a ("sparc,sparc64: unify Kconfig files") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* powerpc/8xx: Fix software emulation interruptChristophe Leroy2021-03-041-1/+1
| | | | | | | | | | | | | | | | [ Upstream commit 903178d0ce6bb30ef80a3604ab9ee2b57869fbc9 ] For unimplemented instructions or unimplemented SPRs, the 8xx triggers a "Software Emulation Exception" (0x1000). That interrupt doesn't set reason bits in SRR1 as the "Program Check Exception" does. Go through emulation_assist_interrupt() to set REASON_ILLEGAL. Fixes: fbbcc3bb139e ("powerpc/8xx: Remove SoftwareEmulation()") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/ad782af87a222efc79cfb06079b0fd23d4224eaf.1612515180.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
* powerpc/pseries/dlpar: handle ibm, configure-connector delay statusNathan Lynch2021-03-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 768d70e19ba525debd571b36e6d0ab19956c63d7 ] dlpar_configure_connector() has two problems in its handling of ibm,configure-connector's return status: 1. When the status is -2 (busy, call again), we call ibm,configure-connector again immediately without checking whether to schedule, which can result in monopolizing the CPU. 2. Extended delay status (9900..9905) goes completely unhandled, causing the configuration to unnecessarily terminate. Fix both of these issues by using rtas_busy_delay(). Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure") Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210107025900.410369-1-nathanl@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ coresVladimir Murzin2021-03-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ] It was observed that decompressor running on hardware implementing ARM v8.2 Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest, would stuck just after: Uncompressing Linux... done, booting the kernel. The reason is that it clears nTLSMD bit when disabling caches: nTLSMD, bit [3] When ARMv8.2-LSMAOC is implemented: No Trap Load Multiple and Store Multiple to Device-nGRE/Device-nGnRE/Device-nGnRnE memory. 0b0 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and generate a stage 1 Alignment fault. 0b1 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped. This bit is permitted to be cached in a TLB. This field resets to 1. Otherwise: Reserved, RES1 So as effect we start getting traps we are not quite ready for. Looking into history it seems that mask used for SCTLR clear came from the similar code for ARMv4, where bit[3] is the enable/disable bit for the write buffer. That not applicable to ARMv7 and onwards, so retire that bit from the masks. Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
* powerpc/47x: Disable 256k page sizeChristophe Leroy2021-03-041-1/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 910a0cb6d259736a0c86e795d4c2f42af8d0d775 ] PPC47x_TLBE_SIZE isn't defined for 256k pages, leading to a build break if 256k pages is selected. So change the kconfig so that 256k pages can't be selected for 47x. Fixes: e7f75ad01d59 ("powerpc/47x: Base ppc476 support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> [mpe: Expand change log to mention build break] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/2fed79b1154c872194f98bac4422c23918325e61.1611128938.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
* KVM: PPC: Make the VMX instruction emulation routines staticCédric Le Goater2021-03-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9236f57a9e51c72ce426ccd2e53e123de7196a0f ] These are only used locally. It fixes these W=1 compile errors : ../arch/powerpc/kvm/powerpc.c:1521:5: error: no previous prototype for ‘kvmppc_get_vmx_dword’ [-Werror=missing-prototypes] 1521 | int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~~ ../arch/powerpc/kvm/powerpc.c:1539:5: error: no previous prototype for ‘kvmppc_get_vmx_word’ [-Werror=missing-prototypes] 1539 | int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~ ../arch/powerpc/kvm/powerpc.c:1557:5: error: no previous prototype for ‘kvmppc_get_vmx_hword’ [-Werror=missing-prototypes] 1557 | int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~~ ../arch/powerpc/kvm/powerpc.c:1575:5: error: no previous prototype for ‘kvmppc_get_vmx_byte’ [-Werror=missing-prototypes] 1575 | int kvmppc_get_vmx_byte(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~ Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction mmio emulation with analyse_instr() input") Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210104143206.695198-19-clg@kaod.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* clocksource/drivers/ixp4xx: Select TIMER_OF when neededArnd Bergmann2021-03-041-1/+0
| | | | | | | | | | | | | | | | | | | [ Upstream commit 7a3b8758bd6e45f7b671723b5c9fa2b69d0787ae ] Compile-testing the ixp4xx timer with CONFIG_OF enabled but CONFIG_TIMER_OF disabled leads to a harmless warning: arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ixp4xx.o' being placed in section `__timer_of_table' Move the select statement from the platform code into the driver so it always gets enabled in configurations that rely on it. Fixes: 40df14cc5cc0 ("clocksource/drivers/ixp4xx: Add OF initialization support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210103135955.3808976-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: properly stop .eh_frame generationAlexander Lobakin2021-03-042-1/+18
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 894ef530012fb5078466efdfb2c15d8b2f1565cd ] Commit 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") added -fno-asynchronous-unwind-tables to KBUILD_CFLAGS to prevent compiler from emitting .eh_frame symbols. However, as MIPS heavily uses CFI, that's not enough. Use the approach taken for x86 (as it also uses CFI) and explicitly put CFI symbols into the .debug_frame section (except for VDSO). This allows us to drop .eh_frame from DISCARDS as it's no longer being generated. Fixes: 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: lantiq: Explicitly compare LTQ_EBU_PCC_ISTAT against 0Nathan Chancellor2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit c6f2a9e17b9bef7677caddb1626c2402f3e9d2bd ] When building xway_defconfig with clang: arch/mips/lantiq/irq.c:305:48: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ^ ~~~~~~~~~~~~~~~~~ arch/mips/lantiq/irq.c:305:48: note: use '&' for a bitwise operation if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ^~ & arch/mips/lantiq/irq.c:305:48: note: remove constant to silence this warning if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ~^~~~~~~~~~~~~~~~~~~~ 1 error generated. Explicitly compare the constant LTQ_EBU_PCC_ISTAT against 0 to fix the warning. Additionally, remove the unnecessary parentheses as this is a simple conditional statement and shorthand '== 0' to '!'. Fixes: 3645da0276ae ("OF: MIPS: lantiq: implement irq_domain support") Link: https://github.com/ClangBuiltLinux/linux/issues/807 Reported-by: Dmitry Golovin <dima@golovin.in> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* MIPS: c-r4k: Fix section mismatch for loongson2_sc_initNathan Chancellor2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit c58734eee6a2151ba033c0dcb31902c89e310374 ] When building with clang, the following section mismatch warning occurs: WARNING: modpost: vmlinux.o(.text+0x24490): Section mismatch in reference from the function r4k_cache_init() to the function .init.text:loongson2_sc_init() This should have been fixed with commit ad4fddef5f23 ("mips: fix Section mismatch in reference") but it was missed. Remove the improper __init annotation like that commit did. Fixes: 078a55fc824c ("MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code") Link: https://github.com/ClangBuiltLinux/linux/issues/787 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: arm64/aes-ce - really hide slower algos when faster ones are enabledArd Biesheuvel2021-03-041-2/+2
| | | | | | | | | | | | | | | | [ Upstream commit 15deb4333cd6d4e1e3216582e4c531ec40a6b060 ] Commit 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if faster driver is enabled") intended to hide modes from the plain NEON driver that are also implemented by the faster bit sliced NEON one if both are enabled. However, the defined() CPP function does not detect if the bit sliced NEON driver is enabled as a module. So instead, let's use IS_ENABLED() here. Fixes: 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if ...") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: msm8916: Fix reserved and rfsa nodes unit addressVincent Knecht2021-03-041-2/+2
| | | | | | | | | | | | | [ Upstream commit d5ae2528b0b56cf054b27d48b0cb85330900082f ] Fix `reserved` and `rfsa` unit address according to their reg address Fixes: 7258e10e6a0b ("ARM: dts: msm8916: Update reserved-memory") Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Link: https://lore.kernel.org/r/20210123104417.518105-1-vincent.knecht@mailoo.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: armada-3720-turris-mox: rename u-boot mtd partition to a53-firmwareMarek Behún2021-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a9d9bfcadfb43b856dbcf9419de75f7420d5a225 ] The partition called "u-boot" in reality contains TF-A and U-Boot, and TF-A is before U-Boot. Rename this parition to "a53-firmware" to avoid confusion for users, since they cannot simply build U-Boot from U-Boot repository and flash the resulting image there. Instead they have to build the firmware with the sources from the mox-boot-builder repository [1] and flash the a53-firmware.bin binary there. [1] https://gitlab.nic.cz/turris/mox-boot-builder Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Cc: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: armada388-helios4: assign pinctrl to each fanRosen Penev2021-03-041-3/+10
| | | | | | | | | | | | [ Upstream commit 46ecdfc1830eaa40a11d7f832089c82b0e67ea96 ] Split up the pins for each fan. This is needed in order to control them Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: armada388-helios4: assign pinctrl to LEDsRosen Penev2021-03-041-3/+12
| | | | | | | | | | | | | [ Upstream commit e011c9025a4691b5c734029577a920bd6c320994 ] Split up the pins to match earlier definitions. Allows LEDs to flash properly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: Configure missing thermal interrupt for 4430Tony Lindgren2021-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 44f416879a442600b006ef7dec3a6dc98bcf59c6 ] We have gpio_86 wired internally to the bandgap thermal shutdown interrupt on 4430 like we have it on 4460 according to the TRM. This can be found easily by searching for TSHUT. For some reason the thermal shutdown interrupt was never added for 4430, let's add it. I believe this is needed for the thermal shutdown interrupt handler ti_bandgap_tshut_irq_handler() to call orderly_poweroff(). Fixes: aa9bb4bb8878 ("arm: dts: add omap4430 thermal data") Cc: Carl Philipp Klemm <philipp@uvos.xyz> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: A64: Limit MMC2 bus frequency to 150 MHzAndre Przywara2021-03-042-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 948c657cc45e8ce48cb533d4e2106145fa765759 ] In contrast to the H6 (and later) manuals, the A64 datasheet does not specify any limitations in the maximum possible frequency for eMMC controllers. However experimentation has found that a 150 MHz limit similar to other SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist for the MMC2 controller. Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi. The Pinebook seems to be the an odd exception, since it apparently seems to work with 200 MHz as well, so overwrite this in its board .dts file. Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works. Fixes: 22be992faea7 ("arm64: allwinner: a64: Increase the MMC max frequency") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-7-andre.przywara@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: H6: Allow up to 150 MHz MMC bus frequencyAndre Przywara2021-03-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cfe6c487b9a1abc6197714ec5605716a5428cf03 ] The H6 manual explicitly lists a frequency limit of 150 MHz for the bus frequency of the MMC controllers. So far we had no explicit limits in the DT, which limited eMMC to the spec defined frequencies, or whatever the driver defines (both Linux and FreeBSD use 52 MHz here). Put those maximum frequencies in the SoC .dtsi, to allow higher speed modes (which still would need to be explicitly enabled, per board). Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed 200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably. Fixes: 8f54bd1595b3 ("arm64: allwinner: h6: add device tree nodes for MMC controllers") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-6-andre.przywara@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD cardAndre Przywara2021-03-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 941432d007689f3774646e41a1439228b6c6ee0e ] The SD card on the SoPine SoM module is somewhat concealed, so was originally defined as "non-removable". However there is a working card-detect pin (tested on two different SoM versions), and in certain SoM base boards it might be actually accessible at runtime. Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the non-removable flag, even though the SD card slot is perfectly accessible and usable there. (It turns out that just *my* board has a broken card detect switch, so I originally thought CD wouldn't work on the LTS.) Drop the "non-removable" flag to describe the SD card slot properly. Fixes: c3904a269891 ("arm64: allwinner: a64: add DTSI file for SoPine SoM") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-5-andre.przywara@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: H6: properly connect USB PHY to port 0Andre Przywara2021-03-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit da2fb8457f71138d455cba82edec0d34f858e506 ] In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the H6 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: eabb3d424b6d ("arm64: dts: allwinner: h6: add USB2-related device nodes") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-3-andre.przywara@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: allwinner: A64: properly connect USB PHY to port 0Andre Przywara2021-03-042-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cc72570747e43335f4933a24dd74d5653639176a ] In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the A64 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. Remove the part from the Pinebook DTS which already had this property. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: dc03a047df1d ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210113152630.28810-2-andre.przywara@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: exynos: correct PMIC interrupt trigger level on EspressoKrzysztof Kozlowski2021-03-041-1/+1
| | | | | | | | | | | | | | [ Upstream commit 1fea2eb2f5bbd3fbbe2513d2386b5f6e6db17fd7 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212903.216728-8-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* arm64: dts: exynos: correct PMIC interrupt trigger level on TM2Krzysztof Kozlowski2021-03-041-1/+1
| | | | | | | | | | | | | | | [ Upstream commit e98e2367dfb4b6d7a80c8ce795c644124eff5f36 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201210212903.216728-7-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 familyKrzysztof Kozlowski2021-03-041-1/+1
| | | | | | | | | | | | | | [ Upstream commit 3e7d9a583a24f7582c6bc29a0d4d624feedbc2f9 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: aac4e0615341 ("ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201210212903.216728-6-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale OctaKrzysztof Kozlowski2021-03-041-1/+1
| | | | | | | | | | | | | | [ Upstream commit 1ac8893c4fa3d4a34915dc5cdab568a39db5086c ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 1fed2252713e ("ARM: dts: fix pinctrl for s2mps11-irq on exynos5420-arndale-octa") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201210212903.216728-5-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: exynos: correct PMIC interrupt trigger level on SpringKrzysztof Kozlowski2021-03-041-1/+1
| | | | | | | | | | | | | | [ Upstream commit 77e6a5467cb8657cf8b5e610a30a4c502085e4f9 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 53dd4138bb0a ("ARM: dts: Add exynos5250-spring device tree") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201210212903.216728-4-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* ARM: dts: exynos: correct PMIC interrupt trigger level on RinatoKrzysztof Kozlowski2021-03-041-1/+1
| | | | | | | | | | | | | | | [ Upstream commit 437ae60947716bb479e2f32466f49445c0509b1e ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: faaf348ef468 ("ARM: dts: Add board dts file for exynos3250-rinato") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201210212903.216728-3-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-01 18:02:48 +0000