summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-03-10alpha/boot/tools/objstrip: fix the check for ELF headerAl Viro1-1/+1
[ Upstream commit 1878787797cbb019eeefe6f905514dcd557302b6 ] Just memcmp() with ELFMAG - that's the normal way to do it in userland code, which that thing is. Besides, that has the benefit of actually building - str_has_prefix() is *NOT* present in <string.h>. Fixes: 5f14596e55de "alpha: Replace strncmp with str_has_prefix" Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10sparc: allow PM configs for sparc32 COMPILE_TESTRandy Dunlap1-1/+1
[ Upstream commit 7be6a87c2473957090995b7eb541e31d57a2c801 ] When doing randconfig builds for sparc32 with COMPILE_TEST, some (non-Sparc) drivers cause kconfig warnings with the Kconfig symbols PM, PM_GENERIC_DOMAINS, or PM_GENERIC_DOMAINS_OF. This is due to arch/sparc/Kconfig not using the PM Kconfig for Sparc32: if SPARC64 source "kernel/power/Kconfig" endif Arnd suggested adding "|| COMPILE_TEST" to the conditional, instead of trying to track down every driver that selects any of these PM symbols. Fixes the following kconfig warnings: WARNING: unmet direct dependencies detected for PM Depends on [n]: SPARC64 [=n] Selected by [y]: - SUN20I_PPU [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) WARNING: unmet direct dependencies detected for PM Depends on [n]: SPARC64 [=n] Selected by [y]: - SUN20I_PPU [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS Depends on [n]: SPARC64 [=n] && PM [=y] Selected by [y]: - QCOM_GDSC [=y] && COMMON_CLK [=y] && PM [=y] - SUN20I_PPU [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) - MESON_GX_PM_DOMAINS [=y] && (ARCH_MESON || COMPILE_TEST [=y]) && PM [=y] && OF [=y] - BCM2835_POWER [=y] && (ARCH_BCM2835 || COMPILE_TEST [=y] && OF [=y]) && PM [=y] - BCM_PMB [=y] && (ARCH_BCMBCA || COMPILE_TEST [=y] && OF [=y]) && PM [=y] - ROCKCHIP_PM_DOMAINS [=y] && (ARCH_ROCKCHIP || COMPILE_TEST [=y]) && PM [=y] Selected by [m]: - ARM_SCPI_POWER_DOMAIN [=m] && (ARM_SCPI_PROTOCOL [=m] || COMPILE_TEST [=y] && OF [=y]) && PM [=y] - MESON_EE_PM_DOMAINS [=m] && (ARCH_MESON || COMPILE_TEST [=y]) && PM [=y] && OF [=y] - QCOM_AOSS_QMP [=m] && (ARCH_QCOM || COMPILE_TEST [=y]) && MAILBOX [=y] && COMMON_CLK [=y] && PM [=y] WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS_OF Depends on [n]: SPARC64 [=n] && PM_GENERIC_DOMAINS [=y] && OF [=y] Selected by [y]: - MESON_GX_PM_DOMAINS [=y] && (ARCH_MESON || COMPILE_TEST [=y]) && PM [=y] && OF [=y] Selected by [m]: - MESON_EE_PM_DOMAINS [=m] && (ARCH_MESON || COMPILE_TEST [=y]) && PM [=y] && OF [=y] Link: https://lkml.kernel.org/r/20230205004357.29459-1-rdunlap@infradead.org Fixes: bdde6b3c8ba4 ("sparc64: Hibernation support") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Suggested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Kirill Tkhai <tkhai@yandex.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10LoongArch, bpf: Use 4 instructions for function address in JITHengqi Chen2-1/+22
[ Upstream commit 64f50f6575721ef03d001e907455cbe3baa2a5b1 ] This patch fixes the following issue of function calls in JIT, like: [ 29.346981] multi-func JIT bug 105 != 103 The issus can be reproduced by running the "inline simple bpf_loop call" verifier test. This is because we are emiting 2-4 instructions for 64-bit immediate moves. During the first pass of JIT, the placeholder address is zero, emiting two instructions for it. In the extra pass, the function address is in XKVRANGE, emiting four instructions for it. This change the instruction index in JIT context. Let's always use 4 instructions for function address in JIT. So that the instruction sequences don't change between the first pass and the extra pass for function calls. Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://lore.kernel.org/bpf/20230214152633.2265699-1-hengqi.chen@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10RISC-V: time: initialize hrtimer based broadcast clock event deviceConor Dooley1-0/+3
[ Upstream commit 8b3b8fbb4896984b5564789a42240e4b3caddb61 ] Similarly to commit 022eb8ae8b5e ("ARM: 8938/1: kernel: initialize broadcast hrtimer based clock event device"), RISC-V needs to initiate hrtimer based broadcast clock event device before C3STOP can be used. Otherwise, the introduction of C3STOP for the RISC-V arch timer in commit 232ccac1bd9b ("clocksource/drivers/riscv: Events are stopped during CPU suspend") leaves us without any broadcast timer registered. This prevents the kernel from entering oneshot mode, which breaks timer behaviour, for example clock_nanosleep(). A test app that sleeps each cpu for 6, 5, 4, 3 ms respectively, HZ=250 & C3STOP enabled, the sleep times are rounded up to the next jiffy: == CPU: 1 == == CPU: 2 == == CPU: 3 == == CPU: 4 == Mean: 7.974992 Mean: 7.976534 Mean: 7.962591 Mean: 3.952179 Std Dev: 0.154374 Std Dev: 0.156082 Std Dev: 0.171018 Std Dev: 0.076193 Hi: 9.472000 Hi: 10.495000 Hi: 8.864000 Hi: 4.736000 Lo: 6.087000 Lo: 6.380000 Lo: 4.872000 Lo: 3.403000 Samples: 521 Samples: 521 Samples: 521 Samples: 521 Link: https://lore.kernel.org/linux-riscv/YzYTNQRxLr7Q9JR0@spud/ Fixes: 232ccac1bd9b ("clocksource/drivers/riscv: Events are stopped during CPU suspend") Suggested-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20230103141102.772228-2-apatel@ventanamicro.com Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10m68k: /proc/hardware should depend on PROC_FSRandy Dunlap1-0/+1
[ Upstream commit 1e5b5df65af99013b4d31607ddb3ca5731dbe44d ] When CONFIG_PROC_FS is not set, there is a build error for an unused function. Make PROC_HARDWARE depend on PROC_FS to prevent this error. In file included from ../arch/m68k/kernel/setup.c:3: ../arch/m68k/kernel/setup_mm.c:477:12: error: 'hardware_proc_show' defined but not used [-Werror=unused-function] 477 | static int hardware_proc_show(struct seq_file *m, void *v) | ^~~~~~~~~~~~~~~~~~ Fixes: 66d857b08b8c ("m68k: merge m68k and m68knommu arch directories") # v3.0 Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20230209010825.24136-1-rdunlap@infradead.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/ap: fix status returned by ap_qact()Halil Pasic1-1/+4
[ Upstream commit a2522c80f074c35254974fec39fffe8b8d75befe ] Since commit 159491f3b509 ("s390/ap: rework assembler functions to use unions for in/out register variables") the function ap_qact() tries to grab the status from the wrong part of the register. Thus we always end up with zeros. Which is wrong, among others, because we detect failures via status.response_code. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reported-by: Harald Freudenberger <freude@linux.ibm.com> Fixes: 159491f3b509 ("s390/ap: rework assembler functions to use unions for in/out register variables") Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/ap: fix status returned by ap_aqic()Halil Pasic1-2/+5
[ Upstream commit 394740d7645ea767795074287769dd26dbd4d782 ] There function ap_aqic() tries to grab the status from the wrong part of the register. Thus we always end up with zeros. Which is wrong, among others, because we detect failures via status.response_code. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reported-by: Janosch Frank <frankja@linux.ibm.com> Fixes: 159491f3b509 ("s390/ap: rework assembler functions to use unions for in/out register variables") Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/boot: fix mem_detect extended area allocationVasily Gorbik4-52/+31
[ Upstream commit 22476f47b6b7fb7d066c71f67ebc11892adb0849 ] Allocation of mem_detect extended area was not considered neither in commit 9641b8cc733f ("s390/ipl: read IPL report at early boot") nor in commit b2d24b97b2a9 ("s390/kernel: add support for kernel address space layout randomization (KASLR)"). As a result mem_detect extended theoretically may overlap with ipl report or randomized kernel image position. But as mem_detect code will allocate extended area only upon exceeding 255 online regions (which should alternate with offline memory regions) it is not seen in practice. To make sure mem_detect extended area does not overlap with ipl report or randomized kernel position extend usage of "safe_addr". Make initrd handling and mem_detect extended area allocation code move it further right and make KASLR takes in into consideration as well. Fixes: 9641b8cc733f ("s390/ipl: read IPL report at early boot") Fixes: b2d24b97b2a9 ("s390/kernel: add support for kernel address space layout randomization (KASLR)") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/mem_detect: rely on diag260() if sclp_early_get_memsize() failsVasily Gorbik1-1/+1
[ Upstream commit eb33f9eb304a4c18beb5ba6362eaa5c4beaf40d8 ] In case sclp_early_get_memsize() fails but diag260() succeeds make sure some sane value is returned. This error scenario is highly unlikely, but this change makes system able to boot in such case. Suggested-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Stable-dep-of: 22476f47b6b7 ("s390/boot: fix mem_detect extended area allocation") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/boot: cleanup decompressor header filesAlexander Gordeev3-28/+23
[ Upstream commit 9c3205b2b062420c26b33924b910880889acf832 ] Move declarations to appropriate header files. Instead of cryptic casting directly assign struct vmlinux_info type to _vmlinux_info linker script variable - wich it actually is. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Stable-dep-of: 22476f47b6b7 ("s390/boot: fix mem_detect extended area allocation") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/vmem: fix empty page tables cleanup under KASANVasily Gorbik1-3/+3
[ Upstream commit 108303b0a2d27cb14eed565e33e64ad9eefe5d7e ] Commit b9ff81003cf1 ("s390/vmem: cleanup empty page tables") introduced empty page tables cleanup in vmem code, but when the kernel is built with KASAN enabled the code has no effect due to wrong KASAN shadow memory intersection condition, which effectively ignores any memory range below KASAN shadow. Fix intersection condition to make code work as anticipated. Fixes: b9ff81003cf1 ("s390/vmem: cleanup empty page tables") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/mem_detect: fix detect_memory() error handlingVasily Gorbik1-1/+1
[ Upstream commit 3400c35a4090704e6c465449616ab7e67a9209e7 ] Currently if for some reason sclp_early_read_info() fails, sclp_early_get_memsize() will not set max_physmem_end and it will stay uninitialized. Any garbage value other than 0 will lead to detect_memory() taking wrong path or returning a garbage value as max_physmem_end. To avoid that simply initialize max_physmem_end. Fixes: 73045a08cf55 ("s390: unify identity mapping limits handling") Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/bpf: Add expoline to tail callsIlya Leoshkevich1-2/+10
[ Upstream commit bb4ef8fc3d193ed8d5583fb47cbeff5d8fb8302f ] All the indirect jumps in the eBPF JIT already use expolines, except for the tail call one. Fixes: de5cb6eb514e ("s390: use expoline thunks in the BPF JIT") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/r/20230129190501.1624747-3-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10x86/microcode: Adjust late loading result reporting messageAshok Raj1-4/+7
[ Upstream commit 6eab3abac7043226e5375e9ead0c7607ced6767b ] During late microcode loading, the "Reload completed" message is issued unconditionally, regardless of success or failure. Adjust the message to report the result of the update. [ bp: Massage. ] Fixes: 9bd681251b7c ("x86/microcode: Announce reload operation's completion") Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/lkml/874judpqqd.ffs@tglx/ Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10x86/microcode: Check CPU capabilities after late microcode update correctlyAshok Raj3-13/+30
[ Upstream commit c0dd9245aa9e25a697181f6085692272c9ec61bc ] The kernel caches each CPU's feature bits at boot in an x86_capability[] structure. However, the capabilities in the BSP's copy can be turned off as a result of certain command line parameters or configuration restrictions, for example the SGX bit. This can cause a mismatch when comparing the values before and after the microcode update. Another example is X86_FEATURE_SRBDS_CTRL which gets added only after microcode update: # --- cpuid.before 2023-01-21 14:54:15.652000747 +0100 # +++ cpuid.after 2023-01-21 14:54:26.632001024 +0100 # @@ -10,7 +10,7 @@ CPU: # 0x00000004 0x04: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 # 0x00000005 0x00: eax=0x00000040 ebx=0x00000040 ecx=0x00000003 edx=0x11142120 # 0x00000006 0x00: eax=0x000027f7 ebx=0x00000002 ecx=0x00000001 edx=0x00000000 # - 0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc002400 # + 0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc002e00 ^^^ and which proves for a gazillionth time that late loading is a bad bad idea. microcode_check() is called after an update to report any previously cached CPUID bits which might have changed due to the update. Therefore, store the cached CPU caps before the update and compare them with the CPU caps after the microcode update has succeeded. Thus, the comparison is done between the CPUID *hardware* bits before and after the upgrade instead of using the cached, possibly runtime modified values in BSP's boot_cpu_data copy. As a result, false warnings about CPUID bits changes are avoided. [ bp: - Massage. - Add SRBDS_CTRL example. - Add kernel-doc. - Incorporate forgotten review feedback from dhansen. ] Fixes: 1008c52c09dc ("x86/CPU: Add a microcode loader callback") Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230109153555.4986-3-ashok.raj@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10x86/microcode: Add a parameter to microcode_check() to store CPU capabilitiesAshok Raj3-10/+16
[ Upstream commit ab31c74455c64e69342ddab21fd9426fcbfefde7 ] Add a parameter to store CPU capabilities before performing a microcode update so that CPU capabilities can be compared before and after update. [ bp: Massage. ] Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230109153555.4986-2-ashok.raj@intel.com Stable-dep-of: c0dd9245aa9e ("x86/microcode: Check CPU capabilities after late microcode update correctly") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10x86/signal: Fix the value returned by strict_sas_size()Christophe JAILLET1-1/+1
[ Upstream commit ef6dfc4b238a435ab552207ec09e4a82b6426d31 ] Functions used with __setup() return 1 when the argument has been successfully parsed. Reverse the returned value so that 1 is returned when kstrtobool() is successful (i.e. returns 0). My understanding of these __setup() functions is that returning 1 or 0 does not change much anyway - so this is more of a cleanup than a functional fix. I spot it and found it spurious while looking at something else. Even if the output is not perfect, you'll get the idea with: $ git grep -B2 -A10 retu.*kstrtobool | grep __setup -B10 Fixes: 3aac3ebea08f ("x86/signal: Implement sigaltstack size validation") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/73882d43ebe420c9d8fb82d0560021722b243000.1673717552.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10s390/early: fix sclp_early_sccb variable lifetimeAlexander Gordeev2-1/+1
[ Upstream commit 639886b71ddef085a0e7bb1f225b8ae3eda5c06f ] Commit ada1da31ce34 ("s390/sclp: sort out physical vs virtual pointers usage") fixed the notion of virtual address for sclp_early_sccb pointer. However, it did not take into account that kasan_early_init() can also output messages and sclp_early_sccb should be adjusted by the time kasan_early_init() is called. Currently it is not a problem, since virtual and physical addresses on s390 are the same. Nevertheless, should they ever differ, this would cause an invalid pointer access. Fixes: ada1da31ce34 ("s390/sclp: sort out physical vs virtual pointers usage") Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64/sysreg: Fix errors in 32 bit enumeration valuesMark Brown1-4/+4
[ Upstream commit 8c6e105558628b63292ae770198f11a1d5535660 ] The recently converted 32 bit ID registers have errors in MVFR0_EL1.FPSP, MVFR0_EL1.SIMDReg and MVFR1_EL1.SIMDHP where enumeration values which should be 0b0010 are specified as 0b0001. Correct these. Fixes: e79c94a2a487 ("arm64/sysreg: Convert MVFR0_EL1 to automatic generation") Fixes: c9b718eda706 ("arm64/sysreg: Convert MVFR1_EL1 to automatic generation") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221207-arm64-sysreg-helpers-v3-2-0d71a7b174a8@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64/cpufeature: Fix field sign for DIT hwcap detectionMark Brown1-1/+1
[ Upstream commit 50daf5b7c4ec4efcaf49a4128930f872bec7dbc0 ] Since it was added our hwcap for DIT has specified that DIT is a signed field but this appears to be incorrect, the two values for the enumeration are: 0b0000 NI 0b0001 IMP which look like a normal unsigned enumeration and the in-kernel DIT usage added by 01ab991fc0ee ("arm64: Enable data independent timing (DIT) in the kernel") detects the feature with an unsigned enum. Fix the hwcap to specify the field as unsigned. Fixes: 7206dc93a58f ("arm64: Expose Arm v8.4 features") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20221207-arm64-sysreg-helpers-v3-1-0d71a7b174a8@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10crypto: x86/ghash - fix unaligned access in ghash_setkey()Eric Biggers1-3/+3
[ Upstream commit 116db2704c193fff6d73ea6c2219625f0c9bdfc8 ] The key can be unaligned, so use the unaligned memory access helpers. Fixes: 8ceee72808d1 ("crypto: ghash-clmulni-intel - use C implementation for setkey()") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: pmk8350: Use the correct PON compatibleKonrad Dybcio1-1/+1
[ Upstream commit c0ee8e0ba5cc17623e63349a168b41e407b1eef0 ] A special compatible was introduced for PMK8350 both in the driver and the bindings to facilitate for 2 base registers (PBS & HLOS). Use it. Fixes: b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230213212930.2115182-1-konrad.dybcio@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10x86/perf/zhaoxin: Add stepping check for ZXCsilviazhao1-1/+7
[ Upstream commit fd636b6a9bc6034f2e5bb869658898a2b472c037 ] Some of Nano series processors will lead GP when accessing PMC fixed counter. Meanwhile, their hardware support for PMC has not announced externally. So exclude Nano CPUs from ZXC by checking stepping information. This is an unambiguous way to differentiate between ZXC and Nano CPUs. Following are Nano and ZXC FMS information: Nano FMS: Family=6, Model=F, Stepping=[0-A][C-D] ZXC FMS: Family=6, Model=F, Stepping=E-F OR Family=6, Model=0x19, Stepping=0-3 Fixes: 3a4ac121c2ca ("x86/perf: Add hardware performance events support for Zhaoxin CPU.") Reported-by: Arjan <8vvbbqzo567a@nospam.xutrox.com> Reported-by: Kevin Brace <kevinbrace@gmx.com> Signed-off-by: silviazhao <silviazhao-oc@zhaoxin.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=212389 Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10perf/x86/intel/ds: Fix the conversion from TSC to perf timeKan Liang1-9/+26
[ Upstream commit 89e97eb8cec0f1af5ebf2380308913256ca7915a ] The time order is incorrect when the TSC in a PEBS record is used. $perf record -e cycles:upp dd if=/dev/zero of=/dev/null count=10000 $ perf script --show-task-events perf-exec 0 0.000000: PERF_RECORD_COMM: perf-exec:915/915 dd 915 106.479872: PERF_RECORD_COMM exec: dd:915/915 dd 915 106.483270: PERF_RECORD_EXIT(915:915):(914:914) dd 915 106.512429: 1 cycles:upp: ffffffff96c011b7 [unknown] ([unknown]) ... ... The perf time is from sched_clock_cpu(). The current PEBS code unconditionally convert the TSC to native_sched_clock(). There is a shift between the two clocks. If the TSC is stable, the shift is consistent, __sched_clock_offset. If the TSC is unstable, the shift has to be calculated at runtime. This patch doesn't support the conversion when the TSC is unstable. The TSC unstable case is a corner case and very unlikely to happen. If it happens, the TSC in a PEBS record will be dropped and fall back to perf_event_clock(). Fixes: 47a3aeb39e8d ("perf/x86/intel/pebs: Fix PEBS timestamps overwritten") Reported-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/CAM9d7cgWDVAq8-11RbJ2uGfwkKD6fA-OMwOKDrNUrU_=8MgEjg@mail.gmail.com/ Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8992-lg-bullhead: Enable regulatorsPetr Vorel1-22/+10
[ Upstream commit 2866527093ddbc6356bb31f560f0b4b4decf3e2e ] Enable pm8994_s1, pm8994_l{26,29,30,32} regulators. Use values from downstream kernel on bullhead rev 1.01. NOTE: downstream kernel on angler rev 1.01 differences: * pm8994_l29: regulator-min-microvolt = <2700000> * pm8994_l{20,28,31}: use regulator-boot-on Verification: [ 1.832460] s1: Bringing 0uV into 1025000-1025000uV ... [ 2.057667] l26: Bringing 0uV into 987500-987500uV ... [ 2.075722] l29: Bringing 0uV into 2800000-2800000uV [ 2.076604] l30: Bringing 0uV into 1800000-1800000uV [ 2.082431] l31: Bringing 0uV into 1262500-1262500uV [ 2.095767] l32: Bringing 0uV into 1800000-1800000uV Fixes: f3b2c99e73be ("arm64: dts: Enable onboard SDHCI on msm8992") Signed-off-by: Petr Vorel <pvorel@suse.cz> Tested-by: Jamie Douglass <jamiemdouglass@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230203100952.13857-1-pvorel@suse.cz Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: sm6115: correct TLMM gpio-rangesKrzysztof Kozlowski1-1/+1
[ Upstream commit 272fc52431611d779de132c4e03de6e0c1199731 ] Correct the number of GPIOs in TLMM pin controller. Fixes: 97e563bf5ba1 ("arm64: dts: qcom: sm6115: Add basic soc dtsi") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Iskren Chernev <me@iskren.info> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202104452.299048-11-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8953: correct TLMM gpio-rangesKrzysztof Kozlowski1-1/+1
[ Upstream commit a4fb71497df23cb0d02d70fa2b8f8786328e325d ] Correct the number of GPIOs in TLMM pin controller. Fixes: 9fb08c801923 ("arm64: dts: qcom: Add MSM8953 device tree") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Luca Weiss <luca@z3ntu.xyz> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202104452.299048-10-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8992-lg-bullhead: Correct memory overlaps with the SMEM ↵Jamie Douglass1-2/+7
and MPSS memory regions [ Upstream commit d44106883d74992343710f18c4aaae937c7cefab ] The memory region reserved by a previous commit (see fixes tag below) overlaps with the SMEM and MPSS memory regions, causing error messages in dmesg: OF: reserved mem: OVERLAP DETECTED! reserved@5000000 (0x0000000005000000--0x0000000007200000) overlaps with smem_region@6a00000 (0x0000000006a00000--0x0000000006c00000) OF: reserved mem: OVERLAP DETECTED! reserved@6c00000 (0x0000000006c00000--0x0000000007200000) overlaps with memory@7000000 (0x0000000007000000--0x000000000ca00000) This patch resolves both of these by splitting the previously reserved memory region into two sections either side of the SMEM region and by cutting off the second memory region to 0x7000000. Fixes: 22c7e1a0fa45 ("arm64: dts: msm8992-bullhead: add memory hole region") Signed-off-by: Jamie Douglass <jamiemdouglass@gmail.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Tested-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230202054819.16079-1-jamiemdouglass@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: sm8450: drop incorrect cells from serialKrzysztof Kozlowski1-4/+0
[ Upstream commit 60d2da2c916956535cf37b7bf1ae8fefbf432e55 ] The serial/UART device node does not have children with unit addresses, so address/size cells are not correct. Fixes: f5837418479a ("arm64: dts: qcom: sm8450: add uart20 node") Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230124084951.38195-3-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: sm8350: drop incorrect cells from serialKrzysztof Kozlowski1-2/+0
[ Upstream commit 6027331e6eae9eb957d1b73a7e3255f4151d6163 ] The serial/UART device node does not have children with unit addresses, so address/size cells are not correct. Fixes: cf03cd7e12bd ("arm64: dts: qcom: sm8350: Set up WRAP0 QUPs") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230124084951.38195-2-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8996 switch from RPM_SMD_BB_CLK1 to RPM_SMD_XO_CLK_SRCDmitry Baryshkov1-7/+7
[ Upstream commit 8ae72166c2b73b0f2ce498ea15d4feceb9fef50e ] The vendor kernel uses RPM_SMD_XO_CLK_SRC clock as an CXO clock rather than using the RPM_SMD_BB_CLK1 directly. Follow this example and switch msm8996.dtsi to use RPM_SMD_XO_CLK_SRC clock instead of RPM_SMB_BB_CLK1. Fixes: 2b8c9c77c268 ("arm64: dts: qcom: msm8996: convert xo_board to RPM_SMD_BB_CLK1") Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230120061417.2623751-7-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: msm8996: support using GPLL0 as kryocc inputDmitry Baryshkov1-2/+2
[ Upstream commit ac0d84d4556cecf81ba0b1631d25d9a395235a5c ] In some cases the driver might need using GPLL0 to drive CPU clocks. Bring it in through the sys_apcs_aux clock. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113120544.59320-15-dmitry.baryshkov@linaro.org Stable-dep-of: 8ae72166c2b7 ("arm64: dts: qcom: msm8996 switch from RPM_SMD_BB_CLK1 to RPM_SMD_XO_CLK_SRC") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: qcom: sm8450-nagara: Correct firmware pathsKonrad Dybcio1-3/+3
[ Upstream commit e27f38e6255306527e32af85592d805f3360ff94 ] Nagara is definitely not SM8350, fix it! Fixes: c53532f7825c ("arm64: dts: qcom: pdx223: correct firmware paths") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230203142309.1106349-1-konrad.dybcio@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ARM: dts: stm32: Update part number NVMEM description on stm32mp131Patrick Delaunay1-0/+1
[ Upstream commit 366384e495511bea8583e44173629a3012d62db0 ] The STM32MP13x Device Part Number (also named RPN in reference manual) only uses the first 12 bits in OTP4, all the other bit are reserved and they can be different of zero; they must be masked in NVMEM result, so the number of bits must be defined in the nvmem cell description. Fixes: 1da8779c0029 ("ARM: dts: stm32: add STM32MP13 SoCs support") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mediatek: mt7986: Fix watchdog compatibleAllen-KH Cheng1-2/+1
[ Upstream commit 70d24df30d06e5c822ba94751166ef55d0e28a89 ] MT7986's watchdog embeds a reset controller and needs only the mediatek,mt7986-wdt compatible string as the MT6589 one is there for watchdogs that don't have any reset controller capability. Fixes: 50137c150f5f ("arm64: dts: mediatek: add basic mt7986 support") Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20221108033209.22751-4-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mediatek: mt8195: Fix watchdog compatibleAngeloGioacchino Del Regno1-2/+1
[ Upstream commit 02938f460cde0d360dde48056c4d1c0a4bd49230 ] MT8195's watchdog embeds a reset controller and needs only the mediatek,mt8195-wdt compatible string as the MT6589 one is there for watchdogs that don't have any reset controller capability. Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Co-developed-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20221108033209.22751-3-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mediatek: mt8186: Fix watchdog compatibleAngeloGioacchino Del Regno1-2/+1
[ Upstream commit e5e961628d696237ddc3d53d9d5ac11f43e0bf67 ] MT8186's watchdog embeds a reset controller and needs only the mediatek,mt8186-wdt compatible string as the MT6589 one is there for watchdogs that don't have any reset controller capability. Fixes: 2e78620b1350 ("arm64: dts: Add MediaTek MT8186 dts and evaluation board and Makefile") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Co-developed-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20221108033209.22751-2-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mediatek: mt7622: Add missing pwm-cells to pwm nodeAngeloGioacchino Del Regno1-0/+1
[ Upstream commit 22925af785fa3470efdf566339616d801119d348 ] Specify #pwm-cells on pwm@11006000 to make it actually usable. Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20221128112028.58021-2-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mt8186: Fix CPU map for single-cluster SoCAngeloGioacchino Del Regno1-4/+2
[ Upstream commit 1c473804b0c8a68c6ef2cf519b38ec6725ca4aa5 ] MT8186 features the ARM DynamIQ technology and combines both two Cortex-A76 (big) and six Cortex-A55 (LITTLE) CPUs in one cluster: fix the CPU map to reflect that. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 2e78620b1350 ("arm64: dts: Add MediaTek MT8186 dts and evaluation board and Makefile") Link: https://lore.kernel.org/r/20230126103526.417039-4-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mt8192: Fix CPU map for single-cluster SoCAngeloGioacchino Del Regno1-7/+4
[ Upstream commit 160ce54d635455ffb5e9b42c5ba9cb9aaa98cdb2 ] MT8192 features the ARM DynamIQ technology and combines both four Cortex-A76 (big) and four Cortex-A55 (LITTLE) CPUs in one cluster: fix the CPU map to reflect that. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 48489980e27e ("arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile") Link: https://lore.kernel.org/r/20230126103526.417039-3-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: mt8195: Fix CPU map for single-cluster SoCAngeloGioacchino Del Regno1-6/+4
[ Upstream commit cc4f0b13a887b483faa45084616998a21b63889d ] MT8195 features the ARM DynamIQ technology and combines both four Cortex-A78 (big) and four Cortex-A55 (LITTLE) CPUs in one cluster: fix the CPU map to reflect that. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Link: https://lore.kernel.org/r/20230126103526.417039-2-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ARM: dts: imx7s: correct iomuxc gpr mux controller cellsPeng Fan1-1/+1
[ Upstream commit 0e3e1946606a2919b1dda9967ab2e1c5af2fedd6 ] Per binding doc reg-mux.yaml, the #mux-control-cells should be 1 Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Fixes: 94a905a79f2c ("ARM: dts: imx7s: add multiplexer controls") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ARM: dts: sun8i: nanopi-duo2: Fix regulator GPIO referenceSamuel Holland1-1/+1
[ Upstream commit 2177d4ae971f79b4a9a3c411f2fb8ae6113d1430 ] The property named in the schema is 'enable-gpios', not 'enable-gpio'. This makes no difference at runtime, because the regulator is marked as always-on, but it breaks validation. Fixes: 4701fc6e5dd9 ("ARM: dts: sun8i: add FriendlyARM NanoPi Duo2") Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20221231225854.16320-2-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: meson: bananapi-m5: switch VDDIO_C pin to OPEN_DRAINChristian Hewitt1-1/+1
[ Upstream commit 856968e066bd77b113965f1a355ec7401edff65f ] For proper warm (re)boot from SD card the BPI-M5 board requires TFLASH_VDD_EN and VDDIO_C pins to be switched to high impedance mode. This can be achieved using OPEN_DRAIN instead of ACTIVE_HIGH to leave the GPIO pins in input mode and retain high state (pin has the pull-up). This change is inspired by meson-sm1-odroid.dtsi where OPEN_DRAIN has been used to resolve similar problems with the Odroid C4 board (TF_IO in the C4 dts is the equivalent regulator). Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts") Suggested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230127142221.3718184-2-christianshewitt@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: meson: radxa-zero: allow usb otg modeChristian Hewitt1-1/+0
[ Upstream commit ce43ea00b927805c1fd0450ccc9b4b6069e292c5 ] Setting dr_mode to "host" prevents otg which can be useful on a board with limited connectivity options. So don't force host mode. Fixes: 26d1400f7457 ("arm64: dts: amlogic: add support for Radxa Zero") Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230127103913.3386435-1-christianshewitt@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: renesas: beacon-renesom: Fix gpio expander referenceAdam Ford1-14/+10
[ Upstream commit d7f9492dfc03153ac56ab59066a196558748f575 ] The board used to originally introduce the Beacon Embedded RZ/G2[M/N/H] boards had a GPIO expander with address 20, but this was changed when the final board went to production. The production boards changed both the part itself and the address. With the incorrect address, the LCD cannot come up. If the LCD fails, the rcar-du driver fails to come up, and that also breaks HDMI. Pre-release board were not shipped to the general public, so it should be safe to push this as a fix. Anyone with a production board would have video fail due to this GPIO expander change. Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230114225647.227972-1-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: tegra: Mark host1x as dma-coherent on Tegra194/234Mikko Perttunen2-0/+2
[ Upstream commit 361238cdc52523fd7b1f3aa447c0579f42448b00 ] Ensure appropriate configuration is done to make the host1x device and context devices DMA coherent by adding the dma-coherent flag. Fixes: b35f5b53a87b ("arm64: tegra: Add context isolation domains on Tegra234") Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: amlogic: meson-sm1-odroid-hc4: fix active fan thermal tripNeil Armstrong1-1/+9
[ Upstream commit 1d2f14117aa7773efff50f832b85fc7779e586e0 ] Add an active trip tied to the on-board fan cooling device, which is better than describing it along the passive cooling maps. Fixes: 33b14f663df8 ("arm64: dts: meson: add initial device-tree for ODROID-HC4") Reported-by: Ricardo Pardini <ricardo@pardini.net> Link: https://lore.kernel.org/r/20230124-topic-odroid-hc4-upstream-fix-fan-trip-v1-1-b0c6aa355d93@linaro.org Tested-by: Ricardo Pardini <ricardo@pardini.net> [narmstrong: added Ricardo's tested-by from off-list chat] Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: amlogic: meson-g12b-odroid-go-ultra: fix rk818 pmic propertiesNeil Armstrong1-1/+1
[ Upstream commit ce9999722656f2433af9029571bc2b99448dda74 ] Fixes: pmic@1c: '#clock-cells' is a required property pmic@1c: 'switch-supply' does not match any of the regexes: 'pinctrl-[0-9]+' The switch supply is described by vcc9-supply per bindings documentation. Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-14-44351528957e@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10arm64: dts: amlogic: meson-gxbb-kii-pro: fix led node nameNeil Armstrong1-1/+1
[ Upstream commit afdef3b188c934f79ad4b0a7bd8c692742f9b5af ] Fixes: leds: status: {...} is not of type 'array' Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-13-44351528957e@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>