summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2021-07-28nds32: fix up stack guard gapGreg Kroah-Hartman
commit c453db6cd96418c79702eaf38259002755ab23ff upstream. Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") fixed up all architectures to deal with the stack guard gap. But when nds32 was added to the tree, it forgot to do the same thing. Resolve this by properly fixing up the nsd32's version of arch_get_unmapped_area() Cc: Nick Hu <nickhu@andestech.com> Cc: Greentime Hu <green.hu@gmail.com> Cc: Vincent Chen <deanbo422@gmail.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Hugh Dickins <hughd@google.com> Cc: Qiang Liu <cyruscyliu@gmail.com> Cc: stable <stable@vger.kernel.org> Reported-by: iLifetruth <yixiaonn@gmail.com> Acked-by: Hugh Dickins <hughd@google.com> Link: https://lore.kernel.org/r/20210629104024.2293615-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-28KVM: PPC: Book3S HV Nested: Sanitise H_ENTER_NESTED TM stateNicholas Piggin
commit d9c57d3ed52a92536f5fa59dc5ccdd58b4875076 upstream. The H_ENTER_NESTED hypercall is handled by the L0, and it is a request by the L1 to switch the context of the vCPU over to that of its L2 guest, and return with an interrupt indication. The L1 is responsible for switching some registers to guest context, and the L0 switches others (including all the hypervisor privileged state). If the L2 MSR has TM active, then the L1 is responsible for recheckpointing the L2 TM state. Then the L1 exits to L0 via the H_ENTER_NESTED hcall, and the L0 saves the TM state as part of the exit, and then it recheckpoints the TM state as part of the nested entry and finally HRFIDs into the L2 with TM active MSR. Not efficient, but about the simplest approach for something that's horrendously complicated. Problems arise if the L1 exits to the L0 with a TM state which does not match the L2 TM state being requested. For example if the L1 is transactional but the L2 MSR is non-transactional, or vice versa. The L0's HRFID can take a TM Bad Thing interrupt and crash. Fix this by disallowing H_ENTER_NESTED in TM[T] state entirely, and then ensuring that if the L1 is suspended then the L2 must have TM active, and if the L1 is not suspended then the L2 must not have TM active. Fixes: 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall") Cc: stable@vger.kernel.org # v4.20+ Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Acked-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-28KVM: PPC: Book3S: Fix H_RTAS rets buffer overflowNicholas Piggin
commit f62f3c20647ebd5fb6ecb8f0b477b9281c44c10a upstream. The kvmppc_rtas_hcall() sets the host rtas_args.rets pointer based on the rtas_args.nargs that was provided by the guest. That guest nargs value is not range checked, so the guest can cause the host rets pointer to be pointed outside the args array. The individual rtas function handlers check the nargs and nrets values to ensure they are correct, but if they are not, the handlers store a -3 (0xfffffffd) failure indication in rets[0] which corrupts host memory. Fix this by testing up front whether the guest supplied nargs and nret would exceed the array size, and fail the hcall directly without storing a failure indication to rets[0]. Also expand on a comment about why we kill the guest and try not to return errors directly if we have a valid rets[0] pointer. Fixes: 8e591cb72047 ("KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls") Cc: stable@vger.kernel.org # v3.10+ Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-28s390/boot: fix use of expolines in the DMA codeAlexander Egorenkov
commit 463f36c76fa4ec015c640ff63ccf52e7527abee0 upstream. The DMA code section of the decompressor must be compiled with expolines if Spectre V2 mitigation has been enabled for the decompressed kernel. This is required because although the decompressor's image contains the DMA code section, it is handed over to the decompressed kernel for use. Because the DMA code is already slow w/o expolines, use expolines always regardless whether the decompressed kernel is using them or not. This simplifies the DMA code by dropping the conditional compilation of expolines. Fixes: bf72630130c2 ("s390: use proper expoline sections for .dma code") Cc: <stable@vger.kernel.org> # 5.2 Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-28s390/ftrace: fix ftrace_update_ftrace_func implementationVasily Gorbik
commit f8c2602733c953ed7a16e060640b8e96f9d94b9b upstream. s390 enforces DYNAMIC_FTRACE if FUNCTION_TRACER is selected. At the same time implementation of ftrace_caller is not compliant with HAVE_DYNAMIC_FTRACE since it doesn't provide implementation of ftrace_update_ftrace_func() and calls ftrace_trace_function() directly. The subtle difference is that during ftrace code patching ftrace replaces function tracer via ftrace_update_ftrace_func() and activates it back afterwards. Unexpected direct calls to ftrace_trace_function() during ftrace code patching leads to nullptr-dereferences when tracing is activated for one of functions which are used during code patching. Those function currently are: copy_from_kernel_nofault() copy_from_kernel_nofault_allowed() preempt_count_sub() [with debug_defconfig] preempt_count_add() [with debug_defconfig] Corresponding KASAN report: BUG: KASAN: nullptr-dereference in function_trace_call+0x316/0x3b0 Read of size 4 at addr 0000000000001e08 by task migration/0/15 CPU: 0 PID: 15 Comm: migration/0 Tainted: G B 5.13.0-41423-g08316af3644d Hardware name: IBM 3906 M04 704 (LPAR) Stopper: multi_cpu_stop+0x0/0x3e0 <- stop_machine_cpuslocked+0x1e4/0x218 Call Trace: [<0000000001f77caa>] show_stack+0x16a/0x1d0 [<0000000001f8de42>] dump_stack+0x15a/0x1b0 [<0000000001f81d56>] print_address_description.constprop.0+0x66/0x2e0 [<000000000082b0ca>] kasan_report+0x152/0x1c0 [<00000000004cfd8e>] function_trace_call+0x316/0x3b0 [<0000000001fb7082>] ftrace_caller+0x7a/0x7e [<00000000006bb3e6>] copy_from_kernel_nofault_allowed+0x6/0x10 [<00000000006bb42e>] copy_from_kernel_nofault+0x3e/0xd0 [<000000000014605c>] ftrace_make_call+0xb4/0x1f8 [<000000000047a1b4>] ftrace_replace_code+0x134/0x1d8 [<000000000047a6e0>] ftrace_modify_all_code+0x120/0x1d0 [<000000000047a7ec>] __ftrace_modify_code+0x5c/0x78 [<000000000042395c>] multi_cpu_stop+0x224/0x3e0 [<0000000000423212>] cpu_stopper_thread+0x33a/0x5a0 [<0000000000243ff2>] smpboot_thread_fn+0x302/0x708 [<00000000002329ea>] kthread+0x342/0x408 [<00000000001066b2>] __ret_from_fork+0x92/0xf0 [<0000000001fb57fa>] ret_from_fork+0xa/0x30 The buggy address belongs to the page: page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1 flags: 0x1ffff00000001000(reserved|node=0|zone=0|lastcpupid=0x1ffff) raw: 1ffff00000001000 0000040000000048 0000040000000048 0000000000000000 raw: 0000000000000000 0000000000000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 0000000000001d00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0000000000001d80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 >0000000000001e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 ^ 0000000000001e80: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0000000000001f00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 ================================================================== To fix that introduce ftrace_func callback to be called from ftrace_caller and update it in ftrace_update_ftrace_func(). Fixes: 4cc9bed034d1 ("[S390] cleanup ftrace backend functions") Cc: stable@vger.kernel.org Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-28KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leakNicholas Piggin
[ Upstream commit bc4188a2f56e821ea057aca6bf444e138d06c252 ] vcpu_put is not called if the user copy fails. This can result in preempt notifier corruption and crashes, among other issues. Fixes: b3cebfe8c1ca ("KVM: PPC: Move vcpu_load/vcpu_put down to each ioctl case in kvm_arch_vcpu_ioctl") Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210716024310.164448-2-npiggin@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-28KVM: PPC: Book3S: Fix CONFIG_TRANSACTIONAL_MEM=n crashNicholas Piggin
[ Upstream commit bd31ecf44b8e18ccb1e5f6b50f85de6922a60de3 ] When running CPU_FTR_P9_TM_HV_ASSIST, HFSCR[TM] is set for the guest even if the host has CONFIG_TRANSACTIONAL_MEM=n, which causes it to be unprepared to handle guest exits while transactional. Normal guests don't have a problem because the HTM capability will not be advertised, but a rogue or buggy one could crash the host. Fixes: 4bb3c7a0208f ("KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9") Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210716024310.164448-1-npiggin@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-28s390/bpf: Perform r1 range checking before accessing jit->seen_reg[r1]Colin Ian King
[ Upstream commit 91091656252f5d6d8c476e0c92776ce9fae7b445 ] Currently array jit->seen_reg[r1] is being accessed before the range checking of index r1. The range changing on r1 should be performed first since it will avoid any potential out-of-range accesses on the array seen_reg[] and also it is more optimal to perform checks on r1 before fetching data from the array. Fix this by swapping the order of the checks before the array access. Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/bpf/20210715125712.24690-1-colin.king@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-28KVM: x86/pmu: Clear anythread deprecated bit when 0xa leaf is unsupported on ↵Like Xu
the SVM [ Upstream commit 7234c362ccb3c2228f06f19f93b132de9cfa7ae4 ] The AMD platform does not support the functions Ah CPUID leaf. The returned results for this entry should all remain zero just like the native does: AMD host: 0x0000000a 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 (uncanny) AMD guest: 0x0000000a 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00008000 Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional") Signed-off-by: Like Xu <likexu@tencent.com> Message-Id: <20210628074354.33848-1-likexu@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25bpf: Track subprog poke descriptors correctly and fix use-after-freeJohn Fastabend
commit f263a81451c12da5a342d90572e317e611846f2c upstream. Subprograms are calling map_poke_track(), but on program release there is no hook to call map_poke_untrack(). However, on program release, the aux memory (and poke descriptor table) is freed even though we still have a reference to it in the element list of the map aux data. When we run map_poke_run(), we then end up accessing free'd memory, triggering KASAN in prog_array_map_poke_run(): [...] [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337 [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399 [ 402.824715] Call Trace: [ 402.824719] dump_stack+0x93/0xc2 [ 402.824727] print_address_description.constprop.0+0x1a/0x140 [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757] prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] The elements concerned are walked as follows: for (i = 0; i < elem->aux->size_poke_tab; i++) { poke = &elem->aux->poke_tab[i]; [...] The access to size_poke_tab is a 4 byte read, verified by checking offsets in the KASAN dump: [ 402.825004] The buggy address belongs to the object at ffff8881905a7800 which belongs to the cache kmalloc-1k of size 1024 [ 402.825008] The buggy address is located 320 bytes inside of 1024-byte region [ffff8881905a7800, ffff8881905a7c00) The pahole output of bpf_prog_aux: struct bpf_prog_aux { [...] /* --- cacheline 5 boundary (320 bytes) --- */ u32 size_poke_tab; /* 320 4 */ [...] In general, subprograms do not necessarily manage their own data structures. For example, BTF func_info and linfo are just pointers to the main program structure. This allows reference counting and cleanup to be done on the latter which simplifies their management a bit. The aux->poke_tab struct, however, did not follow this logic. The initial proposed fix for this use-after-free bug further embedded poke data tracking into the subprogram with proper reference counting. However, Daniel and Alexei questioned why we were treating these objects special; I agree, its unnecessary. The fix here removes the per subprogram poke table allocation and map tracking and instead simply points the aux->poke_tab pointer at the main programs poke table. This way, map tracking is simplified to the main program and we do not need to manage them per subprogram. This also means, bpf_prog_free_deferred(), which unwinds the program reference counting and kfrees objects, needs to ensure that we don't try to double free the poke_tab when free'ing the subprog structures. This is easily solved by NULL'ing the poke_tab pointer. The second detail is to ensure that per subprogram JIT logic only does fixups on poke_tab[] entries it owns. To do this, we add a pointer in the poke structure to point at the subprogram value so JITs can easily check while walking the poke_tab structure if the current entry belongs to the current program. The aux pointer is stable and therefore suitable for such comparison. On the jit_subprogs() error path, we omit cleaning up the poke->aux field because these are only ever referenced from the JIT side, but on error we will never make it to the JIT, so its fine to leave them dangling. Removing these pointers would complicate the error path for no reason. However, we do need to untrack all poke descriptors from the main program as otherwise they could race with the freeing of JIT memory from the subprograms. Lastly, a748c6975dea3 ("bpf: propagate poke descriptors to subprograms") had an off-by-one on the subprogram instruction index range check as it was testing 'insn_idx >= subprog_start && insn_idx <= subprog_end'. However, subprog_end is the next subprogram's start instruction. Fixes: a748c6975dea3 ("bpf: propagate poke descriptors to subprograms") Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Co-developed-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210707223848.14580-2-john.fastabend@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25ARM: dts: tacoma: Add phase corrections for eMMCAndrew Jeffery
commit 2d6608b57c50c54c3e46649110e8ea5a40959c30 upstream. The degree values were reversed out from the magic tap values of 7 (in) and 15 + inversion (out) initially suggested by Aspeed. With the patch tacoma survives several gigabytes of reads and writes using dd while without it locks up randomly during the boot process. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210625061017.1149942-1-andrew@aj.id.au Fixes: 2fc88f92359d ("mmc: sdhci-of-aspeed: Expose clock phase controls") Fixes: 961216c135a8 ("ARM: dts: aspeed: Add Rainier system") Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25ARM: dts: aspeed: Fix AST2600 machines line namesJoel Stanley
commit ca46ad2214473df1a6a9496be17156d65ba89b9f upstream. Tacoma and Rainier both have a line-names array that is too long: gpio gpiochip0: gpio-line-names is length 232 but should be at most length 208 This was probably copied from an AST2500 device tree that did have more GPIOs on the controller. Fixes: e9b24b55ca4f ("ARM: dts: aspeed: rainier: Add gpio line names") Fixes: 2f68e4e7df67 ("ARM: dts: aspeed: tacoma: Add gpio line names") Link: https://lore.kernel.org/r/20210624090742.56640-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25mm/page_alloc: fix memory map initialization for descending nodesMike Rapoport
commit 122e093c1734361dedb64f65c99b93e28e4624f4 upstream. On systems with memory nodes sorted in descending order, for instance Dell Precision WorkStation T5500, the struct pages for higher PFNs and respectively lower nodes, could be overwritten by the initialization of struct pages corresponding to the holes in the memory sections. For example for the below memory layout [ 0.245624] Early memory node ranges [ 0.248496] node 1: [mem 0x0000000000001000-0x0000000000090fff] [ 0.251376] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff] [ 0.254256] node 1: [mem 0x0000000100000000-0x0000001423ffffff] [ 0.257144] node 0: [mem 0x0000001424000000-0x0000002023ffffff] the range 0x1424000000 - 0x1428000000 in the beginning of node 0 starts in the middle of a section and will be considered as a hole during the initialization of the last section in node 1. The wrong initialization of the memory map causes panic on boot when CONFIG_DEBUG_VM is enabled. Reorder loop order of the memory map initialization so that the outer loop will always iterate over populated memory regions in the ascending order and the inner loop will select the zone corresponding to the PFN range. This way initialization of the struct pages for the memory holes will be always done for the ranges that are actually not populated. [akpm@linux-foundation.org: coding style fixes] Link: https://lkml.kernel.org/r/YNXlMqBbL+tBG7yq@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=213073 Link: https://lkml.kernel.org/r/20210624062305.10940-1-rppt@kernel.org Fixes: 0740a50b9baa ("mm/page_alloc.c: refactor initialization of struct page for holes in memory layout") Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Cc: Boris Petkov <bp@alien8.de> Cc: Robert Shteynfeld <robert.shteynfeld@gmail.com> Cc: Baoquan He <bhe@redhat.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: David Hildenbrand <david@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [rppt: tweak for compatibility with IA64's override of memmap_init] Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi filePali Rohár
[ Upstream commit 3a52a48973b355b3aac5add92ef50650ae37c2bd ] Move the turris-mox-rwtm firmware node from Turris MOX' device tree into the generic armada-37xx.dtsi file and use the generic compatible string 'marvell,armada-3700-rwtm-firmware' instead of the current one. Turris MOX DTS file contains also old compatible string for backward compatibility. The Turris MOX rWTM firmware can be used on any Armada 37xx device, giving them access to the rWTM hardware random number generator, which is otherwise unavailable. This change allows Linux to load the turris-mox-rwtm.ko module on these boards. Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails to probe, while with CZ.NIC's firmware it registers the HW random number generator. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25s390: introduce proper type handling call_on_stack() macroHeiko Carstens
[ Upstream commit 41d71fe59cce41237f24f3b7bdc1b414069a34ed ] The existing CALL_ON_STACK() macro allows for subtle bugs: - There is no type checking of the function that is being called. That is: missing or too many arguments do not cause any compile error or warning. The same is true if the return type of the called function changes. This can lead to quite random bugs. - Sign and zero extension of arguments is missing. Given that the s390 C ABI requires that the caller of a function performs proper sign and zero extension this can also lead to subtle bugs. - If arguments to the CALL_ON_STACK() macros contain functions calls register corruption can happen due to register asm constructs being used. Therefore introduce a new call_on_stack() macro which is supposed to fix all these problems. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25s390/traps: do not test MONITOR CALL without CONFIG_BUGIlya Leoshkevich
[ Upstream commit b8e9cc20b808e26329090c19ff80b7f5098e98ff ] tinyconfig fails to boot, because without CONFIG_BUG report_bug() always returns BUG_TRAP_TYPE_BUG, which causes mc 0,0 in test_monitor_call() to panic. Fix by skipping the test without CONFIG_BUG. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25perf/x86/intel/uncore: Clean up error handling path of iio mappingKan Liang
[ Upstream commit d4ba0b06306a70c99a43f9d452886a86e2d3bd26 ] The error handling path of iio mapping looks fragile. We already fixed one issue caused by it, commit f797f05d917f ("perf/x86/intel/uncore: Fix for iio mapping on Skylake Server"). Clean up the error handling path and make the code robust. Reported-by: gushengxian <gushengxian@yulong.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/40e66cf9-398b-20d7-ce4d-433be6e08921@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arch/arm64/boot/dts/marvell: fix NAND partitioning schemeKonstantin Porotchkin
[ Upstream commit e3850467bf8c82de4a052619136839fe8054b774 ] Eliminate 1MB gap between Linux and filesystem partitions. Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arm64: dts: imx8mq: assign PCIe clocksLucas Stach
[ Upstream commit 15a5261e4d052bf85c7fba24dbe0e9a7c8c05925 ] This fixes multiple issues with the current non-existent PCIe clock setup: The controller can run at up to 250MHz, so use a parent that provides this clock. The PHY needs an exact 100MHz reference clock to function if the PCIe refclock is not fed in via the refclock pads. While this mode is not supported (yet) in the driver it doesn't hurt to make sure we are providing a clock with the right rate. The AUX clock is specified to have a maximum clock rate of 10MHz. So the current setup, which drives it straight from the 25MHz oscillator is actually overclocking the AUX input. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arm64: dts: ls208xa: remove bus-num from dspi nodeMian Yousaf Kaukab
[ Upstream commit 8240c972c1798ea013cbb407722295fc826b3584 ] On LS2088A-RDB board, if the spi-fsl-dspi driver is built as module then its probe fails with the following warning: [ 10.471363] couldn't get idr [ 10.471381] WARNING: CPU: 4 PID: 488 at drivers/spi/spi.c:2689 spi_register_controller+0x73c/0x8d0 ... [ 10.471651] fsl-dspi 2100000.spi: Problem registering DSPI ctlr [ 10.471708] fsl-dspi: probe of 2100000.spi failed with error -16 Reason for the failure is that bus-num property is set for dspi node. However, bus-num property is not set for the qspi node. If probe for spi-fsl-qspi happens first then id 0 is dynamically allocated to it. Call to spi_register_controller() from spi-fsl-dspi driver then fails. Since commit 29d2daf2c33c ("spi: spi-fsl-dspi: Make bus-num property optional") bus-num property is optional. Remove bus-num property from dspi node to fix the issue. Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: OMAP2+: Block suspend for am3 and am4 if PM is not configuredTony Lindgren
[ Upstream commit 093a474ce10d8ea3db3ef2922aca5a38f34bab1b ] If the PM related modules are not loaded and PM firmware not configured, the system suspend fails to resume. Let's fix this by adding initial platform_suspend_ops to block suspend and warn about missing modules. When pm33xx and wkup_m3_ipc have been loaded and m3 coprocessor booted with it's firmware, pm33xx sets up working platform_suspend_ops. Note that we need to configure at least PM_SUSPEND_STANDBY to have suspend_set_ops(). Cc: Dave Gerlach <d-gerlach@ti.com> Cc: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix stpmic node for stm32mp1 boardsAlexandre Torgue
[ Upstream commit 4bf4abe19089245b7b12f35e5cafb5477b3e2c48 ] On some STM32 MP15 boards, stpmic node is not correct which generates warnings running "make dtbs_check W=1" command. Issues are: -"regulator-active-discharge" is not a boolean but an uint32. -"regulator-over-current-protection" is not a valid entry for vref_ddr. -LDO4 has a fixed voltage (3v3) so min/max entries are not allowed. Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: Rename spi-flash/mx66l51235l@N to flash@N on DHCOM SoMMarek Vasut
[ Upstream commit 9b8a9b389d8464e1ca5a4e92c6a4422844ad4ef3 ] Fix the following dtbs_check warning: spi-flash@0: $nodename:0: 'spi-flash@0' does not match '^flash(@.*)?$' Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: Drop unused linux,wakeup from touchscreen node on DHCOM SoMMarek Vasut
[ Upstream commit 5247a50c8b53ca214a488da648e1bb35c35c2597 ] Fix the following dtbs_check warning: touchscreen@38: 'linux,wakeup' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix the Odyssey SoM eMMC VQMMC supplyGrzegorz Szymaszek
[ Upstream commit f493162319788802b6a49634f7268e691b4c10ec ] The Seeed SoM-STM32MP157C device tree had the eMMC’s (SDMMC2) VQMMC supply set to v3v3 (buck4), the same as the VMMC supply. That was incorrect, as on the SoM, the VQMMC supply is provided from vdd (buck3) instead. Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: move stmmac axi config in ethernet node on stm32mp15Alexandre Torgue
[ Upstream commit fb1406335c067be074eab38206cf9abfdce2fb0b ] It fixes the following warning seen running "make dtbs_check W=1" Warning (simple_bus_reg): /soc/stmmac-axi-config: missing or empty reg/ranges property Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix i2c node name on stm32f746 to prevent warningsAlexandre Torgue
[ Upstream commit ad0ed10ba5792064fc3accbf8f0341152a57eecb ] Replace upper case by lower case in i2c nodes name. Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: rockchip: fix supply properties in io-domains nodesJohan Jonker
[ Upstream commit f07edc41220b14ce057a4e6d7161b30688ddb8a2 ] A test with rockchip-io-domain.yaml gives notifications for supply properties in io-domains nodes. Fix them all into ".*-supply$" format. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210606181632.13371-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arm64: dts: juno: Update SCPI nodes as per the YAML schemaSudeep Holla
[ Upstream commit 70010556b158a0fefe43415fb0c58347dcce7da0 ] The SCPI YAML schema expects standard node names for clocks and power domain controllers. Fix those as per the schema for Juno platforms. Link: https://lore.kernel.org/r/20210608145133.2088631-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: bcm283x: Fix up GPIO LED node namesStefan Wahren
[ Upstream commit 5f30dacf37bc93308e91e4d0fc94681ca73f0f91 ] Fix the node names for the GPIO LEDs to conform to the standard node name led-.. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1622981777-5023-6-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: bcm283x: Fix up MMC node namesStefan Wahren
[ Upstream commit f230c32349eb0a43a012a81c08a7f13859b86cbb ] Fix the node names for the MMC/SD card controller to conform to the standard node name mmc@.. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1622981777-5023-2-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix timer nodes on STM32 MCU to prevent warningsAlexandre Torgue
[ Upstream commit 2388f14d8747f8304e26ee870790e188c9431efd ] Prevent warning seen with "make dtbs_check W=1" command: Warning (avoid_unnecessary_addr_size): /soc/timers@40001c00: unnecessary address-cells/size-cells without "ranges" or child "reg" property Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix RCC node name on stm32f429 MCUAlexandre Torgue
[ Upstream commit e4b948415a89a219d13e454011cdcf9e63ecc529 ] This prevent warning observed with "make dtbs_check W=1" Warning (simple_bus_reg): /soc/rcc@40023810: simple-bus unit address format error, expected "40023800" Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix gpio-keys node on STM32 MCU boardsAlexandre Torgue
[ Upstream commit bf24b91f4baf7e421c770a1d9c7d381b10206ac9 ] Fix following warning observed with "make dtbs_check W=1" command. It concerns f429 eval and disco boards, f769 disco board. Warning (unit_address_vs_reg): /gpio_keys/button@0: node has a unit name, but no reg or ranges property Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: fix stm32mp157c-odyssey card detect pinGrzegorz Szymaszek
[ Upstream commit 0171b07373cc8c2815ca5fa79a7308fdefa54ca4 ] The microSD card detect pin is physically connected to the MPU pin PI3. The Device Tree configuration of the card detect pin was wrong—it was set to pin PB7 instead. If such configuration was used, the kernel would hang on “Waiting for root device” when booting from a microSD card. Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: Fix touchscreen node on dhcom-pdk2Marek Vasut
[ Upstream commit 4b5fadef3fc2ab8863ffdf31eed6a745b1bf6e61 ] Fix make dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml:0:0: /soc/i2c@40015000/polytouch@38: failed to match any schema with compatible: ['edt,edt-ft5x06'] Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: stm32: Remove extra size-cells on dhcom-pdk2Marek Vasut
[ Upstream commit 28b9a4679d8074512f12967497c161b992eb3b75 ] Fix make dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: gpio-keys-polled: '#address-cells' is a dependency of '#size-cells' arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: gpio-keys: '#address-cells' is a dependency of '#size-cells' Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arm64: dts: qcom: sc7180: Move rmtfs memory regionSujit Kautkar
[ Upstream commit d4282fb4f8f9683711ae6c076da16aa8e675fdbd ] Move rmtfs memory region so that it does not overlap with system RAM (kernel data) when KAsan is enabled. This puts rmtfs right after mba_mem which is not supposed to increase beyond 0x94600000 Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Sujit Kautkar <sujitka@chromium.org> Link: https://lore.kernel.org/r/20210514113430.1.Ic2d032cd80424af229bb95e2c67dd4de1a70cb0c@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: tegra: nexus7: Correct 3v3 regulator GPIO of PM269 variantDmitry Osipenko
[ Upstream commit c4dd6066bc304649e3159f1c7a08ece25d537e00 ] The 3v3 regulator GPIO is GP6 and not GP7, which is the DDR regulator. Both regulators are always-on, nevertheless the DT model needs to be corrected, fix it. Reported-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: tegra: wm8903: Fix polarity of headphones-detection GPIO in device-treesDmitry Osipenko
[ Upstream commit 5f45da704de425d74abd75feaa928fc8a3df03ba ] All Tegra boards which use WM8903 audio codec are specifying a wrong polarity for the headphones detection GPIO. The kernel driver hardcodes the polarity to active-low, which is the correct polarity, so we can fix the device-trees safely. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arm64: dts: ti: k3-am654x/j721e/j7200-common-proc-board: Fix MCU_RGMII1_TXC ↵Grygorii Strashko
direction [ Upstream commit 69db725cdb2b803af67897a08ea54467d11f6020 ] The MCU RGMII MCU_RGMII1_TXC pin is defined as input by mistake, although this does not make any difference functionality wise it's better to update to avoid confusion. Hence fix MCU RGMII MCU_RGMII1_TXC pin pinmux definitions to be an output in K3 am654x/j721e/j7200 board files. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210526132041.6104-1-grygorii.strashko@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: OMAP2+: Replace underscores in sub-mailbox node namesSuman Anna
[ Upstream commit 9e7f5ee1137397def6580461e27e5efcb68183ee ] A number of sub-mailbox node names in various OMAP2+ dts files are currently using underscores. This is not adhering to the node name convention, fix all of these to use hiphens. These nodes are already using the prefix mbox, so they will be in compliance with the sub-mailbox node name convention being added in the OMAP Mailbox YAML binding as well. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: am335x: fix ti,no-reset-on-init flag for gpiosGrygorii Strashko
[ Upstream commit d7d30b8fcd111e9feb171023c0e0c8d855582dcb ] The ti,no-reset-on-init flag need to be at the interconnect target module level for the modules that have it defined. The ti-sysc driver handles this case, but produces warning, not a critical issue. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: am437x-gp-evm: fix ti,no-reset-on-init flag for gpiosGrygorii Strashko
[ Upstream commit 2566d5b8c1670f7d7a44cc1426d254147ec5c421 ] The ti,no-reset-on-init flag need to be at the interconnect target module level for the modules that have it defined. The ti-sysc driver handles this case, but produces warning, not a critical issue. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: am57xx-cl-som-am57x: fix ti,no-reset-on-init flag for gpiosGrygorii Strashko
[ Upstream commit b644c5e01c870056e13a096e14b9a92075c8f682 ] The ti,no-reset-on-init flag need to be at the interconnect target module level for the modules that have it defined. The ti-sysc driver handles this case, but produces warning, not a critical issue. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: imx6dl-riotboard: configure PHY clock and set proper EEE valueOleksij Rempel
[ Upstream commit 723de6a4126b2474a8106e943749e1554012dad6 ] Without SoC specific PHY fixups the network interface on this board will fail to work. Provide missing DT properties to make it work again. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: ux500: Fix orientation of accelerometerLinus Walleij
[ Upstream commit 4beba4011995a2c44ee27e1d358dc32e6b9211b3 ] This adds a mounting matrix to the accelerometer on the TVK1281618 R3. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: ux500: Rename gpio-controller nodeSebastian Reichel
[ Upstream commit 4917b702818872fdf2a9973705af3aa7d3d1f19e ] Rename the AB8500 gpio controller node from ab8500-gpio to ab8500-gpiocontroller, since -gpio is a common suffix for gpio consumers. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25ARM: dts: ux500: Fix interrupt cellsSebastian Reichel
[ Upstream commit e4ff0112a03c2e353c8457cd33c88feb89dfec41 ] Fix interrupt cells in DT AB8500/AB8505 source files. The compiled DTB files will stay the same. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-25arm64: dts: rockchip: fix regulator-gpio states arrayJohan Jonker
[ Upstream commit b82f8e2992534aab0fa762a37376be30df263701 ] A test with the command below gives this error: /arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml: sdmmcio-regulator: states:0: [1800000, 1, 3300000, 0] is too long dtbs_check expects regulator-gpio states in a format of 2 per item, so fix them all. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ regulator/gpio-regulator.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210510215840.16270-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 05:30:31 +0000