summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-03-06arm64: dts: renesas: r8a77965: Describe PCIe root portsMarek Vasut
Add nodes which describe the root ports in the PCIe controller DT nodes. This can be used together with the pwrctrl driver to control clock and power supply to a PCIe slot. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260118135038.8033-5-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a77961: Describe PCIe root portsMarek Vasut
Add nodes which describe the root ports in the PCIe controller DT nodes. This can be used together with the pwrctrl driver to control clock and power supply to a PCIe slot. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260118135038.8033-4-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a77960: Describe PCIe root portsMarek Vasut
Add nodes which describe the root ports in the PCIe controller DT nodes. This can be used together with the pwrctrl driver to control clock and power supply to a PCIe slot. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260118135038.8033-3-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a77951: Describe PCIe root portsMarek Vasut
Add nodes which describe the root ports in the PCIe controller DT nodes. This can be used together with the pwrctrl driver to control clock and power supply to a PCIe slot. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260118135038.8033-2-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06ARM: dts: renesas: r9a06g032: Add support for CPU frequency scalingHerve Codina (Schneider Electric)
In RZ/N1 SoCs, CPUs are allowed to work at 125, 250 or 500 MHz when the 'ref' clock frequency value is set to 500 MHz which is the default 'ref' clock frequency value. Add support for CPU frequency scaling defining those 3 frequencies in the opp-table with the assumption that the 'ref' clock is set to its default value. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260115164905.1203453-1-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: sparrow-hawk: Mark OTP and HSCIF0 pins as bootph-allMarek Vasut
The U-Boot SPL is responsible for initializing the hardware and it does also initialize HSCIF0 and its pinmux, mark the HSCIF0 pinmux as needed in all bootloader stages. The SPL also uses OTP to determine the exact V4H SoC variant during DRAM initialization, to determine which is the maximum allowed DRAM rate, mark OTP as required in all bootloader stages as well. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260112234642.225993-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbersGeert Uytterhoeven
SPI interrupts are in the range 0-987. Extended SPI interrupts should use GIC_ESPI, instead of abusing GIC_SPI with a manual offset of 4064. Fixes: 63500d12cf76d003 ("arm64: dts: renesas: Add R8A78000 SoC support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/1f9dd274720ea1b66617a5dd84f76c3efc829dc8.1772641415.git.geert+renesas@glider.be
2026-03-06arm64: dts: renesas: rzg3s-smarc-som: Set bypass for Versa3 PLL2Claudiu Beznea
The default settings for the Versa3 device on the Renesas RZ/G3S SMARC SoM board have PLL2 disabled. PLL2 was later enabled together with audio support, as it is required to support both 44.1 kHz and 48 kHz audio. With PLL2 enabled, it was observed that Linux occasionally either hangs during boot (the last log message being related to the I2C probe) or randomly crashes. This was mainly reproducible on cold boots. During debugging, it was also noticed that the Unicode replacement character (�) sometimes appears on the serial console. Further investigation traced this to the configuration applied through the Versa3 register at offset 0x1c, which controls PLL enablement. The appearance of the Unicode replacement character suggested an issue with the SoC reference clock. The RZ/G3S reference clock is provided by the Versa3 clock generator (REF output). After checking with the Renesas Versa3 hardware team, it was found that this is related to the PLL2 lock bit being set through the renesas,settings DT property. The PLL lock bit must be set to avoid unstable clock output from the PLL. However, due to the Versa3 hardware design, when a PLL lock bit is set, all outputs (including the REF clock) are temporarily disabled until the configured PLLs become stable. As an alternative, the bypass bit can be used. This does not interrupt the PLL2 output or any other Versa3 outputs, but it may result in temporary instability on PLL2 output while the configuration is applied. Since PLL2 feeds only the audio path and audio is not used during early boot, this is acceptable and does not affect system boot. Drop the PLL2 lock bit and set the bypass bit instead. This has been tested with more than 1000 cold boots. Fixes: a94253232b04 ("arm64: dts: renesas: rzg3s-smarc-som: Add versa3 clock generator node") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260302135703.162601-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g087: Fix CPG register region sizesLad Prabhakar
The CPG register regions were incorrectly sized. Update them to match the actual hardware specification: - First region (0x80280000): 0x1000 -> 0x10000 (64kiB) - Second region (0x81280000): 0x9000 -> 0x10000 (64kiB) Fixes: 4b3d31f0b81fe ("arm64: dts: renesas: Add initial SoC DTSI for the RZ/N2H SoC") 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/20260213131742.3606334-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g077: Fix CPG register region sizesLad Prabhakar
The CPG register regions were incorrectly sized. Update them to match the actual hardware specification: - First region (0x80280000): 0x1000 -> 0x10000 (64kiB) - Second region (0x81280000): 0x9000 -> 0x10000 (64kiB) Fixes: d17b34744f5e4 ("arm64: dts: renesas: Add initial support for the Renesas RZ/T2H SoC") 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/20260213131742.3606334-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g057: Remove wdt{0,2,3} nodesFabrizio Castro
The HW user manual for the Renesas RZ/V2H(P) SoC (a.k.a r9a09g057) states that only WDT1 is supposed to be accessed by the CA55 cores. WDT0 is supposed to be used by the CM33 core, WDT2 is supposed to be used by the CR8 core 0, and WDT3 is supposed to be used by the CR8 core 1. Remove wdt{0,2,3} from the SoC specific device tree to make it compliant with the specification from the HW manual. This change is harmless as there are currently no users of the wdt{0,2,3} device tree nodes, only the wdt1 node is actually used. Fixes: 095105496e7d ("arm64: dts: renesas: r9a09g057: Add WDT0-WDT3 nodes") Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260203124247.7320-3-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: rzv2-evk-cn15-sd: Add ramp delay for SD0 regulatorLad Prabhakar
Set an appropriate ramp delay for the SD0 I/O voltage regulator in the CN15 SD overlay to make UHS-I voltage switching reliable during card initialization. This issue was observed on the RZ/V2H EVK, while the same UHS-I cards worked on the RZ/V2N EVK without problems. Adding the ramp delay makes the behavior consistent and avoids SD init timeouts. Before this change SD0 could fail with: mmc0: error -110 whilst initialising SD card With the delay in place UHS-I cards enumerate correctly: mmc0: new UHS-I speed SDR104 SDXC card at address aaaa mmcblk0: mmc0:aaaa SR64G 59.5 GiB mmcblk0: p1 Fixes: 3d6c2bc7629c8 ("arm64: dts: renesas: Add CN15 eMMC and SD overlays for RZ/V2H and RZ/V2N EVKs") 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/20260123225957.1007089-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: rzt2h-n2h-evk: Add ramp delay for SD0 card regulatorLad Prabhakar
Add a ramp delay of 60 uV/us to the vqmmc_sdhi0 voltage regulator to fix UHS-I SD card detection failures. Measurements on CN78 pin 4 showed the actual voltage ramp time to be 21.86ms when switching between 3.3V and 1.8V. A 25ms ramp delay has been configured to provide adequate margin. The calculation is based on the voltage delta of 1.5V (3.3V - 1.8V): 1500000 uV / 60 uV/us = 25000 us (25ms) Prior to this patch, UHS-I cards failed to initialize with: mmc0: error -110 whilst initialising SD card After this patch, UHS-I cards are properly detected on SD0: mmc0: new UHS-I speed SDR104 SDXC card at address aaaa mmcblk0: mmc0:aaaa SR64G 59.5 GiB Fixes: d065453e5ee09 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable SD card slot") 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/20260123225957.1007089-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06KVM: s390: Fix a deadlockClaudio Imbrenda
In some scenarios, a deadlock can happen, involving _do_shadow_pte(). Convert all usages of pgste_get_lock() to pgste_get_trylock() in _do_shadow_pte() and return -EAGAIN. All callers can already deal with -EAGAIN being returned. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Tested-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
2026-03-06arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faultsPiotr Jaroszynski
contpte_ptep_set_access_flags() compared the gathered ptep_get() value against the requested entry to detect no-ops. ptep_get() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTE_RDONLY set in hardware. For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop. Gathering can therefore cause false no-ops when only a sibling has been updated: - write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared) - read faults: target still lacks PTE_AF Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by __ptep_set_access_flags()), using raw per-PTE values rather than the gathered ptep_get() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision. Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range. Fixes: 4602e5757bcc ("arm64/mm: wire up PTE_CONT for user mappings") Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Breno Leitao <leitao@debian.org> Cc: stable@vger.kernel.org Reviewed-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: James Houghton <jthoughton@google.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Breno Leitao <leitao@debian.org> Signed-off-by: Piotr Jaroszynski <pjaroszynski@nvidia.com> Acked-by: Balbir Singh <balbirs@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-06KVM: arm64: Remove the redundant ISB in __kvm_at_s1e2()Zenghui Yu (Huawei)
We already have an ISB in __kvm_at() to make the address translation result visible to subsequent reads of PAR_EL1. Remove the redundant one right after it. Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260306074422.47694-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-06KVM: arm64: Fix vma_shift staleness on nested hwpoison pathFuad Tabba
When user_mem_abort() handles a nested stage-2 fault, it truncates vma_pagesize to respect the guest's mapping size. However, the local variable vma_shift is never updated to match this new size. If the underlying host page turns out to be hardware poisoned, kvm_send_hwpoison_signal() is called with the original, larger vma_shift instead of the actual mapping size. This signals incorrect poison boundaries to userspace and breaks hugepage memory poison containment for nested VMs. Update vma_shift to match the truncated vma_pagesize when operating on behalf of a nested hypervisor. Fixes: fd276e71d1e7 ("KVM: arm64: nv: Handle shadow stage 2 page faults") Signed-off-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260304162222.836152-3-tabba@google.com [maz: simplified vma_shift assignment from the original patch] Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-06perf/x86/amd/ibs: Fix comment typo in ibs_op_dataYen-Hsiang Hsu
The comment for tag_to_ret_ctr in ibs_op_data says "15-31" but it should be "16-31". Fix the misleading comment. No functional changes. Signed-off-by: Yen-Hsiang Hsu <rrrrr4413@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260113141830.3204114-1-rrrrr4413@gmail.com
2026-03-06parisc: Fix initial page table creation for bootHelge Deller
The KERNEL_INITIAL_ORDER value defines the initial size (usually 32 or 64 MB) of the page table during bootup. Up until now the whole area was initialized with PTE entries, but there was no check if we filled too many entries. Change the code to fill up with so many entries that the "_end" symbol can be reached by the kernel, but not more entries than actually fit into the initial PTE tables. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v6.0+
2026-03-06parisc: Check kernel mapping earlier at bootupHelge Deller
The check if the initial mapping is sufficient needs to happen much earlier during bootup. Move this test directly to the start_parisc() function and use native PDC iodc functions to print the warning, because panic() and printk() are not functional yet. This fixes boot when enabling various KALLSYSMS options which need much more space. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v6.0+
2026-03-06parisc: Increase initial mapping to 64 MB with KALLSYMSHelge Deller
The 32MB initial kernel mapping can become too small when CONFIG_KALLSYMS is used. Increase the mapping to 64 MB in this case. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v6.0+
2026-03-06ARM: dts: stm32: enable DCMI DMA-MDMA chaining on stm32mp157c-ev1.dtsAlain Volmat
Enable the DMA-MDMA chaining for the dcmi (camera capture) in order to be able to achieve higher resolution. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://lore.kernel.org/r/20260106-stm32-dcmi-dma-chaining-v2-12-70688bccd80a@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: add sram node within stm32mp151.dtsiAlain Volmat
Introduce the sram node in order to be used by drivers requiring SRAM memory space. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://lore.kernel.org/r/20260106-stm32-dcmi-dma-chaining-v2-11-70688bccd80a@foss.st.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phyboard-sargas and phycore: Add optional interfacesChristophe Parant
- stm32mp15xx-phycore-som: add NAND device on FMC interface to support the SoM version equipped with NAND flash instead of eMMC. - stm32mp15xx-phyboard-sargas: define pinctrl for PWM5, LTDC and DCMI interfaces used on phyBOARD-Sargas. Those interfaces are not enabled by default as PHYTEC displays and PHYTEC cameras are enabled and configured throught device tree overlays. PWM5 is used for LCD backlight command. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phyboard-sargas and phycore: Fix coding style issuesChristophe Parant
- Remove "stm32-pinfunc.h" include as it is already include in "stm32mp15-pinctrl.dtsi" file. - reserved-memory: reorder the memory sections (lower to higher addresses). - Move vendor properties (go last). - Remove useless compatible values: - QSPI flash: remove the winbond compatible. jedec is enought as the NOR flahses are detectable. - EEPROM: "atmel,24c32" is enought. - Use uppercase for regulator-name properties. - In pmic node: use the names from the PHYTEC SoM schematics. - stmpe811 touch: fix dts schema to comply with st,stmpe.yaml. - Fix one "multiple blank lines" detected by checkpatch. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phycore-stm32mp15: Disable optional SoM peripheralsChristophe Parant
Following peripherals are optional on phyCORE-STM32MP15x following PHYTEC standard SoM variants: external RTC, EEPROM, SPI NOR. Also NAND (fmc) can be populated instead of eMMC (sdmmc2). So disable those peripherals on SoM dtsi file and enable them on board dts file. Additionally, enable by default the "DTS" SoC IP on common SoM dtsi file as it is not an optional IP in STM32MP15x SoC. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-10-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phyboard-sargas: Move aliases from dts to dtsiChristophe Parant
aliases are common to every phyboard-sargas version. So move it to the common phyboard dtsi file. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-9-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phycore-stm32mp15: Add dummy memory-nodeChristophe Parant
"memory" node is not necessary as the bootloader is taking care of passing the correct DDR size. However keep a dummy memory node with the minimum DDR size (512MB) with comment explaining that. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-8-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phycore-stm32mp15: qspi: Fix memory map and pinctrlChristophe Parant
- Add missing chip select pin group in pinctrl. - Overwrite the memory map to the Flash device size (16MB) is necessary to avoid waste of virtual memory that will not be used. Without this modification, qspi probe fails because of ioremap error. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-7-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phyboard-sargas: Fix uart4 and sai2 pinctrlChristophe Parant
- UART4: "uart4_pins_a" pinmux option does not apply here, as PB9 should be used for UART4_TX instead of PG11 (PG11 is LCD_B3 on Sargas). Use "uart4_pins_f" instead. Also remove "pinctrl-3" which is useless (identical to "pinctrl-1"). - SAI2 A: "sai2a_pins_b" pinmux option does not apply here, as only PI6 is used for SAI2 A ("SAI2_SD_A"). Other pins of this group (PI7 and PD13) are not used for audio. Use "sai2a_sleep_pins_d" instead. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-6-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: Add new pinmux groups for phyboard-sargas and phycoreChristophe Parant
Add add alternate pinmux for following interfaces used on phyBOARD-Sargas: - UART4 - LTDC - DCMI - TIM5 - SAI2 Fix "ethernet0_rgmii_pins_d" pinmux used on phyCORE-STM32MP15x: ETH_RGMII_GTX_CLK pin was missing. Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-5-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phyboard-sargas: Introduce SoM device treeChristophe Parant
Add stm32mp15xx-phycore-som.dtsi device tree file to split hardware features between the phyBOARD (baseboard) and the phyCORE (SoM). Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-3-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06ARM: dts: stm32: phycore-stm32mp15: Rename device tree filesChristophe Parant
Rename "stm32mp157c-phycore-*" device tree for the following reasons: - The name of the dts should match to the phyBOARD name and not the name of the SoM ("phycore-stm32mp1-3" was initialy coming from the name of the yocto machine from meta-phytec). - PHYTEC manages different SoM configurations with different STM32MP15x SoC versions, so common dtsi files starting with "stm32mp15xx-*" should be used (as it is done for ST boards for example). - Add "-rdk" as suffix (for "Rapid Development Kit") to match our others phytec boards dts names (imx6, imx6ul,..). - "model" property is updated to introduce the name "phyBOARD-Sargas". Signed-off-by: Christophe Parant <c.parant@phytec.fr> Link: https://lore.kernel.org/r/20251210101611.27008-2-c.parant@phytec.fr Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-03-06RISC-V: KVM: Check host Ssaia extension when creating AIA irqchipAnup Patel
The KVM user-space may create KVM AIA irqchip before checking VCPU Ssaia extension availability so KVM AIA irqchip must fail when host does not have Ssaia extension. Fixes: 89d01306e34d ("RISC-V: KVM: Implement device interface for AIA irqchip") Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260120080013.2153519-4-anup.patel@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix error code returned for Ssaia ONE_REGAnup Patel
Return -ENOENT for Ssaia ONE_REG when Ssaia is not enabled for a VCPU. This will make Ssaia ONE_REG error codes consistent with other ONE_REG interfaces of KVM RISC-V. Fixes: 2a88f38cd58d ("RISC-V: KVM: return ENOENT in *_one_reg() when reg is unknown") Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260120080013.2153519-3-anup.patel@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix error code returned for Smstateen ONE_REGAnup Patel
Return -ENOENT for Smstateen ONE_REG when: 1) Smstateen is not enabled for a VCPU 2) ONE_REG id is out of range This will make Smstateen ONE_REG error codes consistent with other ONE_REG interfaces of KVM RISC-V. Fixes: c04913f2b54e ("RISCV: KVM: Add sstateen0 to ONE_REG") Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260120080013.2153519-2-anup.patel@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06KVM: riscv: Fix Spectre-v1 in PMU counter accessLukas Gerlach
Guest-controlled counter indices received via SBI ecalls are used to index into the PMC array. Sanitize them with array_index_nospec() to prevent speculative out-of-bounds access. Similar to x86 commit 13c5183a4e64 ("KVM: x86: Protect MSR-based index computations in pmu.h from Spectre-v1/L1TF attacks"). Fixes: 8f0153ecd3bf ("RISC-V: KVM: Add skeleton support for perf") Reviewed-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com> Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de> Link: https://lore.kernel.org/r/20260303-kvm-riscv-spectre-v1-v2-4-192caab8e0dc@cispa.de Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06KVM: riscv: Fix Spectre-v1 in floating-point register accessLukas Gerlach
User-controlled indices are used to index into floating-point registers. Sanitize them with array_index_nospec() to prevent speculative out-of-bounds access. Reviewed-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com> Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de> Link: https://lore.kernel.org/r/20260303-kvm-riscv-spectre-v1-v2-3-192caab8e0dc@cispa.de Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06KVM: riscv: Fix Spectre-v1 in AIA CSR accessLukas Gerlach
User-controlled indices are used to access AIA CSR registers. Sanitize them with array_index_nospec() to prevent speculative out-of-bounds access. Similar to x86 commit 8c86405f606c ("KVM: x86: Protect ioapic_read_indirect() from Spectre-v1/L1TF attacks") and arm64 commit 41b87599c743 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()"). Reviewed-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com> Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de> Link: https://lore.kernel.org/r/20260303-kvm-riscv-spectre-v1-v2-2-192caab8e0dc@cispa.de Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06KVM: riscv: Fix Spectre-v1 in ONE_REG register accessLukas Gerlach
User-controlled register indices from the ONE_REG ioctl are used to index into arrays of register values. Sanitize them with array_index_nospec() to prevent speculative out-of-bounds access. Reviewed-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com> Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de> Link: https://lore.kernel.org/r/20260303-kvm-riscv-spectre-v1-v2-1-192caab8e0dc@cispa.de Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Skip THP support check during dirty loggingWang Yechao
When dirty logging is enabled, guest stage mappings are forced to PAGE_SIZE granularity. Changing the mapping page size at this point is incorrect. Fixes: ed7ae7a34bea ("RISC-V: KVM: Transparent huge page support") Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260226191231140_X1Juus7s2kgVlc0ZyW_K@zte.com.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix potential UAF in kvm_riscv_aia_imsic_has_attr()Jiakai Xu
The KVM_DEV_RISCV_AIA_GRP_APLIC branch of aia_has_attr() was identified to have a race condition with concurrent KVM_SET_DEVICE_ATTR ioctls, leading to a use-after-free bug. Upon analyzing the code, it was discovered that the KVM_DEV_RISCV_AIA_GRP_IMSIC branch of aia_has_attr() suffers from the same lack of synchronization. It invokes kvm_riscv_aia_imsic_has_attr() without holding dev->kvm->lock. While aia_has_attr() is running, a concurrent aia_set_attr() could call aia_init() under the dev->kvm->lock. If aia_init() fails, it may trigger kvm_riscv_vcpu_aia_imsic_cleanup(), which frees imsic_state. Without proper locking, kvm_riscv_aia_imsic_has_attr() could attempt to access imsic_state while it is being deallocated. Although this specific path has not yet been reported by a fuzzer, it is logically identical to the APLIC issue. Fix this by acquiring the dev->kvm->lock before calling kvm_riscv_aia_imsic_has_attr(), ensuring consistency with the locking pattern used for other AIA attribute groups. Fixes: 5463091a51cf ("RISC-V: KVM: Expose IMSIC registers as attributes of AIA irqchip") Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260304080804.2281721-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix use-after-free in kvm_riscv_aia_aplic_has_attr()Jiakai Xu
Fuzzer reports a KASAN use-after-free bug triggered by a race between KVM_HAS_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls on the AIA device. The root cause is that aia_has_attr() invokes kvm_riscv_aia_aplic_has_attr() without holding dev->kvm->lock, while a concurrent aia_set_attr() may call aia_init() under that lock. When aia_init() fails after kvm_riscv_aia_aplic_init() has succeeded, it calls kvm_riscv_aia_aplic_cleanup() in its fail_cleanup_imsics path, which frees both aplic_state and aplic_state->irqs. The concurrent has_attr path can then dereference the freed aplic->irqs in aplic_read_pending(): irqd = &aplic->irqs[irq]; /* UAF here */ KASAN report: BUG: KASAN: slab-use-after-free in aplic_read_pending arch/riscv/kvm/aia_aplic.c:119 [inline] BUG: KASAN: slab-use-after-free in aplic_read_pending_word arch/riscv/kvm/aia_aplic.c:351 [inline] BUG: KASAN: slab-use-after-free in aplic_mmio_read_offset arch/riscv/kvm/aia_aplic.c:406 Read of size 8 at addr ff600000ba965d58 by task 9498 Call Trace: aplic_read_pending arch/riscv/kvm/aia_aplic.c:119 [inline] aplic_read_pending_word arch/riscv/kvm/aia_aplic.c:351 [inline] aplic_mmio_read_offset arch/riscv/kvm/aia_aplic.c:406 kvm_riscv_aia_aplic_has_attr arch/riscv/kvm/aia_aplic.c:566 aia_has_attr arch/riscv/kvm/aia_device.c:469 allocated by task 9473: kvm_riscv_aia_aplic_init arch/riscv/kvm/aia_aplic.c:583 aia_init arch/riscv/kvm/aia_device.c:248 [inline] aia_set_attr arch/riscv/kvm/aia_device.c:334 freed by task 9473: kvm_riscv_aia_aplic_cleanup arch/riscv/kvm/aia_aplic.c:644 aia_init arch/riscv/kvm/aia_device.c:292 [inline] aia_set_attr arch/riscv/kvm/aia_device.c:334 Fix this race by acquiring dev->kvm->lock in aia_has_attr() before calling kvm_riscv_aia_aplic_has_attr(), consistent with the locking pattern used in aia_get_attr() and aia_set_attr(). Fixes: 289a007b98b06d ("RISC-V: KVM: Expose APLIC registers as attributes of AIA irqchip") Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com> Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260302132703.1721415-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: fix off-by-one array access in SBI PMURadim Krčmář
The indexed array only has RISCV_KVM_MAX_COUNTERS elements. The out-of-bound access could have been performed by a guest, but it could only access another guest accessible data. Fixes: 8f0153ecd3bf ("RISC-V: KVM: Add skeleton support for perf") Signed-off-by: Radim Krčmář <radim.krcmar@oss.qualcomm.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260227134617.23378-1-radim.krcmar@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix null pointer dereference in kvm_riscv_vcpu_aia_rmw_topei()Jiakai Xu
kvm_riscv_vcpu_aia_rmw_topei() assumes that the per-vCPU IMSIC state has been initialized once AIA is reported as available and initialized at the VM level. This assumption does not always hold. Under fuzzed ioctl sequences, a guest may access the IMSIC TOPEI CSR before the vCPU IMSIC state is set up. In this case, vcpu->arch.aia_context.imsic_state is still NULL, and the TOPEI RMW path dereferences it unconditionally, leading to a host kernel crash. The crash manifests as: Unable to handle kernel paging request at virtual address dfffffff0000000e ... kvm_riscv_vcpu_aia_imsic_rmw arch/riscv/kvm/aia_imsic.c:909 kvm_riscv_vcpu_aia_rmw_topei arch/riscv/kvm/aia.c:231 csr_insn arch/riscv/kvm/vcpu_insn.c:208 system_opcode_insn arch/riscv/kvm/vcpu_insn.c:281 kvm_riscv_vcpu_virtual_insn arch/riscv/kvm/vcpu_insn.c:355 kvm_riscv_vcpu_exit arch/riscv/kvm/vcpu_exit.c:230 kvm_arch_vcpu_ioctl_run arch/riscv/kvm/vcpu.c:1008 ... Fix this by explicitly checking whether the vCPU IMSIC state has been initialized before handling TOPEI CSR accesses. If not, forward the CSR emulation to user space. Fixes: db8b7e97d6137 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC") Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260226085119.643295-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06RISC-V: KVM: Fix use-after-free in kvm_riscv_gstage_get_leaf()Jiakai Xu
While fuzzing KVM on RISC-V, a use-after-free was observed in kvm_riscv_gstage_get_leaf(), where ptep_get() dereferences a freed gstage page table page during gfn unmap. The crash manifests as: use-after-free in ptep_get include/linux/pgtable.h:340 [inline] use-after-free in kvm_riscv_gstage_get_leaf arch/riscv/kvm/gstage.c:89 Call Trace: ptep_get include/linux/pgtable.h:340 [inline] kvm_riscv_gstage_get_leaf+0x2ea/0x358 arch/riscv/kvm/gstage.c:89 kvm_riscv_gstage_unmap_range+0xf0/0x308 arch/riscv/kvm/gstage.c:265 kvm_unmap_gfn_range+0x168/0x1fc arch/riscv/kvm/mmu.c:256 kvm_mmu_unmap_gfn_range virt/kvm/kvm_main.c:724 [inline] page last free pid 808 tgid 808 stack trace: kvm_riscv_mmu_free_pgd+0x1b6/0x26a arch/riscv/kvm/mmu.c:457 kvm_arch_flush_shadow_all+0x1a/0x24 arch/riscv/kvm/mmu.c:134 kvm_flush_shadow_all virt/kvm/kvm_main.c:344 [inline] The UAF is caused by gstage page table walks running concurrently with gstage pgd teardown. In particular, kvm_unmap_gfn_range() can traverse gstage page tables while kvm_arch_flush_shadow_all() frees the pgd, leading to use-after-free of page table pages. Fix the issue by serializing gstage unmap and pgd teardown with kvm->mmu_lock. Holding mmu_lock ensures that gstage page tables remain valid for the duration of unmap operations and prevents concurrent frees. This matches existing RISC-V KVM usage of mmu_lock to protect gstage map/unmap operations, e.g. kvm_riscv_mmu_iounmap. Fixes: dd82e35638d67f ("RISC-V: KVM: Factor-out g-stage page table management") Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260202040059.1801167-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06KVM: riscv: Fix Spectre-v1 in APLIC interrupt handlingLukas Gerlach
Guests can control IRQ indices via MMIO. Sanitize them with array_index_nospec() to prevent speculative out-of-bounds access to the aplic->irqs[] array. Similar to arm64 commit 41b87599c743 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()") and x86 commit 8c86405f606c ("KVM: x86: Protect ioapic_read_indirect() from Spectre-v1/L1TF attacks"). Fixes: 74967aa208e2 ("RISC-V: KVM: Add in-kernel emulation of AIA APLIC") Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260116095731.24555-1-lukas.gerlach@cispa.de Signed-off-by: Anup Patel <anup@brainfault.org>
2026-03-06x86/mm/tlb: Make enter_lazy_tlb() always inline on x86Xie Yuanbin
enter_lazy_tlb() on x86 is short enough, and is called in context switching, which is the hot code path. Make enter_lazy_tlb() always inline on x86 to optimize performance. Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Xie Yuanbin <qq570070308@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20260216164950.147617-2-qq570070308@gmail.com
2026-03-05arm: multi_v7_defconfig: Enable more OMAP 3/4 related configsAndreas Kemnade
Enable drivers commonly used for these boards. - CONFIG_*TWL*: PMIC mostly used on these devices so enable all functions. Especially charging is required to avoid having battery drained. - missing SoC functions (watchdog, thermal, sound) - TI WiLink chipset support to provide WLAN for - GTA04A5, Pandaboards, OpenPandora, Moverio BT200 - HCILL to provide Bluetooth on boards with TI WiLink combo chips - TCA6507 LEDs: some are used as GPIO os GTA04A4 to provide Power. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/20260220184336.616623-1-andreas@kemnade.info Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2026-03-05ARM: omap2: Replace scnprintf with strscpy in omap3_cpuinfoThorsten Blum
Replace scnprintf("%s", ...) with the faster and more direct strscpy(). Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20260224144552.585272-1-thorsten.blum@linux.dev Signed-off-by: Kevin Hilman <khilman@baylibre.com>