summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-09-04vdso: Drop Kconfig GENERIC_VDSO_DATA_STOREThomas Weißschuh
All users of the generic vDSO library also use the generic vDSO datastore. Remove the now unnecessary Kconfig symbol. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-9-d9b65750e49f@linutronix.de
2025-09-04vdso: Drop kconfig GENERIC_COMPAT_VDSOThomas Weißschuh
This configuration is never used. Remove it. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-8-d9b65750e49f@linutronix.de
2025-09-04vdso: Drop kconfig GENERIC_VDSO_32Thomas Weißschuh
This configuration is never used. Remove it. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-7-d9b65750e49f@linutronix.de
2025-09-04riscv: vdso: Untangle Kconfig logicThomas Weißschuh
On riscv32 the generic vDSO infrastructure is used but without its time-related functionality. The Kconfig logic to implement this treats HAVE_GENERIC_VDSO as a synonym for GENERIC_GETTIMEOFDAY. This works today due to some underlying issues in how the generic vDSO library works. Some future cleanups will break this logic. Restructure the Kconfig logic, so HAVE_GENERIC_VDSO refers to the generic library in general and GENERIC_GETTIMEOFDAY refers to its time-related functionality. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-6-d9b65750e49f@linutronix.de
2025-09-04vdso: Move ENABLE_COMPAT_VDSO from core to arm64Thomas Weißschuh
The ENABLE_COMAPT_VDSO symbol is only used by arm64 and only for the time-related functionality. There should be no new users, so it doesn't need to be in the generic vDSO code. Move the logic into arm64 architecture-specific code and replace the explicit define by the standard '#ifdef __aarch64__'. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-3-d9b65750e49f@linutronix.de
2025-09-04ARM: VDSO: Remove cntvct_ok global variableRasmus Villemoes
The cntvct_ok variable has not had any external user since commit c7a18100bdff ("lib/vdso: Avoid highres update if clocksource is not VDSO capable"). It also only has one user in vdso.c, once during init, so rather than having the caller of patch_vdso() initialize cntvct_ok, just call cntvct_functional() directly and avoid the global variable entirely. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lore.kernel.org/all/20250826-vdso-cleanups-v1-2-d9b65750e49f@linutronix.de
2025-09-03binfmt_elf: preserve original ELF e_flags for core dumpsSvetlana Parfenova
Some architectures, such as RISC-V, use the ELF e_flags field to encode ABI-specific information (e.g., ISA extensions, fpu support). Debuggers like GDB rely on these flags in core dumps to correctly interpret optional register sets. If the flags are missing or incorrect, GDB may warn and ignore valid data, for example: warning: Unexpected size of section '.reg2/213' in core file. This can prevent access to fpu or other architecture-specific registers even when they were dumped. Save the e_flags field during ELF binary loading (in load_elf_binary()) into the mm_struct, and later retrieve it during core dump generation (in fill_note_info()). Kconfig option CONFIG_ARCH_HAS_ELF_CORE_EFLAGS is introduced for architectures that require this behaviour. Signed-off-by: Svetlana Parfenova <svetlana.parfenova@syntacore.com> Link: https://lore.kernel.org/r/20250901135350.619485-1-svetlana.parfenova@syntacore.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-09-04riscv: dts: spacemit: uart: remove sec_uart1 device nodeYixun Lan
sec_uart1 is not available from Linux, and no clock is implemented in CCF framework, thus 'make dtbs_check' will pop up this warning message: serial@f0612000: 'clock-names' is a required property Removing the node from device tree to silence the DT check warning. Link: https://lore.kernel.org/r/20250902-02-k1-uart-clock-v2-1-f146918d44f6@gentoo.org Signed-off-by: Yixun Lan <dlan@gentoo.org>
2025-09-03s390: kexec: initialize kexec_buf structBreno Leitao
The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-3-1df9882bb01a@debian.org Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao@debian.org> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Baoquan He <bhe@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Coiby Xu <coxu@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-03riscv: kexec: initialize kexec_buf structBreno Leitao
The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-2-1df9882bb01a@debian.org Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao@debian.org> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Baoquan He <bhe@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Coiby Xu <coxu@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-03arm64: kexec: initialize kexec_buf struct in load_other_segments()Breno Leitao
Patch series "kexec: Fix invalid field access". The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. An initial fix was already landed for arm64[0], and this patchset fixes the problem on the remaining arm64 code and on riscv, as raised by Mark. Discussions about this problem could be found at[1][2]. This patch (of 3): The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-0-1df9882bb01a@debian.org Link: https://lkml.kernel.org/r/20250827-kbuf_all-v1-1-1df9882bb01a@debian.org Link: https://lore.kernel.org/all/20250826180742.f2471131255ec1c43683ea07@linux-foundation.org/ [0] Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/20250826-akpm-v1-1-3c831f0e3799@debian.org/ [2] Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Baoquan He <bhe@redhat.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Coiby Xu <coxu@redhat.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-03Merge tag 'soc-fixes-6.17-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "These are mainly devicetree fixes for the rockchip and nxp platforms on arm64, addressing mistakes in the board and soc specific descriptions. In particular the newly added Rock 5T board required multiple bugfixes for PCIe and USB, while on the i.MX platform there are a number of regulator related fixes. The only other platforms with devicetree fixes are at91 with a fixup for SD/MMC and a change to enable all the available UARTS on the Axiado reference board. Also on the at91 platform, a Kconfig change addresses a regression that stopped the DMA engine from working in 6.17-rc. Three drivers each have a simple bugfix, stopping incorrect behavior in op-tee firmware, the tee subsystem and the qualcomm mdt_loader. Two trivial MAINTAINERS file changes are needed to make sure that patches reach the correct maintainer, but don't change the actual responsibilities" * tag 'soc-fixes-6.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (27 commits) ARM: dts: microchip: sama7d65: Force SDMMC Legacy mode ARM: at91: select ARCH_MICROCHIP arm64: dts: rockchip: fix second M.2 slot on ROCK 5T arm64: dts: rockchip: fix USB on RADXA ROCK 5T MAINTAINERS: exclude defconfig from ARM64 PORT arm64: dts: axiado: Add missing UART aliases MAINTAINERS: Update Nobuhiro Iwamatsu's email address arm64: dts: rockchip: Add vcc-supply to SPI flash on Pinephone Pro arm64: dts: rockchip: fix es8388 address on rk3588s-roc-pc arm64: dts: rockchip: Fix Bluetooth interrupts flag on Neardi LBA3368 arm64: dts: rockchip: correct network description on Sige5 arm64: dts: rockchip: Minor whitespace cleanup ARM: dts: rockchip: Minor whitespace cleanup arm64: dts: rockchip: Add supplies for eMMC on rk3588-orangepi-5 arm64: dts: rockchip: Fix the headphone detection on the orangepi 5 plus arm64: dts: imx95: Fix JPEG encoder node assigned clock arm64: dts: imx95-19x19-evk: correct the phy setting for flexcan1/2 arm64: dts: imx8mp: Fix missing microSD slot vqmmc on Data Modul i.MX8M Plus eDM SBC arm64: dts: imx8mp: Fix missing microSD slot vqmmc on DH electronics i.MX8M Plus DHCOM arm64: dts: imx8mp-tqma8mpql: remove virtual 3.3V regulator ...
2025-09-03Merge tag 'pull-getgeo' of ↵Jens Axboe
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into for-6.18/block Pull struct block_device getgeo changes from Al. "switching ->getgeo() from struct block_device to struct gendisk Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>" * tag 'pull-getgeo' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: block: switch ->getgeo() to struct gendisk scsi: switch ->bios_param() to passing gendisk scsi: switch scsi_bios_ptable() and scsi_partsize() to gendisk
2025-09-03Merge tag 'at91-fixes-6.17' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes Microchip AT91 fixes for v6.17 This update includes: - adaptation to the SDHCI capabilities on sama7d65 curiosity board DT as SDHCI quirks are not in place yet. SD/MMC don't work without these - addition of one Kconfig symbol that is already used in DMA tree for 6.17. XDMA cannot be selected if not present. * tag 'at91-fixes-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: microchip: sama7d65: Force SDMMC Legacy mode ARM: at91: select ARCH_MICROCHIP Link: https://lore.kernel.org/r/20250903173403.113604-1-nicolas.ferre@microchip.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-09-03ARM: dts: BCM5301X: Add support for Buffalo WXR-1750DHPTaishi Shimizu
Add initial device tree support for the Buffalo WXR-1750DHP, a consumer Wi-Fi router based on the Broadcom BCM4708A0 SoC. Hardware specifications: * Processor: Broadcom BCM4708A0 dual-core @ 800 MHz * RAM: DDR3 256 MB * Ethernet Switch: Broadcom BCM53011 integrated via SRAB * NAND Flash: 128 MB (8-bit ECC) * SPI Flash: None * Ports: 4 LAN Ports, 1 WAN Port * USB: 1x USB 3.0 Type-A port Signed-off-by: Taishi Shimizu <s.taishi14142@gmail.com> Link: https://lore.kernel.org/r/20250713071826.726682-3-s.taishi14142@gmail.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-09-03arm64: dts: broadcom: bcm2712: Add default GIC address cellsKrzysztof Kozlowski
Add missing address-cells 0 to GIC interrupt node to silence W=1 warning: bcm2712.dtsi:494.4-497.31: Warning (interrupt_map): /axi/pcie@1000110000:interrupt-map: Missing property '#address-cells' in node /soc@107c000000/interrupt-controller@7fff9000, using 0 as fallback Value '0' is correct because: 1. GIC interrupt controller does not have children, 2. interrupt-map property (in PCI node) consists of five components and the fourth component "parent unit address", which size is defined by '#address-cells' of the node pointed to by the interrupt-parent component, is not used (=0) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250822133407.312505-2-krzysztof.kozlowski@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-09-03ARM: dts: microchip: sama7d65: Force SDMMC Legacy modeRyan Wanner
The SDMMC in this IP currently only supports legacy mode due to a hardware quirk, setting the flags to reflect the limitation. Fixes: deaa14ab6b06 ("ARM: dts: microchip: add support for sama7d65_curiosity board") Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20250819170528.126010-1-Ryan.Wanner@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2025-09-03ARM: at91: select ARCH_MICROCHIPRobert Marko
Like with the ARM64 Microchip platforms, lets add a generic ARCH_MICROCHIP symbol and select it so that drivers that are reused for multiple product generation or lines, can just depend on it instead of adding each SoC symbol as their dependencies. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by: Daniel Machon <daniel.machon@microchip.com> Link: https://lore.kernel.org/r/20250813174720.540015-3-robert.marko@sartura.hr Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2025-09-03ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15Clément Le Goffic
Add the hdp devicetree node for stm32mp15 SoC family Keep the node disabled as HDP needs the pinctrl SoC configuration to be able to output its mux output signal outside of the SoC, on the SoC pad. This configuration is provided in the board dtsi file through 'pinctrl-*' properties as well as HDP mux configuration. Thus, if needed, HDP should be enabled in board dtsi file. Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> Link: https://lore.kernel.org/r/20250711-hdp-upstream-v7-5-faeecf7aaee1@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13Clément Le Goffic
Add the hdp devicetree node for stm32mp13 SoC family. Keep the node disabled as HDP needs the pinctrl SoC configuration to be able to output its mux output signal outside of the SoC, on the SoC pad. This configuration is provided in the board dtsi file through 'pinctrl-*' properties as well as HDP mux configuration. Thus, if needed, HDP should be enabled in board dtsi file. Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> Link: https://lore.kernel.org/r/20250711-hdp-upstream-v7-4-faeecf7aaee1@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03ARM: dts: stm32: Add leds for CM4 on stm32mp15xx-ed1 and stm32mp15xx-dkxAntonio Borneo
Add to the node m4_rproc the pinctrl property corresponding to the orange LED. The GPIO is reserved for the coprocessor Cortex-M4 and will be ignored by Linux. Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Link: https://lore.kernel.org/r/20250610152309.299438-5-antonio.borneo@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03ARM: dts: stm32: Add pinmux for CM4 leds pinsAntonio Borneo
The GPIO H7 on boards stm32mp15xx-dkx and the GPIO D8 on boards stm32mp15xx-ed1 are used by the coprocessor Cortex-M4. Linux running on Cortex-A should not use the GPIO and should left it available for the coprocessor. Add two pinmux groups, one for each families of boards, setting the GPIO function as Reserved (RSVD). Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Link: https://lore.kernel.org/r/20250610152309.299438-4-antonio.borneo@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03x86/boot: Get rid of the .head.text sectionArd Biesheuvel
The .head.text section is now empty, so it can be dropped from the linker script. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-46-ardb+git@google.com
2025-09-03x86/boot: Move startup code out of __head sectionArd Biesheuvel
Move startup code out of the __head section, now that this no longer has a special significance. Move everything into .text or .init.text as appropriate, so that startup code is not kept around unnecessarily. [ bp: Fold in hunk to fix 32-bit CPU hotplug: Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202509022207.56fd97f4-lkp@intel.com ] Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-45-ardb+git@google.com
2025-09-03efistub/x86: Remap inittext read-execute when neededArd Biesheuvel
Recent EFI x86 systems are more strict when it comes to mapping boot images, and require that mappings are either read-write or read-execute. Now that the boot code is being cleaned up and refactored, most of it is being moved into .init.text [where it arguably belongs] but that implies that when booting on such strict EFI firmware, we need to take care to map .init.text (and the .altinstr_aux section that follows it) read-execute as well. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-44-ardb+git@google.com
2025-09-03x86/boot: Create a confined code area for startup codeArd Biesheuvel
In order to be able to have tight control over which code may execute from the early 1:1 mapping of memory, but still link vmlinux as a single executable, prefix all symbol references in startup code with __pi_, and invoke it from outside using the __pi_ prefix. Use objtool to check that no absolute symbol references are present in the startup code, as these cannot be used from code running from the 1:1 mapping. Note that this also requires disabling the latent-entropy GCC plugin, as the global symbol references that it injects would require explicit exports, and given that the startup code rarely executes more than once, it is not a useful source of entropy anyway. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-43-ardb+git@google.com
2025-09-03x86/kbuild: Incorporate boot/startup/ via Kbuild makefileArd Biesheuvel
Using core-y is not the correct way to get kbuild to descend into arch/x86/boot/startup. For instance, building an individual object does not work as expected when the pattern rule is local to the Makefile $ make arch/x86/boot/startup/map_kernel.pi.o GEN Makefile CALL /home/ardb/linux/scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers make[3]: *** No rule to make target 'arch/x86/boot/startup/map_kernel.pi.o'. Stop. make[2]: *** [/home/ardb/linux/scripts/Makefile.build:461: arch/x86] Error 2 make[1]: *** [/home/ardb/linux/Makefile:2011: .] Error 2 make: *** [/home/ardb/linux/Makefile:248: __sub-make] Error 2 So use obj-y from arch.x86/Kbuild instead, which makes things work as expected. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-42-ardb+git@google.com
2025-09-03x86/boot: Revert "Reject absolute references in .head.text"Ard Biesheuvel
This reverts commit faf0ed487415 ("x86/boot: Reject absolute references in .head.text") The startup code is checked directly for the absence of absolute symbol references, so checking the .head.text section in the relocs tool is no longer needed. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-41-ardb+git@google.com
2025-09-03x86/boot: Check startup code for absence of absolute relocationsArd Biesheuvel
Invoke objtool on each startup code object individually to check for the absence of absolute relocations. This is needed because this code will be invoked from the 1:1 mapping of memory before those absolute virtual addresses (which are derived from the kernel virtual base address provided to the linker and possibly shifted at boot) are mapped. Only objects built under arch/x86/boot/startup/ have this restriction, and once they have been incorporated into vmlinux.o, this distinction is difficult to make. So force the invocation of objtool for each object file individually, even if objtool is deferred to vmlinux.o for the rest of the build. In the latter case, only pass --noabs and nothing else; otherwise, append it to the existing objtool command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-40-ardb+git@google.com
2025-09-03x86/sev: Export startup routines for later useArd Biesheuvel
Create aliases that expose routines that are part of the startup code to other code in the core kernel, so that they can be called later as well. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-38-ardb+git@google.com
2025-09-03x86/sev: Move __sev_[get|put]_ghcb() into separate noinstr objectArd Biesheuvel
Rename sev-nmi.c to noinstr.c, and move the get/put GHCB routines into it too, which are also annotated as 'noinstr' and suffer from the same problem as the NMI code, i.e., that GCC may ignore the __no_sanitize_address__ function attribute implied by 'noinstr' and insert KASAN instrumentation anyway. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-37-ardb+git@google.com
2025-09-03x86/sev: Provide PIC aliases for SEV related data objectsArd Biesheuvel
Provide PIC aliases for data objects that are shared between the SEV startup code and the SEV code that executes later. This is needed so that the confined startup code is permitted to access them. This requires some of these variables to be moved into a source file that is not part of the startup code, as the PIC alias is already implied, and exporting variables in the opposite direction is not supported. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-36-ardb+git@google.com
2025-09-03x86/boot: Provide PIC aliases for 5-level paging related constantsArd Biesheuvel
Provide PIC aliases for the global variables related to 5-level paging, so that the startup code can access them in order to populate the kernel page tables. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-35-ardb+git@google.com
2025-09-03x86/boot: Drop redundant RMPADJUST in SEV SVSM presence checkArd Biesheuvel
snp_vmpl will be assigned a non-zero value when executing at a VMPL other than 0, and this is inferred from a call to RMPADJUST, which only works when running at VMPL0. This means that testing snp_vmpl is sufficient, and there is no need to perform the same check again. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-34-ardb+git@google.com
2025-09-03x86/sev: Use boot SVSM CA for all startup and init codeArd Biesheuvel
To avoid having to reason about whether or not to use the per-CPU SVSM calling area when running startup and init code on the boot CPU, reuse the boot SVSM calling area as the per-CPU area for the BSP. Thus, remove the need to make the per-CPU variables and associated state in sev_cfg accessible to the startup code once confined. [ bp: Massage commit message. ] Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-33-ardb+git@google.com
2025-09-03x86/sev: Pass SVSM calling area down to early page state change APIArd Biesheuvel
The early page state change API is mostly only used very early, when only the boot time SVSM calling area is in use. However, this API is also called by the kexec finishing code, which runs very late, and potentially from a different CPU (which uses a different calling area). To avoid pulling the per-CPU SVSM calling area pointers and related SEV state into the startup code, refactor the page state change API so the SVSM calling area virtual and physical addresses can be provided by the caller. No functional change intended. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-32-ardb+git@google.com
2025-09-03x86/sev: Share implementation of MSR-based page state changeArd Biesheuvel
Both the decompressor and the SEV startup code implement the exact same sequence for invoking the MSR based communication protocol to effectuate a page state change. Before tweaking the internal APIs used in both versions, merge them and share them so those tweaks are only needed in a single place. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-31-ardb+git@google.com
2025-09-03x86/sev: Avoid global variable to store virtual address of SVSM areaArd Biesheuvel
The boottime SVSM calling area is used both by the startup code running from a 1:1 mapping, and potentially later on running from the ordinary kernel mapping. This SVSM calling area is statically allocated, and so its physical address doesn't change. However, its virtual address depends on the calling context (1:1 mapping or kernel virtual mapping), and even though the variable that holds the virtual address of this calling area gets updated from 1:1 address to kernel address during the boot, it is hard to reason about why this is guaranteed to be safe. So instead, take the RIP-relative address of the boottime SVSM calling area whenever its virtual address is required, and only use a global variable for the physical address. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/20250828102202.1849035-30-ardb+git@google.com
2025-09-03x86/sev: Move GHCB page based HV communication out of startup codeArd Biesheuvel
Both the decompressor and the core kernel implement an early #VC handler, which only deals with CPUID instructions, and full featured one, which can handle any #VC exception. The former communicates with the hypervisor using the MSR based protocol, whereas the latter uses a shared GHCB page, which is configured a bit later during the boot, when the kernel runs from its ordinary virtual mapping, rather than the 1:1 mapping that the startup code uses. Accessing this shared GHCB page from the core kernel's startup code is problematic, because it involves converting the GHCB address provided by the caller to a physical address. In the startup code, virtual to physical address translations are problematic, given that the virtual address might be a 1:1 mapped address, and such translations should therefore be avoided. This means that exposing startup code dealing with the GHCB to callers that execute from the ordinary kernel virtual mapping should be avoided too. So move all GHCB page based communication out of the startup code, now that all communication occurring before the kernel virtual mapping is up relies on the MSR protocol only. As an exception, add a flag representing the need to apply the coherency fix in order to avoid exporting CPUID* helpers because of the code running too early for the *cpu_has* infrastructure. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250828102202.1849035-29-ardb+git@google.com
2025-09-03Merge tag 'v6.17-rockchip-dtsfixes1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes The newly added Rock 5T board needed slightly bigger fixes to make the PCIe and USB actually work, because the PCIe does share its lanes between two ports and the usb needs to toggle a gpio to supply power. The other interesting fix is the headphone detection on the Orange Pi 5+. The rest are some added supplies to make the boot log less scary and a number of styling fixes. * tag 'v6.17-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: fix second M.2 slot on ROCK 5T arm64: dts: rockchip: fix USB on RADXA ROCK 5T arm64: dts: rockchip: Add vcc-supply to SPI flash on Pinephone Pro arm64: dts: rockchip: fix es8388 address on rk3588s-roc-pc arm64: dts: rockchip: Fix Bluetooth interrupts flag on Neardi LBA3368 arm64: dts: rockchip: correct network description on Sige5 arm64: dts: rockchip: Minor whitespace cleanup ARM: dts: rockchip: Minor whitespace cleanup arm64: dts: rockchip: Add supplies for eMMC on rk3588-orangepi-5 arm64: dts: rockchip: Fix the headphone detection on the orangepi 5 plus arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3399-pinebook-pro arm64: dts: rockchip: mark eeprom as read-only for Radxa E52C Link: https://lore.kernel.org/r/5909239.Y6S9NjorxK@phil Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-09-03arm64: uapi: Provide correct __BITS_PER_LONG for the compat vDSOThomas Weißschuh
The generic vDSO library uses the UAPI headers. On arm64 __BITS_PER_LONG is always '64' even when used from the compat vDSO. In that case __GENMASK() does an illegal bitshift, invoking undefined behaviour. Change __BITS_PER_LONG to also work when used from the comapt vDSO. To not confuse real userspace, only do this when building the kernel. Reported-by: John Stultz <jstultz@google.com> Closes: https://lore.kernel.org/lkml/CANDhNCqvKOc9JgphQwr0eDyJiyG4oLFS9R8rSFvU0fpurrJFDg@mail.gmail.com/ Fixes: cd3557a7618b ("vdso/gettimeofday: Add support for auxiliary clocks") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: John Stultz <jstultz@google.com> Link: https://lore.kernel.org/r/20250821-vdso-arm64-compat-bitsperlong-v1-1-700bcabe7732@linutronix.de Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-09-03arm64: dts: exynos8895: Minor whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space around '=' character. Link: https://lore.kernel.org/r/20250819131641.86520-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-09-03sched: Unify the SCHED_{SMT,CLUSTER,MC} KconfigPeter Zijlstra
Like many Kconfig symbols, SCHED_{SMT,CLUSTER,MC} are duplicated across arch/*/Kconfig. Try and clean up a little. Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> # powerpc Link: https://lkml.kernel.org/r/20250826094358.GG3245006@noisy.programming.kicks-ass.net
2025-09-03sched/fair: Get rid of sched_domains_curr_level hack for tl->cpumask()Peter Zijlstra
Leon [1] and Vinicius [2] noted a topology_span_sane() warning during their testing starting from v6.16-rc1. Debug that followed pointed to the tl->mask() for the NODE domain being incorrectly resolved to that of the highest NUMA domain. tl->mask() for NODE is set to the sd_numa_mask() which depends on the global "sched_domains_curr_level" hack. "sched_domains_curr_level" is set to the "tl->numa_level" during tl traversal in build_sched_domains() calling sd_init() but was not reset before topology_span_sane(). Since "tl->numa_level" still reflected the old value from build_sched_domains(), topology_span_sane() for the NODE domain trips when the span of the last NUMA domain overlaps. Instead of replicating the "sched_domains_curr_level" hack, get rid of it entirely and instead, pass the entire "sched_domain_topology_level" object to tl->cpumask() function to prevent such mishap in the future. sd_numa_mask() now directly references "tl->numa_level" instead of relying on the global "sched_domains_curr_level" hack to index into sched_domains_numa_masks[]. The original warning was reproducible on the following NUMA topology reported by Leon: $ sudo numactl -H available: 5 nodes (0-4) node 0 cpus: 0 1 node 0 size: 2927 MB node 0 free: 1603 MB node 1 cpus: 2 3 node 1 size: 3023 MB node 1 free: 3008 MB node 2 cpus: 4 5 node 2 size: 3023 MB node 2 free: 3007 MB node 3 cpus: 6 7 node 3 size: 3023 MB node 3 free: 3002 MB node 4 cpus: 8 9 node 4 size: 3022 MB node 4 free: 2718 MB node distances: node 0 1 2 3 4 0: 10 39 38 37 36 1: 39 10 38 37 36 2: 38 38 10 37 36 3: 37 37 37 10 36 4: 36 36 36 36 10 The above topology can be mimicked using the following QEMU cmd that was used to reproduce the warning and test the fix: sudo qemu-system-x86_64 -enable-kvm -cpu host \ -m 20G -smp cpus=10,sockets=10 -machine q35 \ -object memory-backend-ram,size=4G,id=m0 \ -object memory-backend-ram,size=4G,id=m1 \ -object memory-backend-ram,size=4G,id=m2 \ -object memory-backend-ram,size=4G,id=m3 \ -object memory-backend-ram,size=4G,id=m4 \ -numa node,cpus=0-1,memdev=m0,nodeid=0 \ -numa node,cpus=2-3,memdev=m1,nodeid=1 \ -numa node,cpus=4-5,memdev=m2,nodeid=2 \ -numa node,cpus=6-7,memdev=m3,nodeid=3 \ -numa node,cpus=8-9,memdev=m4,nodeid=4 \ -numa dist,src=0,dst=1,val=39 \ -numa dist,src=0,dst=2,val=38 \ -numa dist,src=0,dst=3,val=37 \ -numa dist,src=0,dst=4,val=36 \ -numa dist,src=1,dst=0,val=39 \ -numa dist,src=1,dst=2,val=38 \ -numa dist,src=1,dst=3,val=37 \ -numa dist,src=1,dst=4,val=36 \ -numa dist,src=2,dst=0,val=38 \ -numa dist,src=2,dst=1,val=38 \ -numa dist,src=2,dst=3,val=37 \ -numa dist,src=2,dst=4,val=36 \ -numa dist,src=3,dst=0,val=37 \ -numa dist,src=3,dst=1,val=37 \ -numa dist,src=3,dst=2,val=37 \ -numa dist,src=3,dst=4,val=36 \ -numa dist,src=4,dst=0,val=36 \ -numa dist,src=4,dst=1,val=36 \ -numa dist,src=4,dst=2,val=36 \ -numa dist,src=4,dst=3,val=36 \ ... [ prateek: Moved common functions to include/linux/sched/topology.h, reuse the common bits for s390 and ppc, commit message ] Closes: https://lore.kernel.org/lkml/20250610110701.GA256154@unreal/ [1] Fixes: ccf74128d66c ("sched/topology: Assert non-NUMA topology masks don't (partially) overlap") # ce29a7da84cd, f55dac1dafb3 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reported-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Valentin Schneider <vschneid@redhat.com> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Valentin Schneider <vschneid@redhat.com> # x86 Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> # powerpc Link: https://lore.kernel.org/lkml/a3de98387abad28592e6ab591f3ff6107fe01dc1.1755893468.git.tim.c.chen@linux.intel.com/ [2]
2025-09-03ARM: dts: stm32: Drop redundant status=okayKrzysztof Kozlowski
Device nodes are enabled by default, so remove confusing or duplicated enabling of few nodes. No practical impact, verified with dtx_diff. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Marek Vasut <marek.vasut@mailbox.org> Link: https://lore.kernel.org/r/20250818143730.244379-2-krzysztof.kozlowski@linaro.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03arm64: dts: stm32: Minor whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space around '=' character. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250819131707.86657-4-krzysztof.kozlowski@linaro.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03ARM: dts: stm32: Minor whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space around '=' or '{' characters. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250819131707.86657-3-krzysztof.kozlowski@linaro.org Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03ARM: dts: stm32: stm32mp151c-plyaqm: Use correct dai-format propertyJihed Chaibi
The stm32-i2s binding inherits from the standard audio-graph-port schema for its 'port' subnode, audio-graph-port requires the use of the 'dai-format' property. The stm32mp151c-plyaqm dts file was using the non-standard name 'format'. Correct the property name to 'dai-format' to fix the dtbs_check validation error. Fixes: 9365fa46be358 ("ARM: dts: stm32: Add Plymovent AQM devicetree") Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com> Link: https://lore.kernel.org/r/20250830225115.303663-1-jihed.chaibi.dev@gmail.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2025-09-03ARM: dts: aspeed: Drop "sdhci" compatiblesRob Herring (Arm)
The "sdhci" compatible is not documented nor very useful on its own given the various features and quirks of SDHCI implementations. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250829211318.1335862-1-robh@kernel.org Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-09-03ARM: dts: aspeed: Fix/add I2C device vendor prefixesRob Herring (Arm)
The ASpeed DTS files have various I2C devices with missing or incorrect vendor prefixes in their compatible strings. This hasn't really mattered and doesn't impact ABI compatibility as I2C devices get matched with their vendor prefix stripped. With this, the "maxim,max31790" nodes now validate and have some warnings. Remove the spurious "#address-cells" and "#size-cells" properties to fix the warnings. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> [arj: Fix conflicts with fe42f567c387 ("ARM: dts: aspeed: Minor whitespace cleanup")] Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-05 19:37:19 +0000