summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-11-13arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add NMI pushbutton supportOvidiu Panait1-0/+13
RZ/V2H EVK has a user pushbutton connected to the SoC NMI pin, which can be used to wake up the system from suspend to idle. Add a DT node in the device tree to instantiate the gpio-keys driver for this button. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251027140651.18367-1-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-11-13arm64: dts: renesas: rzg3s-smarc: Enable USB supportClaudiu Beznea1-0/+57
Enable USB support (host, device, USB PHYs). Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20251023135810.1688415-8-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-11-13arm64: dts: renesas: r9a08g045: Add USB supportClaudiu Beznea1-0/+118
Add USB nodes for the Renesas RZ/G3S SoC. This consists of PHY reset, host and device support. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20251023135810.1688415-7-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-11-13arm64: dts: renesas: r9a09g057: Add TSU nodesOvidiu Panait1-0/+75
The Renesas RZ/V2H SoC includes a Thermal Sensor Unit (TSU) block designed to measure the junction temperature. The device provides real-time temperature measurements for thermal management, utilizing two dedicated channels for temperature sensing: - TSU0, which is located near the DRP-AI block - TSU1, which is located near the CPU and DRP-AI block Since TSU1 is physically closer the CPU and the highest temperature spot, it is used for CPU throttling through a passive trip and cooling map. TSU0 is configured only with a critical trip. Add TSU nodes along with thermal zones and keep them enabled in the SoC DTSI. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251020143107.13974-4-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-11-13Merge branches 'acpi-cppc' and 'acpi-tables'Rafael J. Wysocki1-1/+1
Merge ACPI CPPC library fixes and an ACPI MRRM table parser fix for 6.18-rc6. * acpi-cppc: ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs ACPI: CPPC: Perform fast check switch only for online CPUs ACPI: CPPC: Check _CPC validity for only the online CPUs ACPI: CPPC: Detect preferred core availability on online CPUs * acpi-tables: ACPI: MRRM: Fix memory leaks and improve error handling
2025-11-13arm64/sysreg: Add ICH_VMCR_EL2Sascha Bischoff1-0/+21
Add the ICH_VMCR_EL2 register, which is required for the upcoming GICv5 KVM support. This register has two different field encodings, based on if it is used for GICv3 or GICv5-based VMs. The GICv5-specific field encodings are generated with a FEAT_GCIE prefix. This register is already described in the GICv3 KVM code directly. This will be ported across to use the generated encodings as part of an upcoming change. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64/sysreg: Move generation of RES0/RES1/UNKN to functionSascha Bischoff1-12/+14
The RESx and UNKN define generation happens in two places (EndSysreg and EndSysregFields), and was using nearly identical code. Split this out into a function, and call that instead, rather then keeping the dupliated code. There are no changes to the generated sysregs as part of this change. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64/sysreg: Support feature-specific fields with 'Prefix' descriptorSascha Bischoff1-38/+88
Some system register field encodings change based on, for example the in-use architecture features, or the context in which they are accessed. In order to support these different field encodings, introduce the Prefix descriptor (Prefix, EndPrefix) for describing such sysregs. The Prefix descriptor can be used in the following way: Sysreg EXAMPLE 0 1 2 3 4 Prefix FEAT_A Field 63:0 Foo EndPrefix Prefix FEAT_B Field 63:1 Bar Res0 0 EndPrefix Field 63:0 Baz EndSysreg This will generate a single set of system register encodings (REG_, SYS_, ...), and then generate three sets of field definitions for the system register called EXAMPLE. The first set is prefixed by FEAT_A, e.g. FEAT_A_EXAMPLE_Foo. The second set is prefixed by FEAT_B, e.g., FEAT_B_EXAMPLE_Bar. The third set is not given a prefix at all, e.g. EXAMPLE_BAZ. For each set, a corresponding set of defines for Res0, Res1, and Unkn is generated. The intent for the final prefix-less fields is to describe default or legacy field encodings. This ensure that prefixed encodings can be added to already-present sysregs without affecting existing legacy code. Prefixed fields must be defined before those without a prefix, and this is checked by the generator. This ensures consisnt ordering within the sysregs definitions. The Prefix descriptor can be used within Sysreg or SysregFields blocks. Field, Res0, Res1, Unkn, Rax, SignedEnum, Enum can all be used within a Prefix block. Fields and Mapping can not. Fields that vary with features must be described as part of a SysregFields block, instead. Mappings, which are just a code comment, make little sense in this context, and have hence not been included. There are no changes to the generated system register definitions as part of this change. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64/sysreg: Fix checks for incomplete sysreg definitionsSascha Bischoff1-3/+3
The checks for incomplete sysreg definitions were checking if the next_bit was greater than 0, which is incorrect and missed occasions where bit 0 hasn't been defined for a sysreg. The reason is that next_bit is -1 when all bits have been processed (LSB - 1). Change the checks to use >= 0, instead. Also, set next_bit in Mapping to -1 instead of 0 to match these new checks. There are no changes to the generated sysreg definitons as part of this change, and conveniently no definitions lack definitions for bit 0. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64: mm: make linear mapping permission update more robust for patial rangeYang Shi1-3/+3
The commit fcf8dda8cc48 ("arm64: pageattr: Explicitly bail out when changing permissions for vmalloc_huge mappings") made permission update for partial range more robust. But the linear mapping permission update still assumes update the whole range by iterating from the first page all the way to the last page of the area. Make it more robust by updating the linear mapping permission from the page mapped by start address, and update the number of numpages. Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Dev Jain <dev.jain@arm.com> Signed-off-by: Yang Shi <yang@os.amperecomputing.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64/mm: Elide TLB flush in certain pte protection transitionsDev Jain1-0/+27
Currently arm64 does an unconditional TLB flush in mprotect(). This is not required for some cases, for example, when changing from PROT_NONE to PROT_READ | PROT_WRITE (a real usecase - glibc malloc does this to emulate growing into the non-main heaps), and unsetting uffd-wp in a range. Therefore, implement pte_needs_flush() for arm64, which is already implemented by some other arches as well. Running a userspace program changing permissions back and forth between PROT_NONE and PROT_READ | PROT_WRITE, and measuring the average time taken for the none->rw transition, I get a reduction from 3.2 microseconds to 2.85 microseconds, giving a 12.3% improvement. Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Dev Jain <dev.jain@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64: dts: ti: k3-am62l: add initial reference board fileVignesh Raghavendra2-0/+364
Add the initial board file for the AM62L3's Evaluation Module. Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com> Link: https://patch.msgid.link/20251105-am62lx-v8-3-496f353e8237@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-13arm64: dts: ti: k3-am62l: add initial infrastructureVignesh Raghavendra5-0/+908
Add the initial infrastructure needed for the AM62L. ALl of which can be found in the Technical Reference Manual (TRM) located here: https://www.ti.com/lit/pdf/sprujb4 Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com> Link: https://patch.msgid.link/20251105-am62lx-v8-2-496f353e8237@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-13KVM: TDX: Use struct_size to simplify tdx_get_capabilities()Sean Christopherson1-9/+4
Use struct_size() instead of manually calculating the number of bytes to allocate for 'caps', including the nested flexible array, and copy all of 'caps' to user space with a single copy_to_user() call (thanks to the full size being provided by struct_size()). Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20251017213914.167301-1-thorsten.blum@linux.dev [sean: separate from swap of get_user() vs. kzalloc() ordering] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-11-13KVM: TDX: Check size of user's kvm_tdx_capabilities array before allocatingThorsten Blum1-11/+7
When userspace is getting TDX capabilities, retrieve and check the number of user entries before allocating kernel scratch space to avoid having to unwind the allocation if get_user() fails or if 'user_caps' is too small to fit 'caps'. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20251017213914.167301-1-thorsten.blum@linux.dev [sean: split to separate patch] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-11-13arm64: dts: ti: am69-aquila: Add CloverJoão Paulo Gonçalves2-0/+452
Add support for Aquila AM69 mated with Clover carrier board. Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69 Link: https://www.toradex.com/products/carrier-board/clover Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20251111175502.8847-4-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-13arm64: dts: ti: Add Aquila AM69 SupportParth Pancholi3-0/+2417
Add support for the Toradex Aquila AM69 and its Development Carrier Board. The Aquila AM69 SoM is based on the TI AM69 SoC from the Jacinto 7 family and is designed for high-end embedded computing, featuring up to 32GB of LPDDR4 and 256GB eMMC storage, extensive multimedia support (3x Quad CSI, 2x Quad DSI, DisplayPort, 5x Audio I2S/TDM), six Ethernet interfaces (1x 1G, 4x 2.5G SGMII, 1x 10G), USB 3.2 Host/DRD support, and a Wi-Fi 7/BT 5.3 module, alongside an RX8130 RTC, I2C EEPROM and Temperature Sensor, and optional TPM 2.0 module. Various nodes, inherited from the SoC dtsi, are explicitly disabled in the SoM dtsi file (`status = disabled`) even if already disabled. These nodes need to be disabled in the SoM, given that the node is not complete there, explicitly disabling it limits the dependency on the SoC dtsi allowing for refactoring without no impact on this file. Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69 Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Co-developed-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20251111175502.8847-3-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-13arm64/mm: Rename try_pgd_pgtable_alloc_init_mmLinu Cherian1-4/+4
With BUG_ON in pgd_pgtable_alloc_init_mm moved up to higher layer, gfp flags is the only difference between try_pgd_pgtable_alloc_init_mm and pgd_pgtable_alloc_init_mm. Hence rename the "try" version to pgd_pgtable_alloc_init_mm_gfp. Reviewed-by: Dev Jain <dev.jain@arm.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Linu Cherian <linu.cherian@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64/mm: Allow __create_pgd_mapping() to propagate pgtable_alloc() errorsChaitanya S Prakash1-78/+136
arch_add_memory() is used to hotplug memory into a system but as a part of its implementation it calls __create_pgd_mapping(), which uses pgtable_alloc() in order to build intermediate page tables. As this path was initally only used during early boot pgtable_alloc() is designed to BUG_ON() on failure. However, in the event that memory hotplug is attempted when the system's memory is extremely tight and the allocation were to fail, it would lead to panicking the system, which is not desirable. Hence update __create_pgd_mapping and all it's callers to be non void and propagate -ENOMEM on allocation failure to allow system to fail gracefully. But during early boot if there is an allocation failure, we want the system to panic, hence create a wrapper around __create_pgd_mapping() called early_create_pgd_mapping() which is designed to panic, if ret is non zero value. All the init calls are updated to use this wrapper rather than the modified __create_pgd_mapping() to restore functionality. Fixes: 4ab215061554 ("arm64: Add memory hotplug support") Reviewed-by: Dev Jain <dev.jain@arm.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Chaitanya S Prakash <chaitanyas.prakash@arm.com> Signed-off-by: Linu Cherian <linu.cherian@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13arm64/sysreg: Replace TCR_EL1 field macrosAnshuman Khandual9-123/+84
This just replaces all used TCR_EL1 field macros with tools sysreg variant based fields and subsequently drops them from the header (pgtable-hwdef.h), although while retaining the ones used for KVM (represented via the sysreg tools format). Cc: Will Deacon <will@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-13KVM: TDX: Fix sparse warnings from using 0 for NULLDave Hansen1-3/+3
Stop using 0 for NULL. sparse moans: ... arch/x86/kvm/vmx/tdx.c:859:38: warning: Using plain integer as NULL pointer for several TDX pointer initializations. While I love a good ptr=0 now and then, it's good to have quiet sparse builds. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Fixes: a50f673f25e0 ("KVM: TDX: Do TDX specific vcpu initialization") Fixes: 8d032b683c29 ("KVM: TDX: create/destroy VM structure") Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Xiaoyao Li <xiaoyao.li@intel.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: "Kirill A. Shutemov" <kas@kernel.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Acked-by: Kiryl Shutsemau <kas@kernel.org> Link: https://patch.msgid.link/20251103234439.DC8227E4@davehans-spike.ostc.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-11-13KVM: TDX: Remove __user annotation from kernel pointerDave Hansen1-1/+2
Separate __user pointer variable declaration from kernel one. There are two 'kvm_cpuid2' pointers involved here. There's an "input" side: 'td_cpuid' which is a normal kernel pointer and an 'output' side. The output here is userspace and there is an attempt at properly annotating the variable with __user: struct kvm_cpuid2 __user *output, *td_cpuid; But, alas, this is wrong. The __user in the definition applies to both 'output' and 'td_cpuid'. Sparse notices the address space mismatch and will complain about it. Fix it up by completely separating the two definitions so that it is obviously correct without even having to know what the C syntax rules even are. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Fixes: 488808e682e7 ("KVM: x86: Introduce KVM_TDX_GET_CPUID") Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Xiaoyao Li <xiaoyao.li@intel.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: "Kirill A. Shutemov" <kas@kernel.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Acked-by: Kiryl Shutsemau <kas@kernel.org> Link: https://patch.msgid.link/20251103234437.A0532420@davehans-spike.ostc.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-11-13KVM: TDX: Take MMU lock around tdh_vp_init()Rick Edgecombe1-3/+14
Take MMU lock around tdh_vp_init() in KVM_TDX_INIT_VCPU to prevent meeting contention during retries in some no-fail MMU paths. The TDX module takes various try-locks internally, which can cause SEAMCALLs to return an error code when contention is met. Dealing with an error in some of the MMU paths that make SEAMCALLs is not straight forward, so KVM takes steps to ensure that these will meet no contention during a single BUSY error retry. The whole scheme relies on KVM to take appropriate steps to avoid making any SEAMCALLs that could contend while the retry is happening. Unfortunately, there is a case where contention could be met if userspace does something unusual. Specifically, hole punching a gmem fd while initializing the TD vCPU. The impact would be triggering a KVM_BUG_ON(). The resource being contended is called the "TDR resource" in TDX docs parlance. The tdh_vp_init() can take this resource as exclusive if the 'version' passed is 1, which happens to be version the kernel passes. The various MMU operations (tdh_mem_range_block(), tdh_mem_track() and tdh_mem_page_remove()) take it as shared. There isn't a KVM lock that maps conceptually and in a lock order friendly way to the TDR lock. So to minimize infrastructure, just take MMU lock around tdh_vp_init(). This makes the operations we care about mutually exclusive. Since the other operations are under a write mmu_lock, the code could just take the lock for read, however this is weirdly inverted from the actual underlying resource being contended. Since this is covering an edge case that shouldn't be hit in normal usage, be a little less weird and take the mmu_lock for write around the call. Fixes: 02ab57707bdb ("KVM: TDX: Implement hooks to propagate changes of TDP MMU mirror page table") Reported-by: Yan Zhao <yan.y.zhao@intel.com> Suggested-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://patch.msgid.link/20251028002824.1470939-1-rick.p.edgecombe@intel.com Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> [sean: tweak comment and capture PUNCH_HOLE interaction] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-11-13Merge tag 'v6.18-rc5' into objtool/core, to pick up fixesIngo Molnar200-835/+1039
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-11-13Merge tag 'loongarch-fixes-6.18-1' of ↵Linus Torvalds23-81/+58
git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: - Fix a Rust build error - Fix exception/interrupt, memory management, perf event, hardware breakpoint, kexec and KVM bugs * tag 'loongarch-fixes-6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: KVM: Fix max supported vCPUs set with EIOINTC LoongArch: KVM: Skip PMU checking on vCPU context switch LoongArch: KVM: Restore guest PMU if it is enabled LoongArch: KVM: Add delay until timer interrupt injected LoongArch: KVM: Set page with write attribute if dirty track disabled LoongArch: kexec: Print out debugging message if required LoongArch: kexec: Initialize the kexec_buf structure LoongArch: Use correct accessor to read FWPC/MWPC LoongArch: Refine the init_hw_perf_events() function LoongArch: Remove __GFP_HIGHMEM masking in pud_alloc_one() LoongArch: Let {pte,pmd}_modify() record the status of _PAGE_DIRTY LoongArch: Consolidate max_pfn & max_low_pfn calculation LoongArch: Consolidate early_ioremap()/ioremap_prot() LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY LoongArch: Clarify 3 MSG interrupt features rust: Add -fno-isolate-erroneous-paths-dereference to bindgen_skip_c_flags
2025-11-13x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possibleSean Christopherson31-104/+130
Extend KVM's export macro framework to provide EXPORT_SYMBOL_FOR_KVM(), and use the helper macro to export symbols for KVM throughout x86 if and only if KVM will build one or more modules, and only for those modules. To avoid unnecessary exports when CONFIG_KVM=m but kvm.ko will not be built (because no vendor modules are selected), let arch code #define EXPORT_SYMBOL_FOR_KVM to suppress/override the exports. Note, the set of symbols to restrict to KVM was generated by manual search and audit; any "misses" are due to human error, not some grand plan. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Kai Huang <kai.huang@intel.com> Tested-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20251112173944.1380633-5-seanjc%40google.com
2025-11-13x86/mm: Drop unnecessary export of "ptdump_walk_pgd_level_debugfs"Sean Christopherson1-1/+0
Don't export "ptdump_walk_pgd_level_debugfs" as its sole user is arch/x86/mm/debug_pagetables.c, which can't be built as a module. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251112173944.1380633-4-seanjc%40google.com
2025-11-13x86/mtrr: Drop unnecessary export of "mtrr_state"Sean Christopherson1-1/+0
Don't export "mtrr_state" as usage is limited to arch/x86/kernel/cpu/mtrr (and nothing outside of that directory even includes the local mtrr.h). No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251112173944.1380633-3-seanjc%40google.com
2025-11-13x86/bugs: Drop unnecessary export of "x86_spec_ctrl_base"Sean Christopherson1-1/+0
Don't export x86_spec_ctrl_base as it's used only in bugs.c and process.c, neither of which can be built into a module. No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251112173944.1380633-2-seanjc%40google.com
2025-11-12arm64: defconfig: Enable SX150x GPIO expander driverFange Zhang1-0/+1
The ANX7625 bridge on the Qualcomm QCS615 Ride reference board is connected to a Semtech SX150x GPIO expander. Enable the SX150x driver to make the display on boards built following this design functional. Signed-off-by: Fange Zhang <fange.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251105-enable-sx150x-gpio-expander-v3-1-2ec8dfde2c9e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-12arm64: dts: intel: agilex5: Add Altera compatible for I3C controllersAdrian Ng Ho Yin1-2/+4
Add the "altr,agilex5-dw-i3c-master" compatible string to the I3C controller nodes on the Agilex5 SoCFPGA platform. Signed-off-by: Adrian Ng Ho Yin <adrianhoyin.ng@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2025-11-12Merge tag 'arm64-fpsimd-on-stack-for-v6.19' into libcrypto-fpsimd-on-stackEric Biggers19-538/+487
Pull fpsimd-on-stack changes from Ard Biesheuvel: "Shared tag/branch for arm64 FP/SIMD changes going through libcrypto" Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-12crash: let architecture decide crash memory export to iomem_resourceSourabh Jain1-0/+8
With the generic crashkernel reservation, the kernel emits the following warning on powerpc: WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/mem.c:341 add_system_ram_resources+0xfc/0x180 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-auto-12607-g5472d60c129f #1 VOLUNTARY Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.01 (NH1110_069) hv:phyp pSeries NIP: c00000000201de3c LR: c00000000201de34 CTR: 0000000000000000 REGS: c000000127cef8a0 TRAP: 0700 Not tainted (6.17.0-auto-12607-g5472d60c129f) MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 84000840 XER: 20040010 CFAR: c00000000017eed0 IRQMASK: 0 GPR00: c00000000201de34 c000000127cefb40 c0000000016a8100 0000000000000001 GPR04: c00000012005aa00 0000000020000000 c000000002b705c8 0000000000000000 GPR08: 000000007fffffff fffffffffffffff0 c000000002db8100 000000011fffffff GPR12: c00000000201dd40 c000000002ff0000 c0000000000112bc 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000015a3808 GPR24: c00000000200468c c000000001699888 0000000000000106 c0000000020d1950 GPR28: c0000000014683f8 0000000081000200 c0000000015c1868 c000000002b9f710 NIP [c00000000201de3c] add_system_ram_resources+0xfc/0x180 LR [c00000000201de34] add_system_ram_resources+0xf4/0x180 Call Trace: add_system_ram_resources+0xf4/0x180 (unreliable) do_one_initcall+0x60/0x36c do_initcalls+0x120/0x220 kernel_init_freeable+0x23c/0x390 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c This warning occurs due to a conflict between crashkernel and System RAM iomem resources. The generic crashkernel reservation adds the crashkernel memory range to /proc/iomem during early initialization. Later, all memblock ranges are added to /proc/iomem as System RAM. If the crashkernel region overlaps with any memblock range, it causes a conflict while adding those memblock regions as iomem resources, triggering the above warning. The conflicting memblock regions are then omitted from /proc/iomem. For example, if the following crashkernel region is added to /proc/iomem: 20000000-11fffffff : Crash kernel then the following memblock regions System RAM regions fail to be inserted: 00000000-7fffffff : System RAM 80000000-257fffffff : System RAM Fix this by not adding the crashkernel memory to /proc/iomem on powerpc. Introduce an architecture hook to let each architecture decide whether to export the crashkernel region to /proc/iomem. For more info checkout commit c40dd2f766440 ("powerpc: Add System RAM to /proc/iomem") and commit bce074bdbc36 ("powerpc: insert System RAM resource to prevent crashkernel conflict") Note: Before switching to the generic crashkernel reservation, powerpc never exported the crashkernel region to /proc/iomem. Link: https://lkml.kernel.org/r/20251016142831.144515-1-sourabhjain@linux.ibm.com Fixes: e3185ee438c2 ("powerpc/crash: use generic crashkernel reservation"). Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Closes: https://lore.kernel.org/all/90937fe0-2e76-4c82-b27e-7b8a7fe3ac69@linux.ibm.com/ Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Cc: Baoquan he <bhe@redhat.com> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12hung_task: panic when there are more than N hung tasks at the same timeLi RongQing1-1/+1
The hung_task_panic sysctl is currently a blunt instrument: it's all or nothing. Panicking on a single hung task can be an overreaction to a transient glitch. A more reliable indicator of a systemic problem is when multiple tasks hang simultaneously. Extend hung_task_panic to accept an integer threshold, allowing the kernel to panic only when N hung tasks are detected in a single scan. This provides finer control to distinguish between isolated incidents and system-wide failures. The accepted values are: - 0: Don't panic (unchanged) - 1: Panic on the first hung task (unchanged) - N > 1: Panic after N hung tasks are detected in a single scan The original behavior is preserved for values 0 and 1, maintaining full backward compatibility. [lance.yang@linux.dev: new changelog] Link: https://lkml.kernel.org/r/20251015063615.2632-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Tested-by: Lance Yang <lance.yang@linux.dev> Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au> [aspeed_g5_defconfig] Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Hildenbrand <david@redhat.com> Cc: Florian Wesphal <fw@strlen.de> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Jason A. Donenfeld <jason@zx2c4.com> Cc: Joel Granados <joel.granados@kernel.org> Cc: Joel Stanley <joel@jms.id.au> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kees Cook <kees@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: "Paul E . McKenney" <paulmck@kernel.org> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Phil Auld <pauld@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Shuah Khan <shuah@kernel.org> Cc: Simon Horman <horms@kernel.org> Cc: Stanislav Fomichev <sdf@fomichev.me> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12treewide: drop outdated compiler version remarks in Kconfig help textsLukas Bulwahn2-13/+8
As of writing, Documentation/Changes states the minimal versions of GNU C being 8.1, Clang being 15.0.0 and binutils being 2.30. A few Kconfig help texts are pointing out that specific GCC and Clang versions are needed, but by now, those pointers to versions, such later than 4.0, later than 4.4, or clang later than 5.0, are obsolete and unlikely to be found by users configuring their kernel builds anyway. Drop these outdated remarks in Kconfig help texts referring to older compiler and binutils versions. No functional change. Link: https://lkml.kernel.org/r/20251010082138.185752-1-lukas.bulwahn@redhat.com Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Cc: Bill Wendling <morbo@google.com> Cc: Justin Stitt <justinstitt@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Russel King <linux@armlinux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12Merge tag 'scoped-ksimd-for-arm-arm64' into libcrypto-fpsimd-on-stackEric Biggers2-0/+14
Pull scoped ksimd API for ARM and arm64 from Ard Biesheuvel: "Introduce a more strict replacement API for kernel_neon_begin()/kernel_neon_end() on both ARM and arm64, and replace occurrences of the latter pair appearing in lib/crypto" Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-12arm64: Fix double word in commentsBo Liu2-2/+2
Remove the repeated word "the" in comments. Signed-off-by: Bo Liu <liubo03@inspur.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-12riscv: defconfig: Enable Anlogic SoCJunhui Liu1-0/+1
Enable Anlogic SoC config in defconfig to allow the default upstream kernel booting on Milianke MLKPAI-FS01 board. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12riscv: dts: anlogic: Add Milianke MLKPAI FS01 boardJunhui Liu3-0/+31
Add support for the Milianke MLKPAI FS01 board based on the Anlogic DR1V90 SoC. The board features 512MB of onboard memory, USB-C UART, 1GbE RJ45 Ethernet, USB-A 2.0 port, TF card slot, and 256Mbit Quad-SPI flash. Currently, the board can boot to a console via UART1, which is connected to the onboard serial chip and routed to the Type-C interface. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12riscv: dts: Add initial Anlogic DR1V90 SoC device treeJunhui Liu1-0/+100
DR1V90 is a FPSoC from Anlogic, which features a RISC-V core as the PS part and 94,464 LUTs for the PL part. The PS part integrates a Nuclei UX900 RISC-V core with 32KB L1 icache and 32KB L1 dcache. It also provides two "snps,dw-apb-uart" compatible UART controllers. Some basic information of the processor can be obtained by running a simple application from nuclei-sdk [1]: -----Nuclei RISC-V CPU Configuration Information----- MARCHID: 0xc900 MIMPID: 0x20300 ISA: RV64 A B C D F I M P S U MCFG: TEE ECC ECLIC PLIC PPI ILM DLM ICACHE DCACHE IREGION No-Safety-Mechanism DLEN=VLEN/2 ILM: 256 KB has-ecc DLM: 256 KB has-ecc ICACHE: 32 KB(set=256,way=2,lsize=64,ecc=1) DCACHE: 32 KB(set=256,way=2,lsize=64,ecc=1) TLB: MainTLB(set=32,way=2,entry=1,ecc=1) ITLB(entry=8) DTLB(entry=8) IREGION: 0x68000000 128 MB Unit Size Address INFO 64KB 0x68000000 DEBUG 64KB 0x68010000 ECLIC 64KB 0x68020000 TIMER 64KB 0x68030000 PLIC 64MB 0x6c000000 INFO-Detail: mpasize : 0 PPI: 0xf8000000 128 MB -----End of Nuclei CPU INFO----- Link: https://github.com/Nuclei-Software/nuclei-sdk/blob/master/application/baremetal/cpuinfo/main.c [1] Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12riscv: Add Anlogic SoC famly Kconfig supportJunhui Liu1-0/+5
The first SoC in the Anlogic series is DR1V90, which contains a RISC-V core from Nuclei. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12arm64: Fix typos and spelling errors in commentsmrigendrachaubey18-22/+22
This patch corrects several minor typographical and spelling errors in comments across multiple arm64 source files. No functional changes. Signed-off-by: mrigendrachaubey <mrigendra.chaubey@gmail.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-12riscv: defconfig: enable SPI_FSL_QUADSPI as a moduleAlex Elder1-0/+1
The SpacemiT K1 SoC QSPI IP uses the Freescale driver. Enable it as a module in the default kernel configuration for RISC-V. Acked-by: Paul Walmsley <pjw@kernel.org> # for arch/riscv Signed-off-by: Alex Elder <elder@riscstar.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12perf/x86/intel: Fix and clean up intel_pmu_drain_arch_pebs() type useIngo Molnar1-2/+1
The following commit introduced a build failure on x86-32: 21954c8a0ff ("perf/x86/intel: Process arch-PEBS records or record fragments") ... arch/x86/events/intel/ds.c:2983:24: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] The forced type conversion to 'u64' and 'void *' are not 32-bit clean, but they are also entirely unnecessary: ->pebs_vaddr is 'void *' already, and integer-compatible pointer arithmetics will work just fine on it. Fix & simplify the code. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: d21954c8a0ff ("perf/x86/intel: Process arch-PEBS records or record fragments") Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Cc: Kan Liang <kan.liang@linux.intel.com> Link: https://patch.msgid.link/20251029102136.61364-10-dapeng1.mi@linux.intel.com
2025-11-12riscv: dts: spacemit: define all missing I2C controller nodesTroy Mitchell1-0/+80
SpacemiT K1 SoC is equipped with a total of nine I2C controllers, ranging from I2C0 to I2C8. Prior to this change, only I2C2 and I2C8 were explicitly defined within the device tree. This patch comprehensively adds the device tree node definitions for I2C controller 0, 1, 4 to 7. The I2C3 node is not added because it belongs exclusively to the secure domain which not used in the linux realm. All newly added I2C nodes are set to "disabled" status by default, allowing future board-specific device tree to enable and configure. Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://lore.kernel.org/r/20251105-k1-add-i2c-node-v1-2-d18dae246137@linux.spacemit.com Signed-off-by: Yixun Lan <dlan@gentoo.org>
2025-11-12KVM: arm64: VHE: Compute fgt traps before activating themAlexandru Elisei1-1/+1
On VHE, the Fine Grain Traps registers are written to hardware in kvm_arch_vcpu_load()->..->__activate_traps_hfgxtr(), but the fgt array is computed later, in kvm_vcpu_load_fgt(). This can lead to zero being written to the FGT registers the first time a VCPU is loaded. Also, any changes to the fgt array will be visible only after the VCPU is scheduled out, and then back in, which is not the intended behaviour. Fix it by computing the fgt array just before the fgt traps are written to hardware. Fixes: fb10ddf35c1c ("KVM: arm64: Compute per-vCPU FGTs at vcpu_load()") Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20251112102853.47759-1-alexandru.elisei@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-11-12riscv: dts: spacemit: reorder i2c2 nodeTroy Mitchell1-13/+13
Reorder the i2c2 node to its correct position according to its register address.This improves the readability and maintainability of the device tree file by adhering to the established ordering convention. No functional change is introduced by this reordering. Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://lore.kernel.org/r/20251105-k1-add-i2c-node-v1-1-d18dae246137@linux.spacemit.com Signed-off-by: Yixun Lan <dlan@gentoo.org>
2025-11-12ARM: dts: renesas: r9a06g032: Add the ADC deviceHerve Codina (Schneider Electric)1-0/+10
The ADC available in the r9a06g032 SoC can use up to two internal ADC cores (ADC1 and ADC2) those internal cores are handled through ADC controller virtual channels. Describe this device. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251103141834.71677-4-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-11-12riscv: dts: spacemit: Add OrangePi R2S board device treeMichael Opdenacker2-0/+91
Add initial device tree support for the OrangePi RV2 board [1], which is marketed as using the Ky X1 SoC but is identical in die and package to the SpacemiT K1 SoC [2]. Enable UART0, to boot into a serial console Two Gigabit Ethernet ports with RGMII interface standard support are enabled, each port is connected to an external Motorcomm YT8531C PHY chip which uses the GPIO for reset control. Enable PDMA. Enable 8 GB eMMC chip for storage. Link: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-R2S.html [1] Link: https://www.spacemit.com/en/key-stone-k1 [2] Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> Reviewed-by: Yixun Lan <dlan@gentoo.org> Link: https://lore.kernel.org/r/20251112044426.2351999-3-michael.opdenacker@rootcommit.com Signed-off-by: Yixun Lan <dlan@gentoo.org>
2025-11-12arm64: dts: renesas: r9a09g087: Add GMAC nodesLad Prabhakar1-0/+448
Add Ethernet MAC (GMAC) device nodes to the RZ/N2H (R9A09G087) SoC DTSI. The RZ/N2H integrates three GMAC interfaces based on the Synopsys DesignWare MAC (version 5.20). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251028175458.1037397-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>