summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-06-27arm64: dts: exynos: gs101-pixel-common: add nvmem-reboot-modeAndré Draszik1-1/+16
Add the 'nvmem-reboot-mode' which is used to communicate a requested boot mode to the boot loader. Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250524-b4-max77759-mfd-dts-v2-3-b479542eb97d@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-27arm64: dts: exynos: gs101-pixel-common: add Maxim MAX77759 PMICAndré Draszik1-0/+61
On Pixel 6 (and Pro), a MAX77759 companion PMIC for USB Type-C applications is used, which contains four functional blocks (at distinct I2C addresses): * top (including GPIO & NVMEM) * charger * fuel gauge * TCPCi This change adds the PMIC and the subnodes for the GPIO expander and NVMEM, and defines the NVMEM layout. The NVMEM layout is declared such that it matches downstream's open-coded configuration [1]. Note: The pinctrl nodes are kept sorted by the 'samsung,pins' property rather than node name, as I think that makes it easier to look at and to add new nodes unambiguously in the future. Its label is prefixed with 'if' (for interface), because there are three PMICs in total in use on Pixel 6 (Pro). Link: https://android.googlesource.com/kernel/google-modules/bms/+/96e729a83817/max77759_maxq.c#67 [1] Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250524-b4-max77759-mfd-dts-v2-2-b479542eb97d@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-27arm64: defconfig: enable Maxim max77759 driverAndré Draszik1-0/+1
Enable the Maxim max77759 as this is used by the gs101-oriole and gs101-raven (Google Pixel 6 and Pixel 6 Pro) boards, The child devices' defaults are based on this MFD driver's state, so this commit enables those implicitly as well. Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250524-b4-max77759-mfd-dts-v2-1-b479542eb97d@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-27Merge tag 'drm-misc-next-2025-06-26' of ↵Dave Airlie1-0/+16
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.17: UAPI Changes: Cross-subsystem Changes: Core Changes: - ci: Add Device tree validation and kunit - connector: Move HDR sink metadat to drm_display_info Driver Changes: - bochs: drm_panic Support - panfrost: MT8370 Support - bridge: - tc358767: Convert to devm_drm_bridge_alloc() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250626-sincere-loon-of-effort-6dbdf9@houat
2025-06-26arm64: dts: qcom: x1-asus-zenbook: support soundAleksandrs Vinarskis1-0/+194
Works: * Both speakers * Both MICs * Headphones jack, L/R channels * Headphones jack, MIC Now working/untested: * Sound over DisplayPort * Sound over HDMI Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250623113709.21184-3-alex.vinarskis@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-26arm64: dts: qcom: x1-asus-zenbook: fixup GPU nodesAleksandrs Vinarskis3-5/+9
It appears not the latest version of the patch was merged. Align with latest upstreamed version by correcting GPU enable location and typo in GPU firmware path for x1p42100 variant. Fixes: 6516961352a1 ("arm64: dts: qcom: Add support for X1-based Asus Zenbook A14") Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250623113709.21184-2-alex.vinarskis@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc3Alexei Starovoitov358-6130/+6666
Cross-merge BPF, perf and other fixes after downstream PRs. It restores BPF CI to green after critical fix commit bc4394e5e79c ("perf: Fix the throttle error of some clock events") No conflicts. Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26x86/mce: Don't remove sysfs if thresholding sysfs init failsYazen Ghannam1-7/+1
Currently, the MCE subsystem sysfs interface will be removed if the thresholding sysfs interface fails to be created. A common failure is due to new MCA bank types that are not recognized and don't have a short name set. The MCA thresholding feature is optional and should not break the common MCE sysfs interface. Also, new MCA bank types are occasionally introduced, and updates will be needed to recognize them. But likewise, this should not break the common sysfs interface. Keep the MCE sysfs interface regardless of the status of the thresholding sysfs interface. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Tested-by: Tony Luck <tony.luck@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-1-236dd74f645f@amd.com
2025-06-26arm64: dts: renesas: r9a09g047: Add GBETH nodesJohn Madieu1-0/+209
Add GBETH nodes to RZ/G3E (R9A09G047) SoC DTSI. Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Link: https://lore.kernel.org/20250623080405.355083-3-john.madieu.xa@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-26arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Rename fixed regulator node namesLad Prabhakar1-2/+2
Rename "regulator0" to "regulator-0p8v" and "regulator1" to "regulator-3p3v" for consistency as done in the RZ/V2N EVK. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250620121045.56114-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-26arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Add RAA215300 PMICLad Prabhakar1-0/+15
Add support for the Renesas RAA215300 PMIC to the RZ/V2N EVK. The PMIC is connected to I2C8 and uses a 32.768kHz fixed clock source (x6). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250619135539.207828-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-26arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add RAA215300 PMICLad Prabhakar1-0/+15
Add support for the Renesas RAA215300 PMIC to the RZ/V2H EVK. The PMIC is connected to I2C8 and uses a 32.768kHz fixed clock source (x6). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250619135539.207828-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-26riscv: Helper to parse hart indexVladimir Kondratiev2-0/+36
RISC-V APLIC specification defines "hart index" in [1]. Similar definitions can be found for ACLINT in [2] Quote from the APLIC specification: Within a given interrupt domain, each of the domain’s harts has a unique index number in the range 0 to 2^14 − 1 (= 16,383). The index number a domain associates with a hart may or may not have any relationship to the unique hart identifier (“hart ID”) that the RISC-V Privileged Architecture assigns to the hart. Two different interrupt domains may employ entirely different index numbers for the same set of harts. Further, it says in "4.5 Memory-mapped control region for an interrupt domain": The array of IDC structures may include some for potential hart index numbers that are not actual hart index numbers in the domain. For example, the first IDC structure is always for hart index 0, but 0 is not necessarily a valid index number for any hart in the domain. Support arbitrary hart indices specified in an optional property "riscv,hart-indexes" which is specified as an array of u32 elements, one per interrupt target, listing hart indexes in the same order as in "interrupts-extended". If this property is not specified, fall back to use logical hart indices within the domain. Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250612143911.3224046-2-vladimir.kondratiev@mobileye.com Link: https://github.com/riscv/riscv-aia [1] Link: https://github.com/riscvarchive/riscv-aclint [2]
2025-06-26s390/nmi: Print additional informationHeiko Carstens3-5/+75
In case of an unrecoverable machine check only the machine check interrupt code is printed to the console before the machine is stopped. This makes root cause analysis sometimes hard. Print additional machine check information to make analysis easier. The output now looks like this: Unrecoverable machine check, code: 00400F5F4C3B0000 6.16.0-rc2-11605-g987a9431e53a-dirty HW: IBM 3931 A01 704 (z/VM 7.4.0) PSW: 0706C00180000000 000003FFE0F0462E PFX: 0000000000070000 LBA: 000003FFE0F0462A EDC: 0000000000000000 FSA: 0000000000000000 CRS: 0080000014966A12 0000000087CB41C7 0000000000BFF140 0000000000000000 000000000000FFFF 0000000000BFF140 0000000071000000 0000000087CB41C7 0000000000008000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00000000024C0007 00000000DB000000 0000000000BFF000 GPRS: FFFFFFFF00000000 000003FFE0F0462E E10EA4F489F897A6 0000000000000000 7FFFFFF2C0413C4C 000003FFE19B7010 0000000000000000 0000000000000000 0000000000000000 00000001F76B3380 000003FFE15D4050 0000000000000005 0000000000000000 0000000000070000 000003FFE0F0586C 0000037FE00B7DA0 System stopped Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-06-26LoongArch: KVM: Avoid overflow with array indexBibo Mao1-10/+7
The variable index is modified and reused as array index when modify register EIOINTC_ENABLE. There will be array index overflow problem. Cc: stable@vger.kernel.org Fixes: 3956a52bc05b ("LoongArch: KVM: Add EIOINTC read and write functions") Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-26LoongArch: Handle KCOV __init vs inline mismatchesKees Cook3-4/+4
When the KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For LoongArch this exposed several places where __init annotations were missing but ended up being "accidentally correct". So fix these cases. Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-26LoongArch: Reserve the EFI memory map regionMing Wang1-0/+12
The EFI memory map at 'boot_memmap' is crucial for kdump to understand the primary kernel's memory layout. This memory region, typically part of EFI Boot Services (BS) data, can be overwritten after ExitBootServices if not explicitly preserved by the kernel. This commit addresses this by: 1. Calling memblock_reserve() to reserve the entire physical region occupied by the EFI memory map (header + descriptors). This prevents the primary kernel from reallocating and corrupting this area. 2. Setting the EFI_PRESERVE_BS_REGIONS flag in efi.flags. This indicates that efforts have been made to preserve critical BS code/data regions which can be useful for other kernel subsystems or debugging. These changes ensure the original EFI memory map data remains intact, improving kdump reliability and potentially aiding other EFI-related functionalities that might rely on preserved BS code/data. Signed-off-by: Ming Wang <wangming01@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-26LoongArch: Fix build warnings about export.hHuacai Chen12-4/+10
After commit a934a57a42f64a4 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") and 7d95680d64ac8e836c ("scripts/misc-check: check unnecessary #include <linux/export.h> when W=1"), we get some build warnings with W=1: arch/loongarch/kernel/acpi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/alternative.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/kfpu.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/traps.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/unwind_guess.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/unwind_orc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/unwind_prologue.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/lib/crc32-loongarch.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/lib/csum.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing arch/loongarch/kernel/elf.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present arch/loongarch/kernel/paravirt.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present arch/loongarch/pci/pci.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present So fix these build warnings for LoongArch. Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-26LoongArch: Replace __ASSEMBLY__ with __ASSEMBLER__ in headersThomas Huth26-62/+62
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembler code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This is bad since macros starting with two underscores are names that are reserved by the C language. It can also be very confusing for the developers when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's now standardize on the __ASSEMBLER__ macro that is provided by the compilers. This is almost a completely mechanical patch (done with a simple "sed -i" statement), with one comment tweaked manually in the arch/loongarch/include/asm/cpu.h file (it was missing the trailing underscores). Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-26x86/bugs: Clean up SRSO microcode handlingDavid Kaplan1-19/+18
SRSO microcode only exists for Zen3/Zen4 CPUs. For those CPUs, the microcode is required for any mitigation other than Safe-RET to be effective. Safe-RET can still protect user->kernel and guest->host attacks without microcode. Clarify this in the code and ensure that SRSO_MITIGATION_UCODE_NEEDED is selected for any mitigation besides Safe-RET if the required microcode isn't present. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250625155805.600376-4-david.kaplan@amd.com
2025-06-26crypto: s390 - Add selftest support for phmacHarald Freudenberger1-0/+137
Add key preparation code in case of selftest running to the phmac setkey function: As long as crypto_ahash_tested() returns with false, all setkey() invocations are assumed to carry sheer hmac clear key values and thus need some preparation to work with the phmac implementation. Thus it is possible to use the already available hmac test vectors implemented in the testmanager to test the phmac code. When crypto_ahash_tested() returns true (that is after larval state) the phmac code assumes the key material is a blob digestible by the pkey kernel module which converts the blob into a working key for the phmac code. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: s390 - New s390 specific protected key hash phmacHarald Freudenberger4-0/+914
Add support for protected key hmac ("phmac") for s390 arch. With the latest machine generation there is now support for protected key (that is a key wrapped by a master key stored in firmware) hmac for sha2 (sha224, sha256, sha384 and sha512) for the s390 specific CPACF instruction kmac. This patch adds support via 4 new ahashes registered as phmac(sha224), phmac(sha256), phmac(sha384) and phmac(sha512). Co-developed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26s390/crypto: Add protected key hmac subfunctions for KMACHolger Dengler1-0/+4
The CPACF KMAC instruction supports new subfunctions for protected key hmac. Add defines for these 4 new subfuctions. Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26KVM: arm64: Don't free hyp pages with pKVM on GICv2Quentin Perret1-1/+4
Marc reported that enabling protected mode on a device with GICv2 doesn't fail gracefully as one would expect, and leads to a host kernel crash. As it turns out, the first half of pKVM init happens before the vgic probe, and so by the time we find out we have a GICv2 we're already committed to keeping the pKVM vectors installed at EL2 -- pKVM rejects stub HVCs for obvious security reasons. However, the error path on KVM init leads to teardown_hyp_mode() which unconditionally frees hypervisor allocations (including the EL2 stacks and per-cpu pages) under the assumption that a previous cpu_hyp_uninit() execution has reset the vectors back to the stubs, which is false with pKVM. Interestingly, host stage-2 protection is not enabled yet at this point, so this use-after-free may go unnoticed for a while. The issue becomes more obvious after the finalize_pkvm() call. Fix this by keeping track of the CPUs on which pKVM is initialized in the kvm_hyp_initialized per-cpu variable, and use it from teardown_hyp_mode() to skip freeing pages that are in fact used. Fixes: a770ee80e662 ("KVM: arm64: pkvm: Disable GICv2 support") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Quentin Perret <qperret@google.com> Link: https://lore.kernel.org/r/20250626101014.1519345-1-qperret@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-26x86/bugs: Use IBPB for retbleed if used by SRSODavid Kaplan1-15/+19
If spec_rstack_overflow=ibpb then this mitigates retbleed as well. This is relevant for AMD Zen1 and Zen2 CPUs which are vulnerable to both bugs. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: H . Peter Anvin <hpa@zytor.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250625155805.600376-3-david.kaplan@amd.com
2025-06-26x86/bugs: Add SRSO_MITIGATION_NOSMTDavid Kaplan1-7/+4
AMD Zen1 and Zen2 CPUs with SMT disabled are not vulnerable to SRSO. Instead of overloading the X86_FEATURE_SRSO_NO bit to indicate this, define a separate mitigation to make the code cleaner. Signed-off-by: David Kaplan <david.kaplan@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: H . Peter Anvin <hpa@zytor.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250625155805.600376-2-david.kaplan@amd.com
2025-06-26arm64: dts: ti: k3-j784s4-j742s2-main-common: Add ACSPCIE1 nodeParth Pancholi1-0/+5
The ACSPCIE1 module on TI's J784S4 SoC is capable of driving the reference clock required by the PCIe Endpoint device. It is an alternative to on- board and external reference clock generators. Add the device-tree node for the same. Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Link: https://lore.kernel.org/r/20250513152155.1590689-1-parth105105@gmail.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-06-26arm64: dts: ti: k3-j722s-evm: Fix USB gpio-hog level for Type-CSiddharth Vadapalli1-1/+1
According to the "GPIO Expander Map / Table" section of the J722S EVM Schematic within the Evaluation Module Design Files package [0], the GPIO Pin P05 located on the GPIO Expander 1 (I2C0/0x23) has to be pulled down to select the Type-C interface. Since commit under Fixes claims to enable the Type-C interface, update the property within "p05-hog" from "output-high" to "output-low", thereby switching from the Type-A interface to the Type-C interface. [0]: https://www.ti.com/lit/zip/sprr495 Cc: stable@vger.kernel.org Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250623100657.4082031-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-06-26KVM: arm64: Fix error path in init_hyp_mode()Mostafa Saleh1-1/+6
In the unlikely case pKVM failed to allocate carveout, the error path tries to access NULL ptr when it de-reference the SVE state from the uninitialized nVHE per-cpu base. [ 1.575420] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1.576010] pc : teardown_hyp_mode+0xe4/0x180 [ 1.576920] lr : teardown_hyp_mode+0xd0/0x180 [ 1.577308] sp : ffff8000826fb9d0 [ 1.577600] x29: ffff8000826fb9d0 x28: 0000000000000000 x27: ffff80008209b000 [ 1.578383] x26: ffff800081dde000 x25: ffff8000820493c0 x24: ffff80008209eb00 [ 1.579180] x23: 0000000000000040 x22: 0000000000000001 x21: 0000000000000000 [ 1.579881] x20: 0000000000000002 x19: ffff800081d540b8 x18: 0000000000000000 [ 1.580544] x17: ffff800081205230 x16: 0000000000000152 x15: 00000000fffffff8 [ 1.581183] x14: 0000000000000008 x13: fff00000ff7f6880 x12: 000000000000003e [ 1.581813] x11: 0000000000000002 x10: 00000000000000ff x9 : 0000000000000000 [ 1.582503] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 43485e525851ff30 [ 1.583140] x5 : fff00000ff6e9030 x4 : fff00000ff6e8f80 x3 : 0000000000000000 [ 1.583780] x2 : 0000000000000000 x1 : 0000000000000002 x0 : 0000000000000000 [ 1.584526] Call trace: [ 1.584945] teardown_hyp_mode+0xe4/0x180 (P) [ 1.585578] init_hyp_mode+0x920/0x994 [ 1.586005] kvm_arm_init+0xb4/0x25c [ 1.586387] do_one_initcall+0xe0/0x258 [ 1.586819] do_initcall_level+0xa0/0xd4 [ 1.587224] do_initcalls+0x54/0x94 [ 1.587606] do_basic_setup+0x1c/0x28 [ 1.587998] kernel_init_freeable+0xc8/0x130 [ 1.588409] kernel_init+0x20/0x1a4 [ 1.588768] ret_from_fork+0x10/0x20 [ 1.589568] Code: f875db48 8b1c0109 f100011f 9a8903e8 (f9463100) [ 1.590332] ---[ end trace 0000000000000000 ]--- As Quentin pointed, the order of free is also wrong, we need to free SVE state first before freeing the per CPU ptrs. I initially observed this on 6.12, but I could also repro in master. Signed-off-by: Mostafa Saleh <smostafa@google.com> Fixes: 66d5b53e20a6 ("KVM: arm64: Allocate memory mapped at hyp for host sve state in pKVM") Reviewed-by: Quentin Perret <qperret@google.com> Link: https://lore.kernel.org/r/20250625123058.875179-1-smostafa@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-26KVM: arm64: Adjust range correctly during host stage-2 faultsQuentin Perret1-8/+12
host_stage2_adjust_range() tries to find the largest block mapping that fits within a memory or mmio region (represented by a kvm_mem_range in this function) during host stage-2 faults under pKVM. To do so, it walks the host stage-2 page-table, finds the faulting PTE and its level, and then progressively increments the level until it finds a granule of the appropriate size. However, the condition in the loop implementing the above is broken as it checks kvm_level_supports_block_mapping() for the next level instead of the current, so pKVM may attempt to map a region larger than can be covered with a single block. This is not a security problem and is quite rare in practice (the kvm_mem_range check usually forces host_stage2_adjust_range() to choose a smaller granule), but this is clearly not the expected behaviour. Refactor the loop to fix the bug and improve readability. Fixes: c4f0935e4d95 ("KVM: arm64: Optimize host memory aborts") Signed-off-by: Quentin Perret <qperret@google.com> Link: https://lore.kernel.org/r/20250625105548.984572-1-qperret@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-26KVM: arm64: nv: Fix MI line level calculation in vgic_v3_nested_update_mi()Wei-Lin Chang1-3/+1
The state of the vcpu's MI line should be asserted when its ICH_HCR_EL2.En is set and ICH_MISR_EL2 is non-zero. Using bitwise AND (&=) directly for this calculation will not give us the correct result when the LSB of the vcpu's ICH_MISR_EL2 isn't set. Correct this by directly computing the line level with a logical AND operation. Signed-off-by: Wei-Lin Chang <r09922117@csie.ntu.edu.tw> Link: https://lore.kernel.org/r/20250625084709.3968844-1-r09922117@csie.ntu.edu.tw [maz: drop the level check from the original code] Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-06-26x86/fpu: Delay instruction pointer fixup until after warningDave Hansen1-3/+2
Right now, if XRSTOR fails a console message like this is be printed: Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers. However, the text location (...+0x9a in this case) is the instruction *AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump also points one instruction late. The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and keep on running after returning from the #GP handler. But it does this fixup before warning. The resulting warning output is nonsensical because it looks like the non-FPU-related instruction is #GP'ing. Do not fix up RIP until after printing the warning. Do this by using the more generic and standard ex_handler_default(). Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails") Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Acked-by: Alison Schofield <alison.schofield@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250624210148.97126F9E%40davehans-spike.ostc.intel.com
2025-06-25arm64: dts: qcom: sm6115: add debug UART pinsBartosz Golaszewski1-0/+9
We should not rely on the bootloader to set up the pinmux of the debug UART port. Let's add pin definitions for uart4 to tlmm and bind them to the relevant device node. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250625152839.193672-1-brgl@bgdev.pl Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-25VFIO: KVM: x86: Drop kvm_arch_{start,end}_assignment()Sean Christopherson2-20/+0
Drop kvm_arch_{start,end}_assignment() and all associated code now that KVM x86 no longer consumes assigned_device_count. Tracking whether or not a VFIO-assigned device is formally associated with a VM is fundamentally flawed, as such an association is optional for general usage, i.e. is prone to false negatives. E.g. prior to commit 2edd9cb79fb3 ("kvm: detect assigned device via irqbypass manager"), device passthrough via VFIO would fail to enable IRQ bypass if userspace omitted the formal VFIO<=>KVM binding. And device drivers that *need* the VFIO<=>KVM connection, e.g. KVM-GT, shouldn't be relying on generic x86 tracking infrastructure. Cc: Jim Mattson <jmattson@google.com> Link: https://lore.kernel.org/r/20250523011756.3243624-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-25Revert "kvm: detect assigned device via irqbypass manager"Sean Christopherson1-8/+1
Now that KVM explicitly tracks the number of possible bypass IRQs, and doesn't conflate IRQ bypass with host MMIO access, stop bumping the assigned device count when adding an IRQ bypass producer. This reverts commit 2edd9cb79fb31b0907c6e0cdce2824780cf9b153. Link: https://lore.kernel.org/r/20250523011756.3243624-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-25Merge branch 'kvm-x86 mmio'Sean Christopherson6-8/+67
Merge the MMIO stale data branch with the device posted IRQs branch to provide a common base for removing KVM's tracking of "assigned" devices. Link: https://lore.kernel.org/all/20250523011756.3243624-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-25KVM: SVM: Simplify MSR interception logic for IA32_XSS MSRChao Gao1-5/+3
Use svm_set_intercept_for_msr() directly to configure IA32_XSS MSR interception, ensuring consistency with other cases where MSRs are intercepted depending on guest caps and CPUIDs. No functional change intended. Signed-off-by: Chao Gao <chao.gao@intel.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://lore.kernel.org/r/20250612081947.94081-3-chao.gao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-25KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flushManuel Andreas1-0/+3
In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated. However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way. Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses. Fixes: 260970862c88 ("KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently") Cc: stable@vger.kernel.org Signed-off-by: Manuel Andreas <manuel.andreas@tum.de> Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/c090efb3-ef82-499f-a5e0-360fc8420fb7@tum.de Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-25ARM: dts: microchip: sam9x7: Add LVDS controllerDharma Balasubiramani1-0/+9
Add support for LVDS controller. Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> Link: https://lore.kernel.org/r/20250625-b4-sam9x7-dts-v1-1-92aaee14ed16@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2025-06-25KVM: VMX: Apply MMIO Stale Data mitigation if KVM maps MMIO into the guestSean Christopherson6-5/+48
Enforce the MMIO State Data mitigation if KVM has ever mapped host MMIO into the VM, not if the VM has an assigned device. VFIO is but one of many ways to map host MMIO into a KVM guest, and even within VFIO, formally attaching a device to a VM via KVM_DEV_VFIO_FILE_ADD is entirely optional. Track whether or not the guest can access host MMIO on a per-MMU basis, i.e. based on whether or not the vCPU has a mapping to host MMIO. For simplicity, track MMIO mappings in "special" rools (those without a kvm_mmu_page) at the VM level, as only Intel CPUs are vulnerable, and so only legacy 32-bit shadow paging is affected, i.e. lack of precise tracking is a complete non-issue. Make the per-MMU and per-VM flags sticky. Detecting when *all* MMIO mappings have been removed would be absurdly complex. And in practice, removing MMIO from a guest will be done by deleting the associated memslot, which by default will force KVM to re-allocate all roots. Special roots will forever be mitigated, but as above, the affected scenarios are not expected to be performance sensitive. Use a VMX_RUN flag to communicate the need for a buffers flush to vmx_vcpu_enter_exit() so that kvm_vcpu_can_access_host_mmio() and all its dependencies don't need to be marked __always_inline, e.g. so that KASAN doesn't trigger a noinstr violation. Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Fixes: 8cb861e9e3c9 ("x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data") Tested-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Link: https://lore.kernel.org/r/20250523011756.3243624-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-25arm64: dts: exynos5433: Align i2c-gpio node names with dtschemaKrzysztof Kozlowski1-1/+1
New dtschema v2025.6 enforces different naming on I2C nodes thus new dtbs_check warnings appeared for I2C GPIO nodes: exynos5433-tm2.dtb: i2c-gpio-0 (i2c-gpio): $nodename:0: 'i2c-gpio-0' does not match '^i2c(@.+|-[a-z0-9]+)?$' exynos5433-tm2.dtb: i2c-gpio-0 (i2c-gpio): Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'amplifier@31' were unexpected) Rename the nodes to a generic i2c-[0-9]+ style with numbers continuing the SoC I2C controller indexing (3 controllers) for simplicity and obviousness, even if the SoC I2C controller is not enabled on given board. The names anyway would not conflict with SoC ones because of unit addresses. Verified with comparing two fdt (after fdtdump). Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Closes: https://lore.kernel.org/all/aCtD7BH5N_uPGkq7@shikoro/ Link: https://lore.kernel.org/r/20250612095549.77954-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-25ARM: dts: s5pv210: Align i2c-gpio node names with dtschemaKrzysztof Kozlowski4-11/+11
New dtschema v2025.6 enforces different naming on I2C nodes thus new dtbs_check warnings appeared for I2C GPIO nodes: s5pv210-fascinate4g.dtb: i2c-gpio-0 (i2c-gpio): $nodename:0: 'i2c-gpio-0' does not match '^i2c(@.+|-[a-z0-9]+)?$' s5pv210-fascinate4g.dtb: i2c-gpio-0 (i2c-gpio): Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'audio-codec@1a' were unexpected) Rename the nodes to a generic i2c-[0-9]+ style with numbers continuing the SoC I2C controller indexing (3 controllers) for simplicity and obviousness, even if the SoC I2C controller is not enabled on given board. The names anyway would not conflict with SoC ones because of unit addresses. Verified with comparing two fdt (after fdtdump). Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Closes: https://lore.kernel.org/all/aCtD7BH5N_uPGkq7@shikoro/ Link: https://lore.kernel.org/r/20250612094807.62532-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-25ARM: dts: exynos: Align i2c-gpio node names with dtschemaKrzysztof Kozlowski7-20/+20
New dtschema v2025.6 enforces different naming on I2C nodes thus new dtbs_check warnings appeared for I2C GPIO nodes: exynos4212-tab3-lte8.dtb: i2c-gpio-3 (i2c-gpio): $nodename:0: 'i2c-gpio-3' does not match '^i2c(@.+|-[a-z0-9]+)?$' exynos4212-tab3-lte8.dtb: i2c-gpio-3 (i2c-gpio): Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'magnetometer@2e' were unexpected) Rename the nodes to a generic i2c-[0-9]+ style with numbers continuing the SoC I2C controller indexing (Exynos3250: 8 controllers, Exynos4: 9 controllers) for simplicity and obviousness, even if the SoC I2C controller is not enabled on given board. The names anyway would not conflict with SoC ones because of unit addresses. Verified with comparing two fdt (after fdtdump). Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Closes: https://lore.kernel.org/all/aCtD7BH5N_uPGkq7@shikoro/ Link: https://lore.kernel.org/r/20250612094807.62532-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-25s390/boot: Use -D__DISABLE_EXPORTSPetr Pavlu1-2/+2
Files in the arch/s390/boot directory reuse logic from the rest of the kernel by including certain C and assembly files from the kernel and lib directories. Some of these included files contain EXPORT_SYMBOL directives. For instance, arch/s390/boot/cmdline.c includes lib/cmdline.c, which exports the get_option() function. This inclusion triggers genksyms processing for the files in arch/s390/boot, which is unnecessary and slows down the build. Additionally, when KBUILD_SYMTYPES=1 is set, the generated symtypes data contain exported symbols that are duplicated with the main kernel. This duplication can confuse external kABI tools that process the symtypes data. Address this issue by compiling the files in arch/s390/boot with -D__DISABLE_EXPORTS. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20250620154649.116068-1-petr.pavlu@suse.com Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-06-25um: vector: Reduce stack usage in vector_eth_configure()Tiwei Bie1-29/+13
When compiling with clang (19.1.7), initializing *vp using a compound literal may result in excessive stack usage. Fix it by initializing the required fields of *vp individually. Without this patch: $ objdump -d arch/um/drivers/vector_kern.o | ./scripts/checkstack.pl x86_64 0 ... 0x0000000000000540 vector_eth_configure [vector_kern.o]:1472 ... With this patch: $ objdump -d arch/um/drivers/vector_kern.o | ./scripts/checkstack.pl x86_64 0 ... 0x0000000000000540 vector_eth_configure [vector_kern.o]:208 ... Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506221017.WtB7Usua-lkp@intel.com/ Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250623110829.314864-1-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-25um: Use correct data source in fpregs_legacy_set()Tiwei Bie1-1/+1
Read from the buffer pointed to by 'from' instead of '&buf', as 'buf' contains no valid data when 'ubuf' is NULL. Fixes: b1e1bd2e6943 ("um: Add helper functions to get/set state for SECCOMP") Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250606124428.148164-5-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-25um: vfio: Prevent duplicate device assignmentsTiwei Bie1-0/+14
Ensure devices are assigned only once. Reject subsequent requests for duplicate assignments. Fixes: a0e2cb6a9063 ("um: Add VFIO-based virtual PCI driver") Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250606124428.148164-4-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-25um: ubd: Add missing error check in start_io_thread()Tiwei Bie1-1/+1
The subsequent call to os_set_fd_block() overwrites the previous return value. OR the two return values together to fix it. Fixes: f88f0bdfc32f ("um: UBD Improvements") Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20250606124428.148164-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-25loongarch, um, xtensa: get rid of generated arch/$ARCH/include/asm/param.hAl Viro3-3/+0
For loongarch and xtensa that gets them to do what x86 et.al. are doing - have asm/param.h resolve to uapi variant, which is generated by mandatory-y += param.h and contains exact same include. On um it will resolve to x86 uapi variant instead, which also contains the same include (um doesn't have uapi headers, but it does build the host ones). Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2025-06-25alpha: regularize the situation with asm/param.hAl Viro2-19/+2
The only reason why alpha can't do what sparc et.al. are doing is that include/asm-generic/param.h relies upon the value of HZ set for userland header in uapi/asm/param.h being 100. We need that value to define USER_HZ and we need that definition to outlive the redefinition of HZ kernel-side. And alpha needs it to be 1024, not 100 like everybody else. So let's add __USER_HZ to uapi/asm-generic/param.h, defaulting to 100 and used to define HZ. That way include/asm-generic/param.h can use that thing instead of open-coding it - it won't be affected by undefining and redefining HZ. That done, alpha asm/param.h can be removed and uapi/asm/param.h switched to defining __USER_HZ and EXEC_PAGESIZE and then including <asm-generic/param.h> - asm/param.h will resolve to uapi/asm/param.h, which pulls <asm-generic/param.h>, which will do the right thing both in the kernel and userland contexts. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-17 20:53:06 +0300