summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-08-15powerpc/eeh: Make EEH driver device hotplug safeTimothy Pearson2-20/+38
[ Upstream commit 1010b4c012b0d78dfb9d3132b49aa2ef024a07a7 ] Multiple race conditions existed between the PCIe hotplug driver and the EEH driver, leading to a variety of kernel oopses of the same general nature: <pcie device unplug> <eeh driver trigger> <hotplug removal trigger> <pcie tree reconfiguration> <eeh recovery next step> <oops in EEH driver bus iteration loop> A second class of oops is also seen when the underlying bus disappears during device recovery. Refactor the EEH module to be PCI rescan and remove safe. Also clean up a few minor formatting / readability issues. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/1334208367.1359861.1752615503144.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15powerpc/eeh: Export eeh_unfreeze_pe()Timothy Pearson1-0/+1
[ Upstream commit e82b34eed04b0ddcff4548b62633467235672fd3 ] The PowerNV hotplug driver needs to be able to clear any frozen PE(s) on the PHB after suprise removal of a downstream device. Export the eeh_unfreeze_pe() symbol to allow implementation of this functionality in the php_nv module. Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/1778535414.1359858.1752615454618.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15sh: Do not use hyphen in exported variable nameBen Hutchings3-9/+9
[ Upstream commit c32969d0362a790fbc6117e0b6a737a7e510b843 ] arch/sh/Makefile defines and exports ld-bfd to be used by arch/sh/boot/compressed/Makefile and arch/sh/boot/romimage/Makefile. However some shells, including dash, will not pass through environment variables whose name includes a hyphen. Usually GNU make does not use a shell to recurse, but if e.g. $(srctree) contains '~' it will use a shell here. Other instances of this problem were previously fixed by commits 2bfbe7881ee0 "kbuild: Do not use hyphen in exported variable name" and 82977af93a0d "sh: rename suffix-y to suffix_y". Rename the variable to ld_bfd. References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0 Fixes: 7b022d07a0fd ("sh: Tidy up the ldscript output format specifier.") Signed-off-by: Ben Hutchings <benh@debian.org> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: arm/aes-neonbs - work around gcc-15 warningArnd Bergmann1-1/+1
[ Upstream commit d5fa96dc5590915f060fee3209143313e4f5b03b ] I get a very rare -Wstringop-overread warning with gcc-15 for one function in aesbs_ctr_encrypt(): arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=] 212 | src = dst = memcpy(buf + sizeof(buf) - bytes, arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt': arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread] 218 | aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'} arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt' 36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[], This could happen in theory if walk.nbytes is larger than INT_MAX and gets converted to a negative local variable. Keep the type unsigned like the orignal nbytes to be sure there is no integer overflow. Fixes: c8bf850e991a ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: s390/sha3 - Use cpu byte-order when exportingHerbert Xu3-15/+37
[ Upstream commit 73c2437109c3eab274258a6430ae5dafac1ef43e ] The sha3 partial hash on s390 is in little-endian just like the final hash. However the generic implementation produces native or big-endian partial hashes. Make s390 sha3 conform to that by doing the byte-swap on export and import. Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Fixes: 6f90ba706551 ("crypto: s390/sha3 - Use API partial block handling") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15crypto: s390/hmac - Fix counter in export stateHerbert Xu1-4/+8
[ Upstream commit 1b39bc4a703a63a22c08232015540adfb31f22ba ] The hmac export state needs to be one block-size bigger to account for the ipad. Reported-by: Ingo Franzki <ifranzki@linux.ibm.com> Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15RISC-V: KVM: Fix inclusion of Smnpm in the guest ISA bitmapSamuel Holland1-30/+53
[ Upstream commit 7826c8f37220daabf90c09fcd9a835d6763f1372 ] The Smnpm extension requires special handling because the guest ISA extension maps to a different extension (Ssnpm) on the host side. commit 1851e7836212 ("RISC-V: KVM: Allow Smnpm and Ssnpm extensions for guests") missed that the vcpu->arch.isa bit is based only on the host extension, so currently both KVM_RISCV_ISA_EXT_{SMNPM,SSNPM} map to vcpu->arch.isa[RISCV_ISA_EXT_SSNPM]. This does not cause any problems for the guest, because both extensions are force-enabled anyway when the host supports Ssnpm, but prevents checking for (guest) Smnpm in the SBI FWFT logic. Redefine kvm_isa_ext_arr to look up the guest extension, since only the guest -> host mapping is unambiguous. Factor out the logic for checking for host support of an extension, so this special case only needs to be handled in one place, and be explicit about which variables hold a host vs a guest ISA extension. Fixes: 1851e7836212 ("RISC-V: KVM: Allow Smnpm and Ssnpm extensions for guests") Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20250111004702.2813013-2-samuel.holland@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15bpf, arm64: Fix fp initialization for exception boundaryPuranjay Mohan1-0/+1
[ Upstream commit b114fcee766d5101eada1aca7bb5fd0a86c89b35 ] In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF program, find_used_callee_regs() is not called because for a program acting as exception boundary, all callee saved registers are saved. find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP being used in any of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used by the program and therefore, FP is not set-up for such programs in the prologue. This can cause the kernel to crash due to a pagefault. Fix it by setting ctx->fp_used = true for exception boundary programs as fp is always saved in such programs. Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20250722133410.54161-2-puranjay@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64/gcs: task_gcs_el0_enable() should use passed taskJeremy Linton2-4/+4
[ Upstream commit cbbcfb94c55c02a8c4ce52b5da0770b5591a314c ] Mark Rutland noticed that the task parameter is ignored and 'current' is being used instead. Since this is usually what its passed, it hasn't yet been causing problems but likely will as the code gets more testing. But, once this is fixed, it creates a new bug in copy_thread_gcs() since the gcs_el_mode isn't yet set for the task before its being checked. Move gcs_alloc_thread_stack() after the new task's gcs_el0_mode initialization to avoid this. Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250719043740.4548-2-jeremy.linton@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15um: rtc: Avoid shadowing err in uml_rtc_start()Tiwei Bie1-1/+1
[ Upstream commit 4c916e3b224a02019b3cc3983a15f32bfd9a22df ] Remove the declaration of 'err' inside the 'if (timetravel)' block, as it would otherwise be unavailable outside that block, potentially leading to uml_rtc_start() returning an uninitialized value. Fixes: dde8b58d5127 ("um: add a pseudo RTC") Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250708090403.1067440-5-tiwei.bie@linux.dev Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEXJohan Korsnes1-1/+0
[ Upstream commit 75cd37c5f28b85979fd5a65174013010f6b78f27 ] This option was removed from the Kconfig in commit 8c710f75256b ("net/sched: Retire tcindex classifier") but it was not removed from the defconfigs. Fixes: 8c710f75256b ("net/sched: Retire tcindex classifier") Signed-off-by: Johan Korsnes <johan.korsnes@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250323191116.113482-1-johan.korsnes@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: fix unnecessary rebuilding when CONFIG_DEBUG_EFI=yMasahiro Yamada1-1/+1
[ Upstream commit 344b6580472451390d070c65c27f59716a1deecb ] When CONFIG_DEBUG_EFI is enabled, some objects are needlessly rebuilt. [Steps to reproduce] Enable CONFIG_DEBUG_EFI and run 'make' twice in a clean source tree. On the second run, arch/arm64/kernel/head.o is rebuilt even though no files have changed. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- clean $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [ snip ] $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CALL scripts/checksyscalls.sh AS arch/arm64/kernel/head.o AR arch/arm64/kernel/built-in.a AR arch/arm64/built-in.a AR built-in.a [ snip ] The issue is caused by the use of the $(realpath ...) function. At the time arch/arm64/kernel/Makefile is parsed on the first run, $(objtree)/vmlinux does not exist. As a result, $(realpath $(objtree)/vmlinux) expands to an empty string. On the second run of Make, $(objtree)/vmlinux already exists, so $(realpath $(objtree)/vmlinux) expands to the absolute path of vmlinux. However, this change in the command line causes arch/arm64/kernel/head.o to be rebuilt. To address this issue, use $(abspath ...) instead, which does not require the file to exist. While $(abspath ...) does not resolve symlinks, this should be fine from a debugging perspective. The GNU Make manual [1] clearly explains the difference between the two: $(realpath names...) For each file name in names return the canonical absolute name. A canonical name does not contain any . or .. components, nor any repeated path separators (/) or symlinks. In case of a failure the empty string is returned. Consult the realpath(3) documentation for a list of possible failure causes. $(abspath namees...) For each file name in names return an absolute name that does not contain any . or .. components, nor any repeated path separators (/). Note that, in contrast to realpath function, abspath does not resolve symlinks and does not require the file names to refer to an existing file or directory. Use the wildcard function to test for existence. The same problem exists in drivers/firmware/efi/libstub/Makefile.zboot. On the first run of Make, $(obj)/vmlinuz.efi.elf does not exist when the Makefile is parsed, so -DZBOOT_EFI_PATH is set to an empty string. Replace $(realpath ...) with $(abspath ...) there as well. [1]: https://www.gnu.org/software/make/manual/make.html#File-Name-Functions Fixes: 757b435aaabe ("efi: arm64: Add vmlinux debug link to the Image binary") Fixes: a050910972bb ("efi/libstub: implement generic EFI zboot") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250625125555.2504734-1-masahiroy@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15m68k: Don't unregister boot console needlesslyFinn Thain3-33/+19
[ Upstream commit 83f672a7f69ec38b1bbb27221e342937f68c11c7 ] When MACH_IS_MVME147, the boot console calls mvme147_scc_write() to generate console output. That will continue to work even after debug_cons_nputs() becomes unavailable so there's no need to unregister the boot console. Take the opportunity to remove a repeated MACH_IS_* test. Use the actual .write method (instead of a wrapper) and test that pointer instead. This means adding an unused parameter to debug_cons_nputs() for consistency with the struct console API. early_printk.c is only built when CONFIG_EARLY_PRINTK=y. As of late, head.S is only built when CONFIG_MMU_MOTOROLA=y. So let the former symbol depend on the latter, to obviate some ifdef conditionals. Cc: Daniel Palmer <daniel@0x0f.com> Fixes: 077b33b9e283 ("m68k: mvme147: Reinstate early console") Signed-off-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/d1d4328e5aa9a87bd8352529ce62b767731c0530.1743467205.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO addHaren Myneni1-2/+50
[ Upstream commit 41a1452759a8b1121df9cf7310acf31d766ba70b ] IO hotplug add event is handled in the user space with drmgr tool. After the device is enabled, the user space uses /sys/kernel/dlpar interface with “dt add index <drc_index>” to update the device tree. The kernel interface (dlpar_hp_dt_add()) finds the parent node for the specified ‘drc_index’ from ibm,drc-info property. The recent FW provides this property from 2017 onwards. But KVM guest code in some releases is still using the older SLOF firmware which has ibm,drc-indexes property instead of ibm,drc-info. If the ibm,drc-info is not available, this patch adds changes to search ‘drc_index’ from the indexes array in ibm,drc-indexes property to support old FW. Fixes: 02b98ff44a57 ("powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add") Reported-by: Kowshik Jois <kowsjois@linux.ibm.com> Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250531235002.239213-1-haren@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15MIPS: alchemy: gpio: use new GPIO line value setter callbacks for the ↵Bartosz Golaszewski1-4/+8
remaining chips [ Upstream commit 6b94bf976f9f9e6d4a6bf3218968a506c049702e ] Previous commit missed two other places that need converting, it only came out in tests on autobuilders now. Convert the rest of the driver. Fixes: 68bdc4dc1130 ("MIPS: alchemy: gpio: use new line value setter callbacks") Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://lore.kernel.org/r/20250727082442.13182-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15riscv: dts: sophgo: sg2044: Add missing riscv,cbop-block-size propertyInochi Amaoto1-0/+64
[ Upstream commit 02d548e553d161813b7d3702a311b9067806057d ] The kernel complains no "riscv,cbop-block-size" and disables the Zicbop extension. Add the missing property to keep it functional. Fixes: ae5bac370ed4 ("riscv: dts: sophgo: Add initial device tree of Sophgo SRD3-10") Link: https://lore.kernel.org/r/20250613074513.1683624-1-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: Fix UART DMA support for RK3528Jonas Karlman1-8/+8
[ Upstream commit ae019f0bdfbef3e0671e7b954321e92fc24c7e54 ] Trying to use UART2 DMA for Bluetooth on ArmSoM Sige1 result in tx timeout when using dma-names = "tx", "rx" as required by the dt-binding: Bluetooth: hci0: command 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) Change the dmas order to fix UART DMA support on RK3528. With this fixed Bluetooth can be loaded using DMA on ArmSoM Sige1: Bluetooth: hci0: BCM: chip id 159 Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM4362A2 Bluetooth: hci0: BCM4362A2 (000.017.017) build 0000 Bluetooth: hci0: BCM4362A2 'brcm/BCM4362A2.hcd' Patch Bluetooth: hci0: BCM: features 0x0f Bluetooth: hci0: BCM43752A2 UART 37.4MHz Ampak AP6398 sLNA iLNA CL1 [Version: 1091.1173] Bluetooth: hci0: BCM4362A2 (000.017.017) build 1173 Fixes: ab6fcb58aedf ("arm64: dts: rockchip: Add UART DMA support for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250709210831.3170458-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: Fix pinctrl node names for RK3528Jonas Karlman1-10/+10
[ Upstream commit f2792bf1c7a54ef23fb3a84286b66f427bfc4853 ] Following warnings can be observed with CHECK_DTBS=y for the RK3528: rk3528-pinctrl.dtsi:101.36-105.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:108.38-112.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:115.36-119.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym0-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:122.36-126.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_dpx: Character '_' not recommended in node name rk3528-pinctrl.dtsi:129.38-133.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_link: Character '_' not recommended in node name rk3528-pinctrl.dtsi:136.36-140.5: Warning (node_name_chars_strict): /pinctrl/fephy/fephym1-led_spd: Character '_' not recommended in node name rk3528-pinctrl.dtsi:782.32-790.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:793.32-801.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-tx_bus2: Character '_' not recommended in node name rk3528-pinctrl.dtsi:804.36-810.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_clk: Character '_' not recommended in node name rk3528-pinctrl.dtsi:813.36-823.5: Warning (node_name_chars_strict): /pinctrl/rgmii/rgmii-rgmii_bus: Character '_' not recommended in node name Rename the affected nodes to fix these warnings. Fixes: a31fad19ae39 ("arm64: dts: rockchip: Add pinctrl and gpio nodes for RK3528") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621113859.2146400-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: freescale: imx8mp-toradex-smarc: fix lvds dsi mux gpioMax Krummenacher2-5/+2
[ Upstream commit 29d34c678cf82341cb0bedb3179d59c56856a80f ] The MUX which either outputs DSI or 2nd channel LVDS signals is part of the SoM. Move the pinmuxing of the GPIO used for controlling the MUX to the SoM dtsi file. Fixes: 97dc91c04558 ("arm64: dts: freescale: add Toradex SMARC iMX8MP") Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: imx8mn-beacon: Fix HS400 USDHC clock speedAdam Ford1-0/+2
[ Upstream commit e16ad6c79906bba5e2ac499492b6a5b29ab19d6c ] The reference manual for the i.MX8MN states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speedAdam Ford1-0/+2
[ Upstream commit f83f69097a302ed2a2775975ddcf12e6a5ac6ec3 ] The reference manual for the i.MX8MM states the clock rate in MMC mode is 1/2 of the input clock, therefore to properly run at HS400 rates, the input clock must be 400MHz to operate at 200MHz. Currently the clock is set to 200MHz which is half the rate it should be, so the throughput is half of what it should be for HS400 operation. Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15ARM: dts: imx6ul-kontron-bl-common: Fix RTS polarity for RS485 interfaceAnnette Kobou1-1/+0
[ Upstream commit 47ef5256124fb939d8157b13ca048c902435cf23 ] The polarity of the DE signal of the transceiver is active-high for sending. Therefore rs485-rts-active-low is wrong and needs to be removed to make RS485 transmissions work. Signed-off-by: Annette Kobou <annette.kobou@kontron.de> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: st: fix timer used for ticksPatrick Delaunay1-1/+1
[ Upstream commit 9ec406ac4b7de3e8040a503429d1a5d389bfdaf6 ] Remove always-on on generic ARM timer as the clock source provided by STGEN is deactivated in low power mode, STOP1 by example. Fixes: 5d30d03aaf78 ("arm64: dts: st: introduce stm32mp25 SoCs family") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20250515151238.1.I85271ddb811a7cf73532fec90de7281cb24ce260@changeid Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: fix PHY handling for ROCK 4DSebastian Reichel1-2/+4
[ Upstream commit cd803da7c033e376a66793a43ee98e136bc6cc25 ] Old revisions of the ROCK 4D board have a dedicated crystal to supply the RTL8211F PHY's 25MHz clock input. At least some newer revisions instead use REFCLKO25M_GMAC0_OUT. The DT already has this half-prepared, but there are some issues: 1. The DT relies on auto-selecting the right PHY driver, which requires that it works good enough to read the ID registers. This does not work without the clock, which is handled by the PHY driver. By updating the compatible to contain the RTL8211F IDs, so that the operating system can choose the right PHY driver without relying on a pre-powered PHY. 2. Despite the name REFCLKO25M_GMAC0_OUT could also provide a different frequency, so ensure it is explicitly set to 25 MHz as expected by the PHY. 3. While at it switch from deprecated "enable-gpio" to standard "enable-gpios". Fixes: a0fb7eca9c09 ("arm64: dts: rockchip: Add Radxa ROCK 4D device tree") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250704-rk3576-rock4d-phy-handling-fixes-v1-1-1d64130c4139@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-verdin: fix PWM_3_DSI GPIO directionParth Pancholi1-1/+1
[ Upstream commit b1a8daa7cf2650637f6cca6aaf014bee89672120 ] PWM_3_DSI is used as the HDMI Hot-Plug Detect (HPD) GPIO for the Verdin DSI-to-HDMI adapter. After the commit 33bab9d84e52 ("arm64: dts: ti: k3-am62p: fix pinctrl settings"), the pin was incorrectly set as output without RXACTIVE, breaking HPD detection and display functionality. The issue was previously hidden and worked by chance before the mentioned pinctrl fix. Fix the pinmux configuration to correctly set PWM_3_DSI GPIO as an input. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250703084534.1649594-1-parth105105@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: renesas: r8a779g3-sparrow-hawk-fan-pwm: Add missing install targetNiklas Söderlund1-0/+1
[ Upstream commit 7e5624e231eea73a6a2c2d0b837a085267590167 ] The target to consider the dtbo file for installation is missing, add it. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/20250701112612.3957799-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm: dts: ti: omap: Fixup pinheader typoAlbin Törnqvist1-1/+1
[ Upstream commit a3a4be32b69c99fc20a66e0de83b91f8c882bf4c ] This commit fixes a typo introduced in commit ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names"). gpio0_7 is located on the P9 header on the BBB. This was verified with a BeagleBone Black by toggling the pin and checking with a multimeter that it corresponds to pin 42 on the P9 header. Signed-off-by: Albin Törnqvist <albin.tornqvist@codiax.se> Link: https://lore.kernel.org/r/20250624114839.1465115-2-albin.tornqvist@codiax.se Fixes: ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names") Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-verdin: add SD_1 CD pull-upFrancesco Dolcini1-1/+1
[ Upstream commit fefaa8d7f8012249729a987d3abce747ffab0ca7 ] Add internal pull-up to the SD_1 card detect signal, without this the CD signal is floating and spurious detects events can happen. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250701081643.71406-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: imx8mp-venice-gw74xx: update name of M2SKT_WDIS2# gpioTim Harvey1-4/+4
[ Upstream commit 26a6a9cde64a890997708007d9de25809970eac9 ] The GW74xx D revision has added a M2SKT_WDIS2# GPIO which routes to the W_DISABLE2# pin of the M.2 socket. Update the gpio name for consistency. Fixes: 6a5d95b06d93 ("arm64: dts: imx8mp-venice-gw74xx: add M2SKT_GPIO10 gpio configuration") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: Enable eMMC HS200 mode on Radxa E20CJonas Karlman1-0/+1
[ Upstream commit 6e3071f4e03997ca0e4388ca61aa06df2802dcd1 ] eMMC HS200 mode (1.8V I/O) is supported by the MMC host controller on RK3528 and works with the optional on-board eMMC module on Radxa E20C. Be explicit about HS200 support in the device tree for Radxa E20C. Fixes: 3a01b5f14a8a ("arm64: dts: rockchip: Enable onboard eMMC on Radxa E20C") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250621165832.2226160-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode alsoPawan Gupta1-2/+4
[ Upstream commit ab9f2388e0b99cd164ddbd74a6133d3070e2788d ] After a recent restructuring of the ITS mitigation, RSB stuffing can no longer be enabled in eIBRS+Retpoline mode. Before ITS, retbleed mitigation only allowed stuffing when eIBRS was not enabled. This was perfectly fine since eIBRS mitigates retbleed. However, RSB stuffing mitigation for ITS is still needed with eIBRS. The restructuring solely relies on retbleed to deploy stuffing, and does not allow it when eIBRS is enabled. This behavior is different from what was before the restructuring. Fix it by allowing stuffing in eIBRS+retpoline mode also. Fixes: 61ab72c2c6bf ("x86/bugs: Restructure ITS mitigation") Closes: https://lore.kernel.org/lkml/20250519235101.2vm6sc5txyoykb2r@desk/ Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250611-eibrs-fix-v4-7-5ff86cac6c61@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15x86/bugs: Introduce cdt_possible()Pawan Gupta1-1/+14
[ Upstream commit 8374a2719df2a00781e6821e373d7de71390d1b4 ] In preparation to allow ITS to also enable stuffing aka Call Depth Tracking (CDT) independently of retbleed, introduce a helper cdt_possible(). Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250611-eibrs-fix-v4-5-5ff86cac6c61@linux.intel.com Stable-dep-of: ab9f2388e0b9 ("x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15x86/bugs: Simplify the retbleed=stuff checksPawan Gupta1-16/+8
[ Upstream commit 530e80648bff083e1d19ad7248c0540812a9a35f ] Simplify the nested checks, remove redundant print and comment. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250611-eibrs-fix-v4-2-5ff86cac6c61@linux.intel.com Stable-dep-of: ab9f2388e0b9 ("x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15x86/bugs: Avoid AUTO after the select step in the retbleed mitigationPawan Gupta1-9/+10
[ Upstream commit 98ff5c071d1cde9426b0bfa449c43d49ec58f1c4 ] The retbleed select function leaves the mitigation to AUTO in some cases. Moreover, the update function can also set the mitigation to AUTO. This is inconsistent with other mitigations and requires explicit handling of AUTO at the end of update step. Make sure a mitigation gets selected in the select step, and do not change it to AUTO in the update step. When no mitigation can be selected leave it to NONE, which is what AUTO was getting changed to in the end. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250611-eibrs-fix-v4-1-5ff86cac6c61@linux.intel.com Stable-dep-of: ab9f2388e0b9 ("x86/bugs: Allow ITS stuffing in eIBRS+retpoline mode also") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15ARM: dts: microchip: sam9x7: Add clock name propertyRyan Wanner1-0/+2
[ Upstream commit 2e24723492b28ffdccb0e3e68725673e299e3823 ] Add clock-output-names to the xtal nodes, so the driver can correctly register the main and slow xtal. This fixes the issue of the SoC clock driver not being able to find the main xtal and slow xtal correctly causing a bad clock tree. Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC") Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/036518968ac657b93e315bb550b822b59ae6f17c.1750175453.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15ARM: dts: microchip: sama7d65: Add clock name propertyRyan Wanner1-0/+2
[ Upstream commit 0029468132ba2e00a3010865038783d9b2e6cc07 ] Add clock-output-names to the xtal nodes, so the driver can correctly register the main and slow xtal. This fixes the issue of the SoC clock driver not being able to find the main xtal and slow xtal correctly causing a bad clock tree. Fixes: 261dcfad1b59 ("ARM: dts: microchip: add sama7d65 SoC DT") Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/3878ae6d0016d46f0c91bd379146d575d5d336aa.1750175453.git.Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-j722s: fix pinctrl-single sizeMichael Walle1-1/+1
[ Upstream commit fdc8ad019ab9a2308b8cef54fbc366f482fb746f ] Pinmux registers ends at 0x000f42ac (including). Thus, the size argument of the pinctrl-single node has to be 0x2b0. Fix it. This will fix the following error: pinctrl-single f4000.pinctrl: mux offset out of range: 0x2ac (0x2ac) Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20250618065239.1904953-1-mwalle@kernel.org Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am62p-verdin: Enable pull-ups on I2C_3_HDMIEmanuele Ghidoli1-2/+2
[ Upstream commit cb2d9c00770e2e6c51864704b5d98c9a0ddccaf9 ] Enable internal bias pull-ups on the SoC-side I2C_3_HDMI that do not have external pull resistors populated on the SoM. This ensures proper default line levels. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20250529102601.452859-1-ghidoliemanuele@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: ti: k3-am642-phyboard-electra: Fix PRU-ICSSG Ethernet portsWadim Egorov1-0/+2
[ Upstream commit 945e48a39c957924bc84d1a6c137da039e13855b ] For the ICSSG PHYs to operate correctly, a 25 MHz reference clock must be supplied on CLKOUT0. Previously, our bootloader configured this clock, which is why the PRU Ethernet ports appeared to work, but the change never made it into the device tree. Add clock properties to make EXT_REFCLK1.CLKOUT0 output a 25MHz clock. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Fixes: 87adfd1ab03a ("arm64: dts: ti: am642-phyboard-electra: Add PRU-ICSSG nodes") Link: https://lore.kernel.org/r/20250521053339.1751844-1-w.egorov@phytec.de Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: rockchip: fix endpoint dtc warning for PX30 ISPQuentin Schulz3-6/+2
[ Upstream commit 5ddb2d46852997a28f8d77153e225611a8268b74 ] dtc complains with the following message for DTSes which use the ISP: arch/arm64/boot/dts/rockchip/px30.dtsi:1272.19-1276.6: Warning (graph_child_address): /isp@ff4a0000/ports/port@0: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary Typically, it is expected from the device DTS(I) to update the SoC DTSI nodes if they have more than one endpoint, so let's assume there's only one endpoint in port@0 by default, instead of forcing board DTS(I)s to /delete-property/ address-cells and size-cells to make dtc happy. Because PX30 PP1516/EVB's endpoint@0 is the only endpoint and considering its parent node now has no address-cells property, dtc complains (same messages for PX30 EVB): arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #address-cells value arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #size-cells value arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size' arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#address-cells' is -1, must be 1 arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#size-cells' is -1, must be 0 arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (graph_child_address): Failed prerequisite 'graph_endpoint' so we fix that by removing the reg property. dtc still complains (same messages for PX30 EVB): arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-450.6: Warning (unit_address_vs_reg): /isp@ff4a0000/ports/port@0/endpoint@0: node has a unit name, but no reg or ranges property so we also remove the @0 suffix off the node name. Fixes: 8df7b4537dfb ("arm64: dts: rockchip: add isp node for px30") Fixes: 474a77395be2 ("arm64: dts: rockchip: hook up camera on px30-evb") Fixes: 56198acdbf0d ("arm64: dts: rockchip: add px30-pp1516 base dtsi and board variants") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250610-ringneck-haikou-video-demo-cam-v2-1-de1bf87e0732@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15ARM: dts: vfxxx: Correctly use two tuples for timer addressKrzysztof Kozlowski1-1/+1
[ Upstream commit f3440dcf8b994197c968fbafe047ce27eed226e8 ] Address and size-cells are 1 and the ftm timer node takes two address spaces in "reg" property, so this should be in two <> tuples. Change has no functional impact, but original code is confusing/less readable. Fixes: 07513e1330a9 ("ARM: dts: vf610: Add Freescale FlexTimer Module timer node.") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: msm8976: Make blsp_dma controlled-remotelyAndré Apitzsch1-0/+2
[ Upstream commit 76270a18dbdf0bb50615f1b29d2cae8d683da01e ] The blsp_dma controller is shared between the different subsystems, which is why it is already initialized by the firmware. We should not reinitialize it from Linux to avoid potential other users of the DMA engine to misbehave. In mainline this can be described using the "qcom,controlled-remotely" property. In the downstream/vendor kernel from Qualcomm there is an opposite "qcom,managed-locally" property. This property is *not* set for the qcom,sps-dma@7884000 and qcom,sps-dma@7ac4000 [1] so adding "qcom,controlled-remotely" upstream matches the behavior of the downstream/vendor kernel. Adding this fixes booting Longcheer L9360. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.3.7.c26/arch/arm/boot/dts/qcom/msm8976.dtsi#L1149-1163 Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20250615-bqx5plus-v2-1-72b45c84237d@apitzsch.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: sa8775p: Correct the interrupt for remoteprocLijuan Gao1-5/+5
[ Upstream commit 7bd7209e9cb11c8864e601d915008da088476f0c ] Fix the incorrect IRQ numbers for ready and handover on sa8775p. The correct values are as follows: Fatal interrupt - 0 Ready interrupt - 1 Handover interrupt - 2 Stop acknowledge interrupt - 3 Fixes: df54dcb34ff2e ("arm64: dts: qcom: sa8775p: add ADSP, CDSP and GPDSP nodes") Signed-off-by: Lijuan Gao <lijuan.gao@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250612-correct_interrupt_for_remoteproc-v1-2-490ee6d92a1b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: exynos: gs101: Add 'local-timer-stop' to cpuidle nodesWill Deacon1-0/+3
[ Upstream commit b649082312dd1a4c3989bbdb7c25eb711e9b1d94 ] In preparation for switching to the architected timer as the primary clockevents device, mark the cpuidle nodes with the 'local-timer-stop' property to indicate that an alternative clockevents device must be used for waking up from the "c2" idle state. Signed-off-by: Will Deacon <willdeacon@google.com> [Original commit from https://android.googlesource.com/kernel/gs/+/a896fd98638047989513d05556faebd28a62b27c] Signed-off-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Youngmin Nam <youngmin.nam@samsung.com> Tested-by: Youngmin Nam <youngmin.nam@samsung.com> Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250611-gs101-cpuidle-v2-1-4fa811ec404d@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: qcs615: disable the CTI device of the camera blockJie Gan1-0/+3
[ Upstream commit 1b7fc8a281cae9e3176584558a4ac551ce0f777d ] Disable the CTI device of the camera block to prevent potential NoC errors during AMBA bus device matching. The clocks for the Qualcomm Debug Subsystem (QDSS) are managed by aoss_qmp through a mailbox. However, the camera block resides outside the AP domain, meaning its QDSS clock cannot be controlled via aoss_qmp. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250611030003.3801-1-jie.gan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: sc7180: Expand IMEM regionKonrad Dybcio1-5/+5
[ Upstream commit 965e28cad4739b11f1bc58c0a9935e025938bb1f ] We need more than what is currently described, expand the region to its actual boundaries. Fixes: ede638c42c82 ("arm64: dts: qcom: sc7180: Add IMEM and pil info regions") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-topic-ipa_mem_dts-v1-3-f7aa94fac1ab@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: sdm845: Expand IMEM regionKonrad Dybcio1-5/+5
[ Upstream commit 81a4a7de3d4031e77b5796479ef21aefb0862807 ] We need more than what is currently described, expand the region to its actual boundaries. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 948f6161c6ab ("arm64: dts: qcom: sdm845: Add IMEM and PIL info region") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250523-topic-ipa_mem_dts-v1-2-f7aa94fac1ab@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for ↵Jie Gan1-0/+1
Coresight [ Upstream commit bd4f35786d5f0798cc1f8c187a81a7c998e6c58f ] An infinite loop has been created by the Coresight devices. When only a source device is enabled, the coresight_find_activated_sysfs_sink function is recursively invoked in an attempt to locate an active sink device, ultimately leading to a stack overflow and system crash. Therefore, disable the replicator1 to break the infinite loop and prevent a potential stack overflow. replicator1_out -> funnel_swao_in6 -> tmc_etf_swao_in -> tmc_etf_swao_out | | replicator1_in replicator_swao_in | | replicator0_out1 replicator_swao_out0 | | replicator0_in funnel_in1_in3 | | tmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out [call trace] dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 dump_stack+0x18/0x28 panic+0x340/0x3b0 nmi_panic+0x94/0xa0 panic_bad_stack+0x114/0x138 handle_bad_stack+0x34/0xb8 __bad_stack+0x78/0x80 coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] ... coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight] coresight_enable_sysfs+0x80/0x2a0 [coresight] side effect after the change: Only trace data originating from AOSS can reach the ETF_SWAO and EUD sinks. Fixes: bf469630552a ("arm64: dts: qcom: qcs615: Add coresight nodes") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20250522005016.2148-1-jie.gan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: freescale: imx93-tqma9352: Limit BUCK2 to 600mVAlexander Stein1-3/+3
[ Upstream commit 696a4c325fad8af95da6a9d797766d1613831622 ] TQMa9352 is only using LPDDR4X, so the BUCK2 regulator should be fixed at 600MV. Fixes: d2858e6bd36c ("arm64: dts: freescale: imx93-tqma9352: Add PMIC node") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15arm64: dts: qcom: x1p42100: Fix thermal sensor configurationKonrad Dybcio2-1/+557
[ Upstream commit 63350a07966f61183462c200361a8c8cc275d560 ] The 8-core SKUs of the X1 family have a different sensor configuration. Override it to expose what the sensors really measure. Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD") Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250520-topic-x1p4_tsens-v2-1-9687b789a4fb@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>