summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-03-18arm64: dts: qcom: remove msm8996-v3.0.dtsiBartosz Golaszewski1-63/+0
This file is not used anywhere. Remove it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Closes: https://lore.kernel.org/all/20251212203226.458694-3-robh@kernel.org/ Link: https://lore.kernel.org/r/20260206134506.72679-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: ipq9574: Enable eMMC variantVaradarajan Narayanan3-2/+42
RDP433/RDP418 can have NAND or eMMC based on a board level rework. Since the same GPIOS are used for both the interfaces, only one of them can be used. Add a new DTS file to enable eMMC. Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260205085936.3220108-5-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: ipq9574-rdp433: Reorganize DTS to introduce eMMC supportVaradarajan Narayanan2-115/+122
The RDP433 has NAND and eMMC variants. Presently, only NAND variant is supported. To enable support for eMMC variant, move the common nodes from ipq9574-rdp433.dts to ipq9574-rdp433-common.dtsi. ipq9574-rdp433-common.dtsi will be included in rdp433 NAND and eMMC DT files. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260205085936.3220108-3-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: ipq9574: Add details for eMMCVaradarajan Narayanan7-45/+72
RDP433 and RDP418 has NAND and eMMC variants. Presently, only NAND variant is supported. To enable support for eMMC variant, add the relevant GPIO and regulator information. Do not enable NAND or eMMC by default in ipq9574-rdp-common.dtsi. Enable it in board specific DTS as applicable. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260205085936.3220108-2-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: qcs8300: Add clocks for QoS configurationOdelu Kukatla1-0/+6
Add clocks which need to be enabled for configuring QoS on qcs8300 SoC. Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260127090116.1438780-4-odelu.kukatla@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: msm8953-xiaomi-daisy: fix backlightBarnabás Czémán1-1/+1
The backlight on this device is connected via 3 strings. Currently, the DT claims only two are present, which results in visible stripes on the display (since every third backlight string remains unconfigured). Fix the number of strings to avoid that. Fixes: 38d779c26395 ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Mi A2 Lite") Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-7-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: msm8937-xiaomi-land: correct wled ovp valueBarnabás Czémán1-1/+1
PMI8950 doesn't actually support setting an OVP threshold value of 29.6 V. The closest allowed value is 29.5 V. Set that instead. Fixes: 2144f6d57d8e ("arm64: dts: qcom: Add Xiaomi Redmi 3S") Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-6-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp valueBarnabás Czémán1-1/+1
PMI8950 doesn't actually support setting an OVP threshold value of 29.6 V. The closest allowed value is 29.5 V. Set that instead. Fixes: aa17e707e04a ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Redmi 5 Plus") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Link: https://lore.kernel.org/r/20260116-pmi8950-wled-v3-5-e6c93de84079@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: sm8550: Update EAS propertiesXilin Wu1-16/+16
The original values provided by Qualcomm appear to be quite inaccurate. Specifically, some heavy gaming tasks could be improperly assigned to the A510 cores by the scheduler, resulting in a CPU bottleneck. This update to the EAS properties aims to enhance the user experience across various scenarios. The power numbers were obtained using a Type-C power meter, which was directly connected to the battery connector on the AYN Odin 2 motherboard, acting as a fake battery. It should be noted that the A715 cores seem less efficient than the A710 cores. Therefore, an average value has been assigned to them, considering that the A715 and A710 cores share a single cpufreq domain. Cortex-A510 cores: 441 kHz, 564 mV, 43 mW, 350 Cx 556 kHz, 580 mV, 59 mW, 346 Cx 672 kHz, 592 mV, 71 mW, 312 Cx 787 kHz, 604 mV, 83 mW, 290 Cx 902 kHz, 608 mV, 96 mW, 288 Cx 1017 kHz, 624 mV, 107 mW, 264 Cx 1113 kHz, 636 mV, 117 mW, 252 Cx 1228 kHz, 652 mV, 130 mW, 240 Cx 1344 kHz, 668 mV, 146 mW, 235 Cx 1459 kHz, 688 mV, 155 mW, 214 Cx 1555 kHz, 704 mV, 166 mW, 205 Cx 1670 kHz, 724 mV, 178 mW, 192 Cx 1785 kHz, 744 mV, 197 mW, 189 Cx 1900 kHz, 764 mV, 221 mW, 190 Cx 2016 kHz, 784 mV, 243 mW, 188 Cx Your dynamic-power-coefficient for cpu 1: 251 Cortex-A715 cores: 614 kHz, 572 mV, 97 mW, 470 Cx 729 kHz, 592 mV, 123 mW, 473 Cx 844 kHz, 608 mV, 152 mW, 486 Cx 940 kHz, 624 mV, 178 mW, 485 Cx 1056 kHz, 644 mV, 207 mW, 465 Cx 1171 kHz, 656 mV, 243 mW, 480 Cx 1286 kHz, 672 mV, 271 mW, 459 Cx 1401 kHz, 692 mV, 310 mW, 454 Cx 1536 kHz, 716 mV, 368 mW, 462 Cx 1651 kHz, 740 mV, 416 mW, 454 Cx 1785 kHz, 760 mV, 492 mW, 475 Cx 1920 kHz, 784 mV, 544 mW, 457 Cx 2054 kHz, 804 mV, 613 mW, 458 Cx 2188 kHz, 828 mV, 702 mW, 465 Cx 2323 kHz, 852 mV, 782 mW, 461 Cx 2457 kHz, 876 mV, 895 mW, 473 Cx 2592 kHz, 896 mV, 1020 mW, 490 Cx 2707 kHz, 920 mV, 1140 mW, 498 Cx 2803 kHz, 940 mV, 1215 mW, 490 Cx Your dynamic-power-coefficient for cpu 3: 472 Cortex-A710 cores: 614 kHz, 572 mV, 91 mW, 388 Cx 729 kHz, 592 mV, 116 mW, 424 Cx 844 kHz, 608 mV, 143 mW, 443 Cx 940 kHz, 624 mV, 165 mW, 434 Cx 1056 kHz, 644 mV, 195 mW, 430 Cx 1171 kHz, 656 mV, 218 mW, 414 Cx 1286 kHz, 672 mV, 250 mW, 415 Cx 1401 kHz, 692 mV, 286 mW, 412 Cx 1536 kHz, 716 mV, 331 mW, 407 Cx 1651 kHz, 740 mV, 374 mW, 401 Cx 1785 kHz, 760 mV, 439 mW, 417 Cx 1920 kHz, 784 mV, 495 mW, 411 Cx 2054 kHz, 804 mV, 557 mW, 412 Cx 2188 kHz, 828 mV, 632 mW, 415 Cx 2323 kHz, 852 mV, 721 mW, 422 Cx 2457 kHz, 876 mV, 813 mW, 427 Cx 2592 kHz, 896 mV, 912 mW, 435 Cx 2707 kHz, 920 mV, 1019 mW, 442 Cx 2803 kHz, 940 mV, 1087 mW, 436 Cx Your dynamic-power-coefficient for cpu 5: 421 Cortex-X3 core: 729 kHz, 568 mV, 252 mW, 1110 Cx 864 kHz, 580 mV, 312 mW, 1097 Cx 998 kHz, 592 mV, 379 mW, 1109 Cx 1132 kHz, 608 mV, 453 mW, 1099 Cx 1248 kHz, 624 mV, 517 mW, 1067 Cx 1363 kHz, 636 mV, 587 mW, 1067 Cx 1478 kHz, 648 mV, 657 mW, 1058 Cx 1593 kHz, 664 mV, 739 mW, 1049 Cx 1708 kHz, 680 mV, 813 mW, 1020 Cx 1843 kHz, 704 mV, 940 mW, 1021 Cx 1977 kHz, 724 mV, 1054 mW, 1007 Cx 2092 kHz, 740 mV, 1201 mW, 1045 Cx 2227 kHz, 768 mV, 1358 mW, 1029 Cx 2342 kHz, 788 mV, 1486 mW, 1016 Cx 2476 kHz, 812 mV, 1711 mW, 1046 Cx 2592 kHz, 836 mV, 1846 mW, 1014 Cx 2726 kHz, 856 mV, 2046 mW, 1020 Cx 2841 kHz, 880 mV, 2266 mW, 1027 Cx 2956 kHz, 908 mV, 2616 mW, 1074 Cx 3187 kHz, 956 mV, 3326 mW, 1147 Cx Your dynamic-power-coefficient for cpu 7: 1057 7-zip benchmark single-core MIPS: 2128 4416 4632 6686 Signed-off-by: Xilin Wu <wuxilin123@gmail.com> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20260128-sm8550-eas-v1-1-fb80615bed5c@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: dts: qcom: hamoa: Add remoteproc IOMMUS in EL2 device treesXin Liu1-0/+8
All the existing variants Hamoa boards are using Gunyah hypervisor which means that, so far, Linux-based OS could only boot in EL1 on those devices. However, it is possible for us to boot Linux at EL2 on these devices [1]. When running under Gunyah, the remote processor firmware IOMMU streams are controlled by Gunyah. However, without Gunyah, the IOMMU is managed by the consumer of this DeviceTree. Therefore, describe the firmware streams for each remote processor. Add remoteproc IOMMUS to the EL2 device trees to generate the corresponding -el2.dtb files. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260203063244.1498699-1-xin.liu@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-18arm64: Kconfig: provide a top-level switch for Microchip platformsBartosz Golaszewski2-6/+5
Microchip is the only platform that doesn't have a top-level switch for disabling all SoC families. Align it with other platforms and update the arm64 defconfig to keep the default config the same. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260226143615.65788-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2026-03-18objtool/x86: Reorder ORC register numberingJosh Poimboeuf2-17/+23
Reorder the ORC register values so their ordering matches the x86 instruction set register encodings. No functional change intended. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2026-03-18objtool: Support Clang RAX DRAP sequenceJosh Poimboeuf2-0/+9
Recent Clang can use RAX as a temporary register for the DRAP stack alignment sequence. Add support for that. Fixes the following warning: vmlinux.o: error: objtool: vmw_host_printf+0xd: unknown CFA base reg 0 Closes: https://lore.kernel.org/cefefdd1-7b82-406d-8ff4-e4b167e45ee6@app.fastmail.com Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/3f33dc720b83dc6d3a2b7094f75a5c90a0b1cbc5.1773708458.git.jpoimboe@kernel.org
2026-03-18arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85VSebastian Krzyszkowiak1-1/+1
The minimal voltage of VDD_SOC sourced from BUCK1 is 0.81V, which is the currently set value. However, BD71837 only guarantees accuracy of ±0.01V, and this still doesn't factor other reasons for actual voltage to slightly drop in, resulting in the possibility of running out of the operational range. Bump the voltage up to 0.85V, which should give enough headroom. Cc: stable@vger.kernel.org Fixes: 8f0216b006e5 ("arm64: dts: Add a device tree for the Librem 5 phone") Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-18Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower"Sebastian Krzyszkowiak2-17/+7
This reverts commit c24a9b698fb02cd0723fa8375abab07f94b97b10. It's been found that there's a significant per-unit variance in accepted supply voltages and the current set still makes some units unstable. Revert back to nominal values. Cc: stable@vger.kernel.org Fixes: c24a9b698fb0 ("arm64: dts: imx8mq-librem5: Set the DVS voltages lower") Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-18Revert "ARM: dts: imx: move nand related property under nand@0"Max Krummenacher15-82/+22
This reverts commit 8124b4a4a96b57d6cc3705a9df9623c52baa047b. The change introduced a regression: at least Colibri iMX6ULL and Colibri iMX7 no longer boot with that commit applied, while they boot again after reverting it. Although this has only been verified on these two modules, the issue is expected to affect all device trees using the gpmi-nand driver. [ 0.876938] Creating 5 MTD partitions on "gpmi-nand": [ 0.876974] 0x000000000000-0x000000080000 : "mx7-bcb" [ 0.879860] 0x000000080000-0x000000200000 : "u-boot1" [ 0.884761] 0x000000200000-0x000000380000 : "u-boot2" [ 0.886993] 0x000000380000-0x000000400000 : "u-boot-env" [ 0.894686] 0x000000400000-0x000020000000 : "ubi" [ 0.899054] gpmi-nand 33002000.nand-controller: driver registered. ... [ 0.960443] ubi0: default fastmap pool size: 200 [ 0.960476] ubi0: default fastmap WL pool size: 100 [ 0.960500] ubi0: attaching mtd4 [ 1.636355] ubi0 error: scan_peb: bad image sequence number 1588722158 in PEB 4060, expected 1574791632 ... [ 1.649889] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd4, error -22 [ 1.650029] UBI error: cannot attach mtd4 ... [ 1.670262] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,253) Fixes: 8124b4a4a96b ("ARM: dts: imx: move nand related property under nand@0") Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-17sh: platform_early: remove pdev->driver_override checkDanilo Krummrich1-4/+0
In commit 507fd01d5333 ("drivers: move the early platform device support to arch/sh") platform_match() was copied over to the sh platform_early code, accidentally including the driver_override check. This check does not make sense for platform_early, as sysfs is not even available in first place at this point in the boot process, hence remove the check. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Fixes: 507fd01d5333 ("drivers: move the early platform device support to arch/sh") Link: https://lore.kernel.org/all/DH4M3DJ4P58T.1BGVAVXN71Z09@kernel.org/ Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17KVM: arm64: Fix the descriptor address in __kvm_at_swap_desc()Zenghui Yu (Huawei)1-1/+1
Using "(u64 __user *)hva + offset" to get the virtual addresses of S1/S2 descriptors looks really wrong, if offset is not zero. What we want to get for swapping is hva + offset, not hva + offset*8. ;-) Fix it. Fixes: f6927b41d573 ("KVM: arm64: Add helper for swapping guest descriptor") Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260317115748.47332-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2026-03-17genirq/matrix, LoongArch: Delete IRQ_MATRIX_BITS leftoversNam Cao1-1/+0
Delete IRQ_MATRIX_BITS leftovers after commit 5b98d210ac1e ("genirq/matrix: Dynamic bitmap allocation") has made IRQ_MATRIX_BITS obsolete. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260316072850.467995-1-namcao@linutronix.de
2026-03-17KVM: arm64: avoid unused-variable warningArnd Bergmann1-3/+2
The 'cpu' variable is only used inside of an #ifdef block and causes a warning if there is no user: arch/arm64/kvm/hyp_trace.c: In function 'kvm_hyp_trace_init': arch/arm64/kvm/hyp_trace.c:422:13: error: unused variable 'cpu' [-Werror=unused-variable] 422 | int cpu; | ^~~ Change the #ifdef to an equivalent IS_ENABLED() check to avoid the warning. Fixes: b22888917fa4 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260313094925.3749287-1-arnd@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-17Merge tag 'renesas-dts-for-v7.1-tag1' of ↵Krzysztof Kozlowski22-53/+505
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DTS updates for v7.1 - Add CPU frequency scaling and QSPI NOR FLASH support on the RZ/N1 SoC and the RZN1D-DB development board, - Add PCIe slot power control on the R-Car H3, M3-W(+), M3-N, and E3 SoCs, - Add USB3.0 PHY support on the R-Car E3 SoC and the Ebisu development board, - Add PCIe/USB3.0 clock generator support on the Salvator-X(S), ULCB King Fisher extension, and Ebisu development boards, - Add RTC support on the RZ/V2N SoC and its EVK board, - Add SPI DMA support on the RZ/T2H, RZ/N2H, RZ/V2H(P), and RZ/V2N SoCs, - Add support for the second SDHI channel on the Atmark Techno Armadillo-800-EVA board, - Miscellaneous fixes and improvements. * tag 'renesas-dts-for-v7.1-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (30 commits) ARM: dts: renesas: armadillo800eva: Add wakeup-source to st1232 ARM: dts: renesas: armadillo800eva: Enable SDHI1 ARM: dts: renesas: r9a06g032-rzn1d400-db: Use interrupts for Micrel PHYs ARM: dts: renesas: r9a06g032-rzn1d400-db: Do not use underscores in node names ARM: dts: renesas: r9a06g032-rzn1d400-db: Add QSPI node including NOR flash arm64: dts: renesas: r9a09g057: Add DMA support for RSPI channels arm64: dts: renesas: r9a09g056: Add DMA support for RSPI channels ARM: dts: renesas: r9a06g032: Describe the QSPI controller arm64: dts: renesas: r9a09g087: Wire up DMA support for SPI arm64: dts: renesas: r9a09g077: Wire up DMA support for SPI arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable RTC arm64: dts: renesas: r9a09g056: Add RTC node arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generator arm64: dts: renesas: salvator-common: Describe PCIe/USB3.0 clock generator arm64: dts: renesas: r8a77990: Add USB 3.0 PHY and USB3S0 clock nodes arm64: dts: renesas: r8a77990: Describe PCIe root port arm64: dts: renesas: r8a77965: Describe PCIe root ports arm64: dts: renesas: r8a77961: Describe PCIe root ports arm64: dts: renesas: r8a77960: Describe PCIe root ports ... Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-17powerpc: Print MMU_FTRS_POSSIBLE & MMU_FTRS_ALWAYS at startupRitesh Harjani (IBM)1-0/+4
Similar to CPU_FTRS_[POSSIBLE|ALWAYS], let's also print MMU_FTRS_[POSSIBLE|ALWAYS]. This has some useful data to capture during bootup. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/c37a9f314a723048d25aa5424f7ede8eec691d86.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Make use of H_RPTI_TYPE_ALL macroRitesh Harjani (IBM)1-6/+3
Instead of opencoding, let's use the pre-defined macro (H_RPTI_TYPE_ALL) at the following places. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/d1d32404d5f0d3e93cd0faad2298b7bfed31288f.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Rename tlbie_lpid_va to tlbie_va_lpidRitesh Harjani (IBM)1-9/+9
In previous patch we renamed tlbie_va_lpid functions to tlbie_va_pid_lpid() since those were working with PIDs as well. This then allows us to rename tlbie_lpid_va to tlbie_va_lpid, which finally makes all the tlbie function naming consistent. No functional change in this patch. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/8fadd2beb2f883c65ba0d797c87d238098cd13c8.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Rename tlbie_va_lpid to tlbie_va_pid_lpidRitesh Harjani (IBM)1-10/+10
It only make sense to rename these functions, so it's better reflect what they are supposed to do. For e.g. __tlbie_va_pid_lpid name better reflect that it is invalidating tlbie using VA, PID and LPID. No functional change in this patch. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/0a0b2cf23b9522f891f9a0f976bbdc5c8e6f6d8b.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Kill the unused argument of exit_lazy_flush_tlbRitesh Harjani (IBM)3-13/+5
In previous patch we removed the only caller of exit_lazy_flush_tlb() which was passing always_flush = false in it's second argument. With that gone, all the callers of exit_lazy_flush_tlb() are local to radix_pgtable.c and there is no need of an additional argument. This patch does the required cleanup. There should not be any functionality change in this patch. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/6f96ea53588034312ae84f74b1e2fa9c4ce7cfd5.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Move serialize_against_pte_lookup() to hash_pgtable.cRitesh Harjani (IBM)3-26/+21
Originally, commit fa4531f753f1 ("powerpc/mm: Don't send IPI to all cpus on THP updates") introduced serialize_against_pte_lookup() call for both Radix and Hash. However below commit fixed the race with Radix commit 70cbc3cc78a9 ("mm: gup: fix the fast GUP race against THP collapse") And therefore following commit removed the serialize_against_pte_lookup() call from radix_pgtable.c commit bedf03416913 ("powerpc/64s/radix: don't need to broadcast IPI for radix pmd collapse flush") Now since serialize_against_pte_lookup() only gets called from hash__pmdp_collapse_flush(), thus move the related functions to hash_pgtable.c Hence this patch: - moves serialize_against_pte_lookup() from radix_pgtable.c to hash_pgtable.c - removes the radix specific calls from do_serialize() - renames do_serialize() to do_nothing(). There should not be any functionality change in this patch. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/a73ebe800a9be257329507703779f822363f8b2f.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s/tlbflush-radix: Remove unused radix__flush_tlb_pwc()Ritesh Harjani (IBM)1-1/+0
Commit 52162ec784fa ("powerpc/mm/book3s64/radix: Use freed_tables instead of need_flush_all") removed radix__flush_tlb_pwc() definition, but missed to remove the extern declaration. This patch removes it. Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/b79c8ce8f00aa3e96ab9b1c77bc004759c397d3f.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Fix _HPAGE_CHG_MASK to include _PAGE_SPECIAL bitRitesh Harjani (IBM)1-2/+2
commit af38538801c6a ("mm/memory: factor out common code from vm_normal_page_*()"), added a VM_WARN_ON_ONCE for huge zero pfn. This can lead to the following call stack. ------------[ cut here ]------------ WARNING: mm/memory.c:735 at vm_normal_page_pmd+0xf0/0x140, CPU#19: hmm-tests/3366 NIP [c00000000078d0c0] vm_normal_page_pmd+0xf0/0x140 LR [c00000000078d060] vm_normal_page_pmd+0x90/0x140 Call Trace: [c00000016f56f850] [c00000000078d060] vm_normal_page_pmd+0x90/0x140 (unreliable) [c00000016f56f8a0] [c0000000008a9e30] change_huge_pmd+0x7c0/0x870 [c00000016f56f930] [c0000000007b2bc4] change_protection+0x17a4/0x1e10 [c00000016f56fba0] [c0000000007b3440] mprotect_fixup+0x210/0x4c0 [c00000016f56fc30] [c0000000007b3c3c] do_mprotect_pkey+0x54c/0x780 [c00000016f56fdb0] [c0000000007b3ed8] sys_mprotect+0x68/0x90 [c00000016f56fdf0] [c00000000003ae40] system_call_exception+0x190/0x500 [c00000016f56fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec This happens when we call mprotect -> change_huge_pmd() mprotect() change_pmd_range() pmd_modify(oldpmd, newprot) # this clears _PAGE_SPECIAL for zero huge pmd pmdv = pmd_val(pmd); pmdv &= _HPAGE_CHG_MASK; # -> gets cleared here return pmd_set_protbits(__pmd(pmdv), newprot); can_change_pmd_writable(vma, vmf->address, pmd) vm_normal_page_pmd(vma, addr, pmd) __vm_normal_page() VM_WARN_ON(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); # this get hits as _PAGE_SPECIAL for zero huge pmd was cleared. It can be easily reproduced with the following testcase: p = mmap(NULL, 2 * hpage_pmd_size, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); madvise((void *)p, 2 * hpage_pmd_size, MADV_HUGEPAGE); aligned = (char*)(((unsigned long)p + hpage_pmd_size - 1) & ~(hpage_pmd_size - 1)); (void)(*(volatile char*)aligned); // read fault, installs huge zero PMD mprotect((void *)aligned, hpage_pmd_size, PROT_READ | PROT_WRITE); This patch adds _PAGE_SPECIAL to _HPAGE_CHG_MASK similar to _PAGE_CHG_MASK, as we don't want to clear this bit when calling pmd_modify() while changing protection bits. Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/7416f5cdbcfeaad947860fcac488b483f1287172.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/64s: Fix unmap race with PMD migration entriesRitesh Harjani (IBM)2-4/+24
The following race is possible with migration swap entries or device-private THP entries. e.g. when move_pages is called on a PMD THP page, then there maybe an intermediate state, where PMD entry acts as a migration swap entry (pmd_present() is true). Then if an munmap happens at the same time, then this VM_BUG_ON() can happen in pmdp_huge_get_and_clear_full(). This patch fixes that. Thread A: move_pages() syscall add_folio_for_migration() mmap_read_lock(mm) folio_isolate_lru(folio) mmap_read_unlock(mm) do_move_pages_to_node() migrate_pages() try_to_migrate_one() spin_lock(ptl) set_pmd_migration_entry() pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn set_pmd_at() # PMD: migration swap entry (pmd_present=0) spin_unlock(ptl) [page copy phase] # <--- RACE WINDOW --> Thread B: munmap() mmap_write_downgrade(mm) unmap_vmas() -> zap_pmd_range() zap_huge_pmd() __pmd_trans_huge_lock() pmd_is_huge(): # !pmd_present && !pmd_none -> TRUE (swap entry) pmd_lock() -> # spin_lock(ptl), waits for Thread A to release ptl pmdp_huge_get_and_clear_full() VM_BUG_ON(!pmd_present(*pmdp)) # HITS! [ 287.738700][ T1867] ------------[ cut here ]------------ [ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187! cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0] pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c lr: c000000000645dec: zap_huge_pmd+0xb0/0x868 sp: c00000044037f790 msr: 800000000282b033 current = 0xc0000004032c1a00 paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09 pid = 1867, comm = a.out kernel BUG at :187! Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026 enter ? for help [link register ] c000000000645dec zap_huge_pmd+0xb0/0x868 [c00000044037f790] c00000044037f7d0 (unreliable) [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8 [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c SP (7fff9b1ee9c0) is in userspace 0:mon> zh commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"), enabled migration for device-private PMD entries. Hence this is one other path where this warning could get trigger from. ------------[ cut here ]------------ WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905 Modules linked in: test_hmm CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 Call Trace: [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable) [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c000000604707760] [c00000000063e5a4] migrate_vma_collect_pmd+0x12e8/0x16c4 [c000000604707890] [c00000000059282c] walk_pgd_range+0x7fc/0xd2c [c000000604707990] [c000000000592e40] __walk_page_range+0xe4/0x2ac [c000000604707a10] [c000000000593534] walk_page_range_mm_unsafe+0x204/0x2a4 [c000000604707ab0] [c00000000063af10] migrate_vma_setup+0x1dc/0x2e8 [c000000604707b10] [c008000006a21838] dmirror_migrate_to_system.constprop.0+0x210/0x4b0 [test_hmm] [c000000604707c30] [c008000006a245b0] dmirror_fops_unlocked_ioctl+0x454/0xa5c [test_hmm] [c000000604707d20] [c0000000006aab84] sys_ioctl+0x4ec/0x1178 [c000000604707e10] [c0000000000326a8] system_call_exception+0x128/0x350 [c000000604707e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fffbe44f50c Fixes: 75358ea359e7c ("powerpc/mm/book3s64: Fix MADV_DONTNEED and parallel page fault race") Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages") Reported-by: Pavithra Prakash <pavrampu@linux.vnet.ibm.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/9437e5ef28d1e2f5cbdd7f8286350ce93c1d43c5.1773078178.git.ritesh.list@gmail.com
2026-03-17powerpc/pgtable-frag: Fix bad page state in pte_frag_destroyRitesh Harjani (IBM)1-0/+1
powerpc uses pt_frag_refcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page. Patch series [1] "mm: free retracted page table by RCU" added pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now(). Now, this can lead to following problem in a corner case... [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec The bad page state error occurs when such a folio gets freed (with active flag set), from do_exit() path in parallel. ... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the pte_frag_refcount still had some unused fragments. Now, if this process exits, with such folio as it's cached pte_frag in mm->context, then during pte_frag_destroy(), we simply call pagetable_dtor() and pagetable_free(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in do_exit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetable_dtor() & pagetable_free(). Fixes: 32cc0b7c9d50 ("powerpc: add pte_free_defer() for pgtables sharing page") Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/ee13e7f99b8f258019da2b37655b998e73e5ef8b.1773078178.git.ritesh.list@gmail.com
2026-03-17Merge tag 'v7.0-rc4' into sched/core, to pick up scheduler fixesIngo Molnar147-1093/+1222
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2026-03-16arm64: dts: broadcom: bcm2712-d-rpi-5-b: update uart10 interruptGregor Herburger1-0/+4
On the -d revision of bcm2712 the uart interrupt is on 120. Update it accordingly. Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-6-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16arm64: dts: broadcom: bcm2712-d-rpi-5-b: add fixes for pinctrl/pinctrl_aonGregor Herburger1-0/+10
On the -d revision of the bcm2712 the pinctrl differs from the c0 revision. The driver already supports both and distinguishes the two with the compatible string. Update the compatible string and reg length to reflect the different pinctrl. Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-5-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16arm64: dts: broadcom: bcm2712-rpi-5-b: add pinctrl properties for csi i2csGregor Herburger1-0/+24
Configure the i2c pins for the csi interfaces as i2c. Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-4-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16arm64: dts: broadcom: bcm2712: add camera backend node pispbeGregor Herburger1-0/+7
The bcm2712 found in the Raspberry Pi 5 has a PiSP Image Signal Processor back end image processor. Add the relevant node to the devicetree. Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-3-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16arm64: dts: broadcom: rp1: add csi nodesGregor Herburger1-0/+28
The RaspberryPi 5 has 2 PiSP Camera front end controller on the RP1 chipset. Add the relevant nodes to the devicetree. Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-2-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16arm64: dts: broadcom: rp1: add i2c controllerGregor Herburger1-0/+77
The RaspberryPi 5 has 7 designware-i2c I2C controller on the RP1 chipset. Add the relevant nodes to the devicetree. Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://lore.kernel.org/r/20260226-raspi-dts-updates-v1-1-60832d20ff04@linutronix.de Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16ARM: dts: BCM5301X: add root pcie bridgesRosen Penev4-99/+76
They are always required and instead of duplicating a definition in each dts file, place it in dtsi with labels and work based on that. Also changed each bridge@ to pcie@ to get extra dtc static analysis. Fixed bridge numbers as a result. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://lore.kernel.org/r/20260302000736.592422-1-rosenp@gmail.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16x86/sev: Rename SNP_FEATURES_PRESENT to SNP_FEATURES_IMPLKim Phillips1-3/+3
Rename SNP_FEATURES_PRESENT to SNP_FEATURES_IMPL to denote its counterpart relationship with SNP_FEATURES_IMPL_REQ. [ bp: Drop stable@, massage commit message. ] Suggested-by: Borislav Petkov (AMD) <bp@alien8.de> Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260203222405.4065706-4-kim.phillips@amd.com
2026-03-16ARM: dts: BCM5301X: Drop extra NAND controller compatibleMiquel Raynal1-1/+1
Fix the dtbs_check warning introduced when the brcm,brcmnand fallback compatible got removed for iProc machines. Fixes: 4db35366d6dc ("dt-bindings: mtd: brcm,brcmnand: Drop "brcm,brcmnand" compatible for iProc") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20260204091530.624230-1-miquel.raynal@bootlin.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16ARM: dts: BCM5301X: Describe PCIe controllers fullyRafał Miłecki1-1/+25
Tested successfully on BCM47094 SoC using Linux's pcie-iproc-platform driver. This fixes: arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie@12000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus.yaml# arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie@12000: 'ranges' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus.yaml# arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie@13000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus.yaml# arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie@13000: 'ranges' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus.yaml# arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie@14000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus.yaml# arch/arm/boot/dts/broadcom/bcm4708-asus-rt-ac56u.dtb: pcie@14000: 'ranges' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus.yaml# Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20260108224026.3550-1-zajec5@gmail.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16arm64: dts: broadcom: bcm2712: Add V3D device nodeMaíra Canal2-0/+18
Commits 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") and 6fd9487147c4 ("drm/v3d: add brcm,2712-v3d as a compatible V3D device") added driver support for V3D on BCM2712, but the corresponding device tree node is still missing. Add the V3D device tree node to the BCM2712 DTS. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20260114120610.82531-1-mcanal@igalia.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-03-16s390/bpf: Zero-extend bpf prog return values and kfunc argumentsIlya Leoshkevich1-15/+24
s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too. Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Reported-by: Hari Bathini <hbathini@linux.ibm.com> Closes: https://lore.kernel.org/bpf/20260312080113.843408-1-hbathini@linux.ibm.com/ Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20260313174807.581826-1-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-16KVM: s390: vsie: Avoid injecting machine check on signalChristian Borntraeger7-15/+22
The recent XFER_TO_GUEST_WORK change resulted in a situation, where the vsie code would interpret a signal during work as a machine check during SIE as both use the EINTR return code. The exit_reason of the sie64a function has nothing to do with the kvm_run exit_reason. Rename it and define a specific code for machine checks instead of abusing -EINTR. rename exit_reason into sie_return to avoid the naming conflict and change the code flow in vsie.c to have a separate variable for rc and sie_return. Fixes: 2bd1337a1295e ("KVM: s390: Use generic VIRT_XFER_TO_GUEST_WORK functions") Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
2026-03-16KVM: s390: log machine checks more aggressivelyChristian Borntraeger3-2/+6
KVM will reinject machine checks that happen during guest activity. From a host perspective this machine check is no longer visible and even for the guest, the guest might decide to only kill a userspace program or even ignore the machine check. As this can be a disruptive event nevertheless, we should log this not only in the VM debug event (that gets lost after guest shutdown) but also on the global KVM event as well as syslog. Consolidate the logging and log with loglevel 2 and higher. Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com>
2026-03-16KVM: s390: Limit adapter indicator access to mapped pageJanosch Frank1-0/+12
While we check the address for errors, we don't seem to check the bit offsets and since they are 32 and 64 bits a lot of memory can be reached indirectly via those offsets. Fixes: 84223598778b ("KVM: s390: irq routing for adapter interrupts.") Suggested-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Tested-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-03-16s390/mm: Add missing secure storage access fixups for donated memoryJanosch Frank1-2/+9
There are special cases where secure storage access exceptions happen in a kernel context for pages that don't have the PG_arch_1 bit set. That bit is set for non-exported guest secure storage (memory) but is absent on storage donated to the Ultravisor since the kernel isn't allowed to export donated pages. Prior to this patch we would try to export the page by calling arch_make_folio_accessible() which would instantly return since the arch bit is absent signifying that the page was already exported and no further action is necessary. This leads to secure storage access exception loops which can never be resolved. With this patch we unconditionally try to export and if that fails we fixup. Fixes: 084ea4d611a3 ("s390/mm: add (non)secure page access exceptions handlers") Reported-by: Heiko Carstens <hca@linux.ibm.com> Suggested-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Tested-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
2026-03-16ASoC: codec: arizona: Convert to use GPIO descriptorsLinus Walleij1-2/+4
This converts the Arizona driver to use GPIO descriptors exclusively, deletes the legacy code path an updates the in-tree user of legacy GPIO. The GPIO lines for mic detect polarity and headphone ID detection are made exclusively descriptor-oriented. The headphone ID detection could actually only be used by the legacy GPIO code, but I converted it to use a descriptor if someone would actually need it so we don't just drop useful code. The compatible "wlf,hpdet-id-gpio" is not in the device tree bindings and only intended to be used by software nodes if any. If someone insists I can try to add a binding for it, but I doubt there is any real user so it seems pointless. Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260314-asoc-arizona-v1-1-ecc9a165307c@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16ARM: shmobile: rcar-gen2: Use of_phandle_args_equal() helperGeert Uytterhoeven1-12/+4
Use the existing of_phandle_args_equal() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/d8338ff1fd795912b466ccf55b49dcd6885b6925.1773241833.git.geert+renesas@glider.be
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-19 11:11:26 +0300