summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-05-27ARM: omap1: enable real software node lookup of GPIOs on Nokia 770Bartosz Golaszewski3-28/+15
Currently the board file for Nokia 770 creates dummy software nodes not attached in any way to the actual GPIO controller devices and uses the fact that GPIOLIB matching swnode's name to the GPIO chip's label during software node lookup. This behavior is wrong and we want to remove it. To that end, we need to first convert all existing users to creating actual fwnode links. Create real software nodes for GPIO controllers on OMAP16xx and reference them from the software nodes in the nokia board file. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/20260430-nokia770-gpio-swnodes-v7-3-c88f74c90dd6@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-27ARM: omap1: use platform_device_register_full() for GPIO devices on OMAP 16xxBartosz Golaszewski1-38/+33
Ahead of changes attaching GPIO controller's software nodes referenced from the Nokia 770 board files to their target devices, switch the method for registering the platform devices to the platform_device_register_full() variant. This is done to leverage the new swnode field of struct platform_device_info which automate the software node's registration and assignment. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/20260430-nokia770-gpio-swnodes-v7-2-c88f74c90dd6@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-27ARM: omap1: drop unused variable from omap16xx_gpio_init()Bartosz Golaszewski1-2/+0
The pdata variable is set but not used. Remove it. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/20260430-nokia770-gpio-swnodes-v7-1-c88f74c90dd6@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-27MIPS: alchemy: db1300: switch to static device propertiesDmitry Torokhov3-71/+156
Convert "5way switch" gpio-keys device and smsc911x ethernet controller to use static device properties instead of bespoke platform data structures for configuration. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [Bartosz: use platform_device_info::swnode] Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: alchemy: gpr: switch to static device propertiesDmitry Torokhov1-52/+75
Convert I2C-gpio device and GPIO-connected LEDs on GPR board to software nodes/properties, so that support for platform data can be removed from gpio-leds driver (which will rely purely on generic device properties for configuration). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [Bartosz: use platform_device_info::swnode] Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: alchemy: db1000: use nodes attached to GPIO chips in propertiesDmitry Torokhov1-21/+8
GPIO subsystem is switching the way it locates GPIO chip instances for GPIO references in software nodes by doing identity matching instead of matching on node names. Switch to using software nodes attached to gpio chips instead of using freestanding software nodes. Also stop supplying platform data for the spi-gpio controller since spi-gpio driver can derive number of chipselect lines from device properties. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: alchemy: mtx1: attach software nodes to GPIO chipsDmitry Torokhov3-22/+56
GPIO subsystem is switching the way it locates GPIO chip instances for GPIO references in software nodes from matching on node names to identity matching, which necessitates assigning firmware nodes (software nodes) to GPIO chips. Move the node definitions for alchemy-gpio1 and alchemy-gpio2 to arch/misp/alchemy/common/gpiolib.c, register them there, and attach them to gpio_chip instances. Adjust MTX1 board file to use these nodes. Note that because nodes need to be registered before they can be used in PROPERTY_ENTRY_GPIO() we have to do the registration at postcore_initcall level, otherwise (due to the link order) MTX1 board initialization code will run first. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [Bartosz: use platform_device_info::swnode] Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: alchemy: provide visible function prototypes to board filesBartosz Golaszewski6-10/+25
Board files under arch/mips/alchemy/ define functions called from db1xxx.c but their prototypes are only in that .c file instead of being declared in a common header. This causes several build warnings about missing prototypes. Provide these prototypes in a new header and include it where necessary. Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: alchemy: platform: add missing includeBartosz Golaszewski1-0/+2
Pull in the platform.h header into platform.c to fix the following warning: arch/mips/alchemy/devboards/platform.c:68:12: warning: no previous prototype for ‘db1x_register_pcmcia_socket’ [-Wmissing-prototypes] 68 | int __init db1x_register_pcmcia_socket(phys_addr_t pcmcia_attr_start, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/mips/alchemy/devboards/platform.c:152:12: warning: no previous prototype for ‘db1x_register_norflash’ [-Wmissing-prototypes] 152 | int __init db1x_register_norflash(unsigned long size, int width, | ^~~~~~~~~~~~~~~~~~~~~~ Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: ip22-gio: do not export device release functionJohan Hovold2-8/+1
There is no need to export the gio device release function as the devices are reference counted. Drop the export along with the unused inline wrapper. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: ip22-gio: switch to dynamic root deviceJohan Hovold1-16/+8
Driver core expects devices to be dynamically allocated and will, for example, complain loudly when no release function has been provided. Use root_device_register() to allocate and register the root device instead of open coding using a static device. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: ip22-gio: fix device reference leak in probeJohan Hovold1-4/+0
The gio probe function needlessly takes a device reference which is never released and therefore prevents unbound gio devices from being freed. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Cc: stable@vger.kernel.org # 3.3 Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: ip22-gio: fix gio device memory leakJohan Hovold1-0/+2
The gio device release callback was never wired up so gio devices are not freed when the last reference is dropped. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Cc: stable@vger.kernel.org # 3.3 Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27MIPS: ip22-gio: fix kfree() of static objectJohan Hovold1-1/+0
The gio bus root device is a statically allocated object which must not be freed by kfree() on failure to register the device or bus. Fixes: 82242d28ff8b ("MIPS: IP22: Add missing put_device call") Cc: stable@vger.kernel.org # 3.17 Cc: Levente Kurusa <levex@linux.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-27ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linenamePotin Lai1-2/+2
Fix the GPIO linenames for CPU_CHIPTHROT signals. The signals were incorrectly marked as output ("-O") while they are actually input signals ("-I"). [arj: Drop list of changed names] Signed-off-by: Potin Lai <potin.lai@quantatw.com> Link: https://patch.msgid.link/20260523-potin-update-sanmiguel-dts-20260522-v1-2-169f5fceb5f9@quantatw.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-05-27ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settingsPotin Lai1-0/+4
Kernel dmesg reports IRQ #44 being disabled due to unhandled interrupts from multiple PCA953x IO expanders: [ 447.047861] irq 44: nobody cared (try booting with the "irqpoll" option) [ 447.063124] handlers: [ 447.068176] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.087268] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.106344] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.125421] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.144513] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.163587] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.182663] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.201756] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.220837] Disabling IRQ #44 The affected IOEXP nodes are missing interrupt pin configuration in the device tree, causing the interrupt line to remain asserted and resulting in repeated unhandled IRQ events. Add the required interrupt-related properties for the affected IOEXP devices to ensure proper interrupt handling and prevent the IRQ from being disabled. [arj: Drop markdown code-block fence, favour indentation] Signed-off-by: Potin Lai <potin.lai@quantatw.com> Link: https://patch.msgid.link/20260523-potin-update-sanmiguel-dts-20260522-v1-1-169f5fceb5f9@quantatw.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-05-27ARM: dts: aspeed: clemente: Remove IOB NIC TMP421 nodesMike Hsieh1-20/+0
Remove the TMP421 sensor entry from the DTS, as it is no longer the primary telemetry source. Accessing the CX8 NIC via I2C while it is powered off causes voltage leakage on the bus, leading to EEPROM corruption on shared I2C devices. Removing this node prevents the BMC from initiating traffic to the NIC during initialization, protecting the integrity of the shared bus. Signed-off-by: Mike Hsieh <mike.quanta.115@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-05-27ARM: dts: aspeed: Enable networking for Asus Kommando IPMI CardAnirudh Srinivasan1-0/+18
Adds the DT nodes needed for ethernet support for Asus Kommando, with phy mode set to rgmii-id. When this DT was originally added, the phy mode was set to rgmii (which was incorrect). It was suggested to remove networking support from the DT till the Aspeed networking driver was patched so that the correct phy mode could be used. The discussion in [1] mentions that u-boot was inserting clk delays that weren't needed, which resulted in needing to set the phy mode in linux to rgmii incorrectly. The solution suggested there was to patch u-boot to no longer insert these clk delays and use rgmii-id as the phy mode for any future DTs added to linux. This DT was tested (on the OpenBMC u-boot fork [2]) with a u-boot DT modified to insert clk delays of 0 (instead of patching u-boot itself). [3] adds a u-boot DT for this device (without networking) and describes how to patch it to add networking support. If this patched DT is used, then networking works with rgmii-id phy mode in both u-boot and linux. [1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/ [2] https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc [3] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/ Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260331-asus-kommando-networking-v2-1-f7d72ae5d40d@gmail.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-05-27ARM: dts: aspeed: rainiera6: Add Meta Rainiera6 BMCNeil Cheng2-0/+1013
Add device tree for the Meta (Facebook) Rainiera6 compute node, based on AST2600 BMC. Signed-off-by: Neil Cheng <neilcheng0417@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-05-26KVM: x86: Treat KVM's virtual PMU as disabled for TDX VMsVishal Annapurve3-1/+12
Introduce a "protected PMU" concept, and use it to disable KVM's virtual PMU for TDX VMs, as the PMU state for TDX VMs is virtualized by the TDX Module[1], i.e. _can't_ emulated/virtualized by KVM, and KVM doesn't yet support enabling/exposing PMU functionality for/to TDX VMs. For now, simply treat the PMU as disabled, as it's not clear what all needs to be changed, e.g. KVM needs to do at least: 1) Configure TD_PARAMS to allow guests to use performance monitoring. 2) Restrict the TD to a subset of the PEBS counters if supported. 3) Limit the TD to setup a certain perfmon events using basic/enhanced event filtering. Explicitly disallow enabling the PMU via KVM_CAP_PMU_CAPABILITY for VMs with a protected PMU to prevent userspace from circumventing KVM's protections. Link: https://cdrdv2.intel.com/v1/dl/getContent/733575 Section 15.2[1] Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Vishal Annapurve <vannapurve@google.com> Link: https://patch.msgid.link/20260522151534.652522-1-vannapurve@google.com [sean: massage shortlog and changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: VMX: Synthesize nested EPT violation GVA_IS_VALID/GVA_TRANSLATED bitsKevin Cheng2-6/+33
When injecting an EPT Violation into L2 in response to a fault detected while emulating an L2 GVA access, synthesize the GVA_IS_VALID and GVA_TRANSLATED bits using information provided by the walker, instead of pulling the bits from vmcs02.EXIT_QUALIFICATION. The information in vmcs02.EXIT_QUALIFICATION is valid/correct if and only if the fault being injected into L1 is the direct result of an EPT Violation VM-Exit from L2. E.g. if KVM is emulating an I/O instruction and the memory operand's translation through L1's EPT fails, using vmcs02.EXIT_QUALIFICATION is wrong as the semantics for EXIT_QUALIFICATION would be for an I/O exit, not an EPT Violation exit. Opportunistically clean up the formatting for creating the mask of bits to pull from vmcs02.EXIT_QUALIFICATION. Signed-off-by: Kevin Cheng <chengkev@google.com> [sean: use plumbed in @access bits, massage changelog] Link: https://patch.msgid.link/20260522232701.3671446-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: SVM: Fix nested NPF injection of PFERR_GUEST_{PAGE,FINAL}_MASK bitsKevin Cheng3-21/+31
Fix KVM's generation of PFERR_GUEST_{PAGE,FINAL}_MASK bits when injecting a Nested Page Fault into L1. Currently, KVM blindly stuffs GUEST_FINAL into L1, which is blatantly wrong given that KVM obviously generates NPFs for page table accesses. There are two paths that trigger NPF injection: hardware NPF exits (from L2) and emulation-triggered faults, i.e. when KVM detects a NPF as part of emulating an L2 GVA access. For the hardware case, use the bits verbatim from the VMCB, as KVM is simply forwarding a NPF to L1. For the emulation case, propagate the GUEST_{PAGE,FINAL} bits from the access field (which were recently added for MBEC+GMET support). To differentiate between the two cases, add "hardware_nested_page_fault" to "struct x86_exception", and set it when injecting a NPF in response to an NPF exit from L2. To help guard against future goofs, assert that exactly one of GUEST_PAGE or GUEST_FINAL is set when injecting a NPF. Unlike VMX, there are no (known) cases where hardware doesn't set either bit, and KVM should always set one or the other when emulating a GVA access. Signed-off-by: Kevin Cheng <chengkev@google.com> [sean: use plumbed in @access bits, massage changelog] Link: https://patch.msgid.link/20260522232701.3671446-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: x86: Tell ->inject_page_fault() whether or a fault came from hardwareSean Christopherson5-14/+28
When injecting a page fault (including nested TDP faults into L1), tell the injection routine whether or not the fault originated in hardware, i.e. if KVM is effectively forwarding a fault it intercept. For nested TDP fault injection, KVM needs to grab PAGE_WALK vs. GUEST_FINAL information from the VMCB/VMCS, _if_ the fault originated in hardware. Note, simply checking whether or not the original exit was due a #NPF or EPT Violation isn't sufficient/correct, as the fault being synthesized for L1 may or may not be the "same" fault that triggered a VM-Exit from L2. E.g. if access to emulated MMIO in L2 hits a !PRESENT fault (EPT Violation or #NPF), e.g. because MMIO caching is disabled or it's the first time the GPA has been accessed by L2, then KVM will enter the emulator. If emulating the MMIO instruction then hits a nested TDP fault, e.g. because L2 was accessing MMIO with a MOVSQ (memory-to-memory move), or because L1 has since unmapped the code stream, then the TDP fault synthesized to L1 will not be the same emulated fault the triggered the VM-Exit. No functional change intended (nothing uses the new param, yet...). Link: https://patch.msgid.link/20260522232701.3671446-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26x86/virt/tdx: Move mk_keyed_paddr() to tdx.c due to no external usersYan Zhao2-6/+6
Move mk_keyed_paddr() from tdx.h to tdx.c to avoid unnecessary header inclusion and improve encapsulation since there are no users outside of tdx.c. No functional change intended. Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Acked-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260430015014.24261-1-yan.y.zhao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26x86/tdx: Drop exported function tdx_quirk_reset_page()Yan Zhao3-9/+2
KVM invokes tdx_quirk_reset_page() to reset TDX control pages (including S-EPT pages, TDR page, etc.), as all those pages are allocated by KVM TDX and thus always have struct page. However, it's also reasonable for KVM to reset those TDX control pages via tdx_quirk_reset_paddr() directly, eliminating the need to export two parallel APIs. Keeping tdx_quirk_reset_page() as a one-line helper in the header file is also unnecessary. No functional change intended. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Suggested-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Acked-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260430015001.24242-1-yan.y.zhao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26x86/tdx: Use PFN directly for unmapping guest private memorySean Christopherson3-16/+13
Remove struct page assumptions/constraints in APIs for unmapping guest private memory and have them take physical address directly. Having core TDX make assumptions that guest private memory must be backed by struct page (and/or folio) will create subtle dependencies on how KVM/guest_memfd allocates/manages memory (e.g., whether it uses memory allocated from core MM, if the memory is refcounted, or if the folio is split) that are easily avoided. [1]. KVM's MMUs work with PFNs. This is very much an intentional design choice. It ensures that the KVM MMUs remain flexible and are not too tightly tied to the regular CPU MMUs and the kernel code around them. Using "struct page" for TDX guest memory is not a good fit anywhere near the KVM MMU code [2]. Therefore, for unmapping guest private memory: export tdx_quirk_reset_paddr() for direct KVM invocation, and convert the SEAMCALL wrapper API tdh_phymem_page_wbinvd_hkid() to take PFN as input (thus updating mk_keyed_paddr() and tdh_phymem_page_wbinvd_tdr()). Intentionally have KVM pass PAGE_SIZE (rather than KVM_HPAGE_SIZE(level)) to tdx_quirk_reset_paddr() in tdx_sept_remove_private_spte() to avoid mixing in huge page changes. The KVM_BUG_ON() check for !PG_LEVEL_4K in tdx_sept_remove_private_spte() justifies using PAGE_SIZE. Do not convert tdx_reclaim_page() to use PFN as input since it currently does not remove guest private memory. Use "kvm_pfn_t pfn" for type safety. Using this KVM type is appropriate since APIs tdh_phymem_page_wbinvd_hkid() and tdx_quirk_reset_paddr() are exported to KVM only. [Yan: Use kvm_pfn_t,exclude tdx_reclaim_page(),use tdx_quirk_reset_paddr()] Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://lore.kernel.org/all/aWgyhmTJphGQqO0Y@google.com [1] Link: https://lore.kernel.org/all/ac7V0g2q2hN3dU5u@google.com [2] Acked-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260430014948.24226-1-yan.y.zhao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26x86/tdx: Use PFN directly for mapping guest private memorySean Christopherson3-13/+20
Remove struct page assumptions/constraints in the SEAMCALL wrapper APIs for mapping guest private memory and have them take PFN directly. Having core TDX make assumptions that guest private memory must be backed by struct page (and/or folio) will create subtle dependencies on how KVM/guest_memfd allocates/manages memory (e.g., whether it uses memory allocated from core MM, if the memory is refcounted, or if the folio is split) that are easily avoided. [1]. KVM's MMUs work with PFNs. This is very much an intentional design choice. It ensures that the KVM MMUs remain flexible and are not too tied to the regular CPU MMUs and the kernel code around them. Using 'struct page' for TDX guest memory is not a good fit anywhere near the KVM MMU code [2]. Use "kvm_pfn_t pfn" for type safety. Using this KVM type is appropriate since APIs tdh_mem_page_add() and tdh_mem_page_aug() are exported to KVM only. [ Yan: Replace "u64 pfn" with "kvm_pfn_t pfn" ] Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://lore.kernel.org/all/aWgyhmTJphGQqO0Y@google.com [1] Link: https://lore.kernel.org/all/ac7V0g2q2hN3dU5u@google.com [2] Acked-by: Kiryl Shutsemau <kas@kernel.org> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260430014929.24210-1-yan.y.zhao@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26ARM: rockchip: keep reset control aroundHeiko Stuebner1-6/+10
Do not put the reset control, retain exclusive control over it. After turning on a CPU, the corresponding reset line must stay deasserted. This also avoids calling reset_control_put() before workqueues are operational. Fixes: 78ebbff6d1a0 ("reset: handle removing supplier before consumers") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Steven Price <steven.price@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260521210915.2331176-1-heiko@sntech.de
2026-05-26module, riscv: force sh_addr=0 for arch-specific sectionsPetr Pavlu1-3/+3
When linking modules with 'ld.bfd -r', sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the resulting .ko files. Relocatable objects are expected to have sh_addr=0 for all sections. Non-zero addresses are confusing in this context, typically worse compressible, and may cause tools to misbehave [1]. Force sh_addr=0 for all riscv-specific module sections. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1] Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-05-26module, m68k: force sh_addr=0 for arch-specific sectionsPetr Pavlu1-1/+1
When linking modules with 'ld.bfd -r', sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the resulting .ko files. Relocatable objects are expected to have sh_addr=0 for all sections. Non-zero addresses are confusing in this context, typically worse compressible, and may cause tools to misbehave [1]. Force sh_addr=0 for all m68k-specific module sections. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1] Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-05-26module, arm64: force sh_addr=0 for arch-specific sectionsPetr Pavlu1-2/+2
When linking modules with 'ld.bfd -r', sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the resulting .ko files. Relocatable objects are expected to have sh_addr=0 for all sections. Non-zero addresses are confusing in this context, typically worse compressible, and may cause tools to misbehave [1]. Force sh_addr=0 for all arm64-specific module sections. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1] Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-05-26module, arm: force sh_addr=0 for arch-specific sectionsPetr Pavlu1-2/+2
When linking modules with 'ld.bfd -r', sections defined without an address inherit the location counter, resulting in non-zero sh_addr values in the resulting .ko files. Relocatable objects are expected to have sh_addr=0 for all sections. Non-zero addresses are confusing in this context, typically worse compressible, and may cause tools to misbehave [1]. Force sh_addr=0 for all arm-specific module sections. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1] Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-05-26x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guestBorislav Petkov5-15/+16
Patch in Fixes: causes the usual: unchecked MSR access error: RDMSR from 0x17 at ... (intel_get_platform_id) Call Trace: early_init_intel early_cpu_init setup_arch _printk start_kernel x86_64_start_reservations x86_64_start_kernel common_startup_64 because the kernel is booted in a guest. In order to avoid it, this MSR access needs to be prevented when running virtualized. That is usually done by checking X86_FEATURE_HYPERVISOR but for this particular case it is too early yet. The platform ID needs to be read as early as when microcode is loaded on the BSP: load_ucode_bsp ... -> get_microcode_blob ... -> intel_find_matching_signature and by that time, CPUID leafs haven't been parsed yet. The microcode loader already has logic to check early whether the kernel is running virtualized so make that globally available to arch/x86/. The query whether running virtualized is getting more and more prominent in recent times so might as well make it an arch-global var which the rest of the code can use. Fixes: d8630b67ca1ed ("x86/cpu: Add platform ID to CPU info structure") Reported-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Tested-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com
2026-05-26KVM: x86: Widen x86_exception's error_code to 64 bitsKevin Cheng2-1/+7
Widen the error_code field in struct x86_exception from u16 to u64 to accommodate AMD's NPF error code, which defines information bits above bit 31, e.g. PFERR_GUEST_FINAL_MASK (bit 32), and PFERR_GUEST_PAGE_MASK (bit 33). Retain the u16 type for the local errcode variable in walk_addr_generic as the walker synthesizes conventional #PF error codes that are architecturally limited to bits 15:0. Signed-off-by: Kevin Cheng <chengkev@google.com> Link: https://patch.msgid.link/20260522232701.3671446-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: SEV: Mark source page dirty when writing back CPUID data on failureAckerley Tng1-0/+1
When writing back CPUID data (provided by trusted firmware) to the source page on failure, mark the page/folio as dirty so that the data isn't lost in the unlikely scenario the page is reclaimed before its read by userspace. Fixes: 2a62345b3052 ("KVM: guest_memfd: GUP source pages prior to populating guest memory") Signed-off-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260522-fix-sev-gmem-post-populate-v2-5-3f196bfad5a1@google.com [sean: use set_page_dirty(), massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: SEV: Unmap local kmaps in LIFO order, per highmem requirementsAckerley Tng1-2/+2
Per highmem.h, local kernel mappings must be unmapped in the reserve order they were acquired, following a LIFO (last-in, first-out) stack-based approach, and that failure to do so "is invalid and causes malfunction". Swap the kunmap_local() calls in SNP post-populate flow to ensure the mappings are released in the correct order. Note, because SNP is 64-bit only, the bugs are benign as there are no highmem mappings to unwind. Fixes: 2a62345b3052 ("KVM: guest_memfd: GUP source pages prior to populating guest memory") Signed-off-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260522-fix-sev-gmem-post-populate-v2-4-3f196bfad5a1@google.com [sean: call out that the bug is benign] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: SEV: Pin source page for write when adding CPUID data for SNP guestSean Christopherson2-1/+2
When populating a guest_memfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the source page as KVM will write back the "correct" CPUID information if the userspace provided data is rejected by trusted firmware. Because KVM writes to the source page using a kernel mapping, pinning for read could result in KVM clobbering read-only memory. Note, well-behaved VMMs are unlikely to be affected, as CPUID information is almost always dynamically generated by userspace, i.e. it's unlikely for the CPUID information to be backed by a read-only mapping. Fixes: 2a62345b30529 ("KVM: guest_memfd: GUP source pages prior to populating guest memory") Cc: stable@vger.kernel.org Signed-off-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260522-fix-sev-gmem-post-populate-v2-1-3f196bfad5a1@google.com [sean: rewrite shortlog and changelog, tag for stable@] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-26KVM: arm64: Add fail-safe for refcounted pages in __pkvm_hyp_donate_hostVincent Donnefort1-4/+16
A previous bug in __pkvm_init_vm error path showed that the hypervisor could leak refcounted pages, (i.e. losing access to a page while its refcount is still elevated). This poses a threat to the pKVM state machine. Address this by introducing a fail-safe in __pkvm_hyp_donate_host. Transitions are not a hot path so added security is worth the extra check. Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260521143626.1005660-4-vdonnefort@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-26KVM: arm64: Fix __pkvm_init_vm error pathVincent Donnefort3-5/+13
In the unlikely case where insert_vm_table_entry fails, __pkvm_init_vm release the memory donated by the host for the PGD, but as the stage-2 is still set-up the hypervisor keeps a refcount on those pages, effectively leaking the references. Fix the rollback with the newly added kvm_guest_destroy_stage2(). Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization") Reported-by: Sashiko <sashiko-bot@kernel.org> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260521143626.1005660-3-vdonnefort@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-26KVM: arm64: Reset page order in pKVM hyp_poolVincent Donnefort2-7/+16
When a VM fails to initialise after its stage-2 hyp_pool has been initialised, that stage-2 must be torn down entirely. This requires resetting both the refcount and the order of its pages back to 0. Currently, reclaim_pgtable_pages() implicitly resets the page order by allocating the entire pool with order-0 granularity. However, in the VM initialisation error path, the addresses of the donated memory (the PGD) are already known, making it unnecessary to iterate over all pages in the pool. Since the vmemmap page order is a hyp_pool-specific field, leaving a non-zero order on hyp_pool destruction is harmless until another pool attempts to admit the page. Instead of resetting this field during destruction, reset it during pool initialization in hyp_pool_init(). For 'external' pages, we can't trust the order either as they bypass hyp_pool_init(). Since we never coalesce them, enforce order-0 to ensure safe insertion into the pool. This leaves no vmemmap order users outside of hyp_pool. Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260521143626.1005660-2-vdonnefort@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-05-26arm64: tegra: Enable PCIe for Jetson AGX ThorJon Hunter1-0/+12
Enable the PCIe controllers on the Jetson AGX Thor Developer Kit that are used for ethernet and NVMe. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-05-26arm64: tegra: Fix address of Tegra264 main GPIO controllerJon Hunter1-44/+44
The 64-bit address of the main GPIO controller on Tegra264 is 0x810c300000. The main GPIO controller was incorrectly added under the bus@0 node instead of the bus@8100000000 node breaking the boot on Tegra264. Fix this by moving to main GPIO controller node under bus@8100000000. Fixes: c70e6bc11d20 ("arm64: tegra: Add Tegra264 GPIO controllers") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-05-26ARM: socfpga: Fix OF node refcount leak in SMP setupYuho Choi1-0/+1
socfpga_smp_prepare_cpus() looks up the Cortex-A9 SCU node with of_find_compatible_node(), which returns a node reference that must be released with of_node_put(). The function maps the SCU registers and then returns without dropping that reference, leaking the node on both the success path and the of_iomap() failure path. Drop the reference once the mapping attempt is complete. The returned MMIO mapping does not depend on keeping the device node reference held. Fixes: 122694a0c712 ("ARM: socfpga: use of_iomap to map the SCU") Cc: stable@vger.kernel.org Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2026-05-26MIPS: Loongson64: dts: Add node for LS7A PCH LPCIcenowy Zheng1-0/+9
Loongson 7A series PCH contain a LPC IRQ controller. Add the device tree node of it. Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Acked-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-26MIPS: Loongson64: dts: Sort nodesIcenowy Zheng1-7/+7
The RTC's address is after UARTs, however the node is currently before them. Re-order the node to match address sequence. Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Acked-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-26MIPS: mobileye: Remove duplicate FIT_IMAGE_FDT_EPM5 from main KconfigSasha Levin1-9/+0
kconfiglint reports: K008: config FIT_IMAGE_FDT_EPM5 has prompts in 2 separate definitions The FIT_IMAGE_FDT_EPM5 Kconfig symbol is defined identically in two places: arch/mips/Kconfig:1052 arch/mips/mobileye/Kconfig:17 Both have the same prompt, depends, default, and help text. Since arch/mips/mobileye/Kconfig is sourced from arch/mips/Kconfig, both definitions are parsed and the symbol ends up with two prompts. The symbol was first introduced in commit 101bd58fde10 ("MIPS: Add support for Mobileye EyeQ5") directly in arch/mips/Kconfig. Three months later, commit fbe0fae601b7 ("MIPS: mobileye: Add EyeQ6H support") created the arch/mips/mobileye/Kconfig sub-file to organize the growing Mobileye platform code and added the MACH_EYEQ5/MACH_EYEQ6H choice along with a copy of FIT_IMAGE_FDT_EPM5. However, the original definition in arch/mips/Kconfig was not removed at that time, leaving a duplicate. Remove the definition from arch/mips/Kconfig, keeping the one in arch/mips/mobileye/Kconfig where it belongs alongside the related MACH_EYEQ5 machine type definition that it depends on. Assisted-by: Claude:claude-opus-4-6 kconfiglint Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-26MIPS: ralink: reduce ARCH_DMA_MINALIGNQingfang Deng1-0/+9
Currently, Ralink SoCs use the default ARCH_DMA_MINALIGN value of 128 bytes defined in mach-generic. This is excessive for these platforms and leads to significant memory waste in kmalloc. Override ARCH_DMA_MINALIGN to use L1_CACHE_BYTES, which is 16 bytes for RT288X and 32 bytes for other Ralink SoCs. Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-26mips: n64: add __iomem for writel callRosen Penev1-1/+1
sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *mem @@ got unsigned int [usertype] * Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202105261445.AcvPd2EE-lkp@intel.com/ Fixes: baec970aa5ba ("mips: Add N64 machine type") Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-26mips: ralink: mt7621: add missing __iomemRosen Penev1-1/+1
raw_readl and writel calls expect pointers annotated with __iomem. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild/202211060456.cnV6IK6G-lkp@intel.com/ Fixes: cc19db8b312a ("MIPS: ralink: mt7621: do memory detection on KSEG1") Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-05-26mips: cps: Assemble jr.hb with an R2 ISA levelRosen Penev1-0/+6
A MIPS allmodconfig built with LLVM can select CPU_MIPS32_R1 together with MIPS_MT_SMP. In that configuration clang invokes the integrated assembler with -march=mips32, and the MIPS MT path in cps-vec.S fails to assemble two jr.hb instructions: arch/mips/kernel/cps-vec.S:376:2: error: instruction requires a CPU feature not currently enabled arch/mips/kernel/cps-vec.S:490:4: error: instruction requires a CPU feature not currently enabled The earlier jr.hb in the same file is already assembled inside a .set MIPS_ISA_LEVEL_RAW scope. The two failing sites are reached after popping back to the file's base ISA level, so LLVM correctly rejects them for an R1 target. Wrap those jr.hb instructions in the same ISA-level push/pop used by the working site. This keeps the MT code unchanged while making the required R2 hazard-branch encoding explicit to the assembler. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 07:58:48 +0000