summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-03-06ARM: shmobile: defconfig: Refresh for v7.0-rc1Geert Uytterhoeven1-6/+5
Refresh the defconfig for Renesas ARM systems: - Move various DRM config symbols (moved in commit 22ba3bb3ff2a8e5a ("drm/Kconfig: sort driver Kconfig source list")), - Drop CONFIG_NFS_V4_1=y (removed in commit 7537db24806fdc3d ("NFS: Merge CONFIG_NFS_V4_1 with CONFIG_NFS_V4")). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/d5faca8fe1db69d584f3097c269be7813ceffd33.1772449420.git.geert+renesas@glider.be
2026-03-06arm64: dts: renesas: r9a09g087: Wire up DMA support for SPICosmin Tanislav1-0/+16
RZ/N2H (R9A09G087) has three DMA controllers that can be used by peripherals like SPI to offload data transfers from the CPU. Wire up the DMA channels for the SPI peripherals. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260128215132.1353381-4-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g077: Wire up DMA support for SPICosmin Tanislav1-0/+16
RZ/T2H (R9A09G077) has three DMA controllers that can be used by peripherals like SPI to offload data transfers from the CPU. Wire up the DMA channels for the SPI peripherals. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260128215132.1353381-3-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable RTCOvidiu Panait1-0/+4
Enable RTC. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260125192706.27099-6-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r9a09g056: Add RTC nodeOvidiu Panait1-0/+15
Add RTC node to Renesas RZ/V2N ("R9A09G056") 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/20260125192706.27099-5-ovidiu.panait.rb@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generatorMarek Vasut1-1/+42
Describe the 9FGV0841 PCIe and USB3.0 clock generator present on Ebisu board. The clock generator supplies 100 MHz differential clock for both PCIe slot and BT/WLAN expansion port, as well as for the USB 3.0 PHY. This configuration is valid for SW49 in OFF position, which means the PCIe signals are routed to the PCIe slot and U11 9FGV0841 PCIe clock generator output 3 supplies clock to the PCIe slot. In case the SW49 is set to ON position, which means the PCIe signals are routed to the EX BT/WLAN expansion port, and U11 9FGV0841 PCIe clock generator output 4 supplies clock to the port and &pciec0_rp clocks should be changed to "clocks = <&pcie_usb_clk 4>;". Once the BT/WLAN port is tested, this can be implemented using a DTO. Until then, assume SW49 is set to OFF position. 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-10-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generatorMarek Vasut2-1/+33
Describe the 9FGV0841 PCIe and USB3.0 clock generator present on ULCB boards. The clock generator supplies 100 MHz differential clock for both PCIe ports, the USB 3.0 PHY and SATA. SATA is not yet described in the ULCB DT, therefore the connection to this clock generator is not described here either. The H3 ULCB schematic does describe connection from output DIF7 to USB3S1_CLK_*, but these signals do not exist on the SoC, therefore this connection is also not described. 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-9-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: salvator-common: Describe PCIe/USB3.0 clock generatorMarek Vasut1-2/+26
Describe the 9FGV0841 PCIe and USB3.0 clock generator present on both Salvator-X and Salvator-XS boards. The clock generator supplies 100 MHz differential clock for both PCIe ports, as well as for the USB 3.0 PHY. 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-8-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a77990: Add USB 3.0 PHY and USB3S0 clock nodesMarek Vasut1-0/+17
Add USB 3.0 PHY and PHY clock node for R-Car E3. The PHY node is different in that it does not have control registers and extal clock, which are not routed to the SoC pads on R-Car E3, therefore describe the PHY as usb-nop-xceiv simple PHY. Add USB3S0 clock pad fixed-clock node, the frequency has to be overridden at board level. 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-7-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a77990: Describe PCIe root portMarek Vasut1-0/+10
Add node which describes the root port in the PCIe controller DT node. 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-6-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-06arm64: dts: renesas: r8a77965: Describe PCIe root portsMarek Vasut1-0/+20
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 Vasut1-0/+20
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 Vasut1-0/+20
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 Vasut1-0/+20
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)1-0/+35
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 Vasut1-0/+5
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 Uytterhoeven1-8/+8
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 Beznea1-1/+1
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 Prabhakar1-2/+2
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 Prabhakar1-2/+2
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 Castro1-30/+0
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 Prabhakar1-0/+1
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 Prabhakar1-0/+1
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 Imbrenda1-2/+4
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 Jaroszynski1-4/+49
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)1-2/+0
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 Tabba1-0/+1
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 Hsu1-1/+1
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 Deller1-1/+6
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 Deller1-8/+12
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 Deller1-1/+1
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 Volmat1-0/+15
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 Volmat1-0/+8
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 Parant2-0/+39
- 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 Parant3-38/+33
- 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 Parant2-9/+8
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 Parant2-9/+9
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 Parant1-0/+9
"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 Parant1-2/+8
- 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 Parant1-6/+5
- 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 Parant1-0/+164
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 Parant3-317/+331
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 Parant3-6/+3
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 Patel1-0/+4
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 Patel1-0/+4
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 Patel1-10/+8
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 Gerlach1-3/+11
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 Gerlach1-4/+13
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 Gerlach1-2/+9
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 Gerlach1-8/+28
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>
generated by cgit (git 2.54.0.dirty) at 2026-10-01 01:53:02 +0000