summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-05-09arm64: tegra: Bump #address-cells and #size-cells on Tegra186Aaron Kling1-67/+67
This was done for Tegra194 and Tegra234 in 2838cfd, but Tegra186 was not part of that change. The same reasoning for that commit also applies to Tegra186, plus keeping the archs as close to each other as possible makes it easier to compare between them and support features concurrently. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250419-tegra186-host1x-addr-size-v1-1-a7493882248d@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-09arm64: tegra: p2180: Explicitly enable GPUAaron Kling1-0/+1
The gpu node originally was explicitly left disabled as it was expected for the bootloader to enable it. However, this is only done in u-boot. If u-boot is not in the boot chain, this will never be enabled. Other Tegra210 devices already explicitly enable the gpu, so make p2180 match. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250420-tx1-gpu-v1-1-d500de18e43e@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: p3310: Explicitly enable GPUAaron Kling1-0/+4
The gpu node originally was explicitly left disabled as it was expected for the bootloader to enable it. However, this is only done in U-Boot. If U-Boot is not in the boot chain, this will never be enabled. Other Tegra186 devices already explicitly enable the GPU, so make p3310 match. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250426-tx2-gpu-v1-1-fa1c78dcdbdc@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: Add DMA properties for Tegra186 and Tegra194 UARTsAaron Kling6-0/+38
Adding the missing dmas and dma-names properties which are required for uart when using with the Tegra HSUART driver. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250428-tegra-serial-fixes-v1-2-4f47c5d85bf6@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: Drop remaining serial clock-names and reset-namesAaron Kling2-24/+0
The referenced commit only removed some of the names, missing all that weren't in use at the time. The commit removes the rest. Fixes: 71de0a054d0e ("arm64: tegra: Drop serial clock-names and reset-names") Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250428-tegra-serial-fixes-v1-1-4f47c5d85bf6@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: Enable PWM fan on the Jetson TX2 DevkitAaron Kling1-0/+109
This is based on the existing configuration of the Jetson TX2 NX devkit. The fan and thermal characteristics of the two devkits are similar, so using the same configuration. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250427-tx2-therm-v1-1-65ddb4314723@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: Enable PWM fan on the Jetson TX1 DevkitAaron Kling1-0/+75
This is based on 6f78a94, which enabled added the fan and thermal zones for the Jetson Nano Devkit. The fan and thermal characteristics of the two devkits are similar, so using the same configuration. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250501-tx1-therm-v2-1-abdb1922c001@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08ARM: tegra: Add device-tree for ASUS Transformer Pad LTE TF300TLSvyatoslav Ryhel2-0/+858
Add device-tree for ASUS Transformer Pad LTE TF300TL, which is NVIDIA Tegra30-based tablet device. Co-developed-by: Ion Agorria <ion@agorria.com> Signed-off-by: Ion Agorria <ion@agorria.com> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250503102950.32744-4-clamor95@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: Add I2C aliases for Tegra234Akhil R1-0/+12
Add aliases for all I2C nodes so that the I2C devnode numbers align with hardware bus number. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://lore.kernel.org/r/20250506095936.10687-4-akhilrajeev@nvidia.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08arm64: tegra: Configure QSPI clocks and add DMAVishwaroop A1-0/+10
For Tegra234 devices, set QSPI0_2X_PM to 199.99 MHz and QSPI0_PM to 99.99 MHz using PLLC as the parent clock. These frequencies enable Quad IO reads at up to 99.99 MHz, the maximum achievable given PLL and clock divider limitations. Introduce IOMMU property which is needed for internal DMA transfers. Signed-off-by: Vishwaroop A <va@nvidia.com> Link: https://lore.kernel.org/r/20250506152350.3370291-2-va@nvidia.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08ARM: tegra: Rename the apbdma nodename to match with common dma-controller ↵Charan Pedumuru2-2/+2
binding Rename the apbdma nodename from "dma@" to "dma-controller@" to align with linux common dma-controller binding. Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20250507-nvidea-dma-v4-1-6161a8de376f@gmail.com [treding@nvidia.com: adjust subject prefix for consistency] Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable USB host portWolfram Sang1-0/+4
Can be used via the USB connector J20. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250508074311.20343-6-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08ARM: dts: renesas: r9a06g032-rzn1d400-db: Add pinmux for the CPLDWolfram Sang1-0/+10
The CPLD has no dedicated driver, so apply the pinmux settings with the pinmux driver instead. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250508074311.20343-5-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08arm64: dts: renesas: white-hawk-single: Improve Ethernet TSN descriptionGeert Uytterhoeven1-2/+6
- Add the missing "ethernet3" alias for the Ethernet TSN port, so U-Boot will fill its local-mac-address property based on the "eth3addr" environment variable (if set), avoiding a random MAC address being assigned by the OS, - Rename the numerical Ethernet PHY label to "tsn0_phy", to avoid future conflicts, and for consistency with the "avbN_phy" labels. Fixes: 3d8e475bd7a724a9 ("arm64: dts: renesas: white-hawk-single: Wire-up Ethernet TSN") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/367f10a18aa196ff1c96734dd9bd5634b312c421.1746624368.git.geert+renesas@glider.be
2025-05-08ARM: dts: renesas: r9a06g032-rzn1d400-db: Enable USB device portWolfram Sang1-0/+4
Can be used via the microUSB connector CN9. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250425100129.11942-5-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08ARM: dts: renesas: r9a06g032-rzn1d400-eb: Describe 9-pin D-sub serial portWolfram Sang1-0/+15
A simple CTS/RTS capable UART on a good old D-sub connector. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250424102805.22803-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08arm64: dts: renesas: beacon-renesom: Align wifi node name with bindingsKrzysztof Kozlowski1-1/+1
Since commit 3c3606793f7e ("dt-bindings: wireless: bcm4329-fmac: Use wireless-controller.yaml schema"), bindings expect 'wifi' as node name: r8a774a1-beacon-rzg2m-kit.dtb: bcrmf@1: $nodename:0: 'bcrmf@1' does not match '^wifi(@.*)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250424084748.105255-1-krzysztof.kozlowski@linaro.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08arm64: dts: renesas: rzg2l-smarc: Enable GPT on carrier boardBiju Das4-0/+27
The GPT4 IOs are available on the carrier board's PMOD0 connector (J1). Enable the GPT on the carrier board by adding the GPT pinmux and node on the carrier board dtsi file. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250424054050.28310-4-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08arm64: dts: renesas: r9a07g054: Add GPT supportBiju Das1-0/+115
Add GPT support by adding pwm node to RZ/V2L SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250424054050.28310-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08arm64: dts: renesas: r9a07g044: Add GPT supportBiju Das1-0/+115
Add GPT support by adding pwm node to RZ/G2L SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250424054050.28310-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08arm64: dts: renesas: sparrow-hawk: Add MSIOF Sound supportKuninori Morimoto1-0/+106
Sparrow Hawk has Headset (CONN3) AUX_IN (CONN4) for Sound input/output which is using MSIOF. Support it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/87plha2wzr.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/874ixxcg3w.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08ARM: dts: renesas: r9a06g032-rzn1d400-eb: Add GMAC1 portWolfram Sang1-0/+65
This port bypasses the switch and is directly connected to the GMAC. Co-developed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250414100206.7185-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-05-08Merge patch series "riscv: Add vendor extensions support for SiFive"Palmer Dabbelt11-1/+117
Cyan Yang <cyan.yang@sifive.com> says: This patch set adds four vendor-specific ISA extensions from SiFive: "xsfvqmaccdod", "xsfvqmaccqoq", "xsfvfnrclipxfqf", and "xsfvfwmaccqqq". Additionally, a new hwprobe key, RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0, has been added to query which SiFive vendor extensions are supported on the current platform. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-1-cyan.yang@sifive.com * b4-shazam-merge: riscv: hwprobe: Add SiFive xsfvfwmaccqqq vendor extension riscv: hwprobe: Document SiFive xsfvfwmaccqqq vendor extension riscv: Add SiFive xsfvfwmaccqqq vendor extension dt-bindings: riscv: Add xsfvfwmaccqqq ISA extension description riscv: hwprobe: Add SiFive xsfvfnrclipxfqf vendor extension riscv: hwprobe: Document SiFive xsfvfnrclipxfqf vendor extension riscv: Add SiFive xsfvfnrclipxfqf vendor extension dt-bindings: riscv: Add xsfvfnrclipxfqf ISA extension description riscv: hwprobe: Add SiFive vendor extension support and probe for xsfqmaccdod and xsfqmaccqoq riscv: hwprobe: Document SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensions riscv: Add SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensions dt-bindings: riscv: Add xsfvqmaccdod and xsfvqmaccqoq ISA extension description Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Add SiFive xsfvfwmaccqqq vendor extensionCyan Yang2-0/+2
Add hwprobe for SiFive "xsfvfwmaccqqq" vendor extension. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-13-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: Add SiFive xsfvfwmaccqqq vendor extensionCyan Yang2-0/+2
Add SiFive vendor extension "xsfvfwmaccqqq" support to the kernel. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-11-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Add SiFive xsfvfnrclipxfqf vendor extensionCyan Yang2-0/+2
Add hwprobe for SiFive "xsfvfnrclipxfqf" vendor extension. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-9-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: Add SiFive xsfvfnrclipxfqf vendor extensionCyan Yang2-0/+2
Add SiFive vendor extension "xsfvfnrclipxfqf" support to the kernel. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-7-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Add SiFive vendor extension support and probe for ↵Cyan Yang6-0/+50
xsfqmaccdod and xsfqmaccqoq Add a new hwprobe key "RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0" which allows userspace to probe for the new vendor extensions from SiFive. Also, add new hwprobe for SiFive "xsfvqmaccdod" and "xsfvqmaccqoq" vendor extensions. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-5-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensionsCyan Yang2-1/+2
Document the support for sifive vendor extensions using the key RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0 and two vendor extensions for SiFive Int8 Matrix Multiplication Instructions using RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD and RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-4-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: Add SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensionsCyan Yang5-0/+57
Add SiFive vendor extension support to the kernel with the target of "xsfvqmaccdod" and "xsfvqmaccqoq". Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-3-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08treewide, timers: Rename try_to_del_timer_sync() as timer_delete_sync_try()Ingo Molnar1-1/+1
Move this API to the canonical timer_*() namespace. Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250507175338.672442-9-mingo@kernel.org
2025-05-08timers: Rename NEXT_TIMER_MAX_DELTA as TIMER_NEXT_MAX_DELTAIngo Molnar1-4/+4
Move this macro to the canonical TIMER_* namespace. Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250507175338.672442-7-mingo@kernel.org
2025-05-08arm64: dts: rockchip: Move rk3568 PCIe3 MSI to use GIC ITSChukun Pan1-4/+4
Following commit b956c9de9175 ("arm64: dts: rockchip: rk356x: Move PCIe MSI to use GIC ITS instead of MBI"), change the PCIe3 controller's MSI on rk3568 to use ITS, so that all MSI-X can work properly. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20250308093008.568437-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-08riscv: vDSO: Remove --hash-style=bothXi Ruoyao1-1/+1
When RISC-V borned, DT_GNU_HASH had already became the de-facto standard so DT_HASH is just wasting storage space. Remove the explicit --hash-style=both setting and rely on the distro toolchain default, which is most likely "gnu" (i.e. generating only DT_GNU_HASH, no DT_HASH). Following the logic of commit 48f6430505c0 ("arm64/vdso: Remove --hash-style=sysv"). Signed-off-by: Xi Ruoyao <xry111@xry111.site> Link: https://lore.kernel.org/r/20250224112042.60282-2-xry111@xry111.site Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08arm64: dts: rockchip: Update eMMC for NanoPi R5 seriesPeter Robinson1-1/+4
Add the 3.3v and 1.8v regulators that are connected to the eMMC on the R5 series devices, as well as adding the eMMC data strobe, and enable eMMC HS200 mode as the Foresee FEMDNN0xxG-A3A55 modules support it. Fixes: c8ec73b05a95d ("arm64: dts: rockchip: create common dtsi for NanoPi R5 series") Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250506222531.625157-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-05-08Merge patch series "riscv: uaccess: optimisations"Palmer Dabbelt4-53/+179
Cyril Bur <cyrilbur@tenstorrent.com> says: This series tries to optimize riscv uaccess by allowing the use of user_access_begin() and user_access_end() which permits grouping user accesses and avoiding the CSR write penalty for each access. The error path can also be optimised using asm goto which patches 3 and 4 achieve. This will speed up jumping to labels by avoiding the need of an intermediary error type variable within the uaccess macros I did read the discussion this series generated. It isn't clear to me which direction to take the patches, if any. * b4-shazam-merge: riscv: uaccess: use 'asm_goto_output' for get_user() riscv: uaccess: use 'asm goto' for put_user() riscv: uaccess: use input constraints for ptr of __put_user() riscv: implement user_access_begin() and families riscv: save the SR_SUM status over switches Link: https://lore.kernel.org/r/20250410070526.3160847-1-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: uaccess: use 'asm_goto_output' for get_user()Jisheng Zhang1-27/+68
With 'asm goto' we don't need to test the error etc, the exception just jumps to the error handling directly. Unlike put_user(), get_user() must work around GCC bugs [1] when using output clobbers in an asm goto statement. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 # 1 Signed-off-by: Jisheng Zhang <jszhang@kernel.org> [Cyril Bur: Rewritten commit message] Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-6-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: uaccess: use 'asm goto' for put_user()Jisheng Zhang1-38/+33
With 'asm goto' we don't need to test the error etc, the exception just jumps to the error handling directly. Because there are no output clobbers which could trigger gcc bugs [1] the use of asm_goto_output() macro is not necessary here. Not using asm_goto_output() is desirable as the generated output asm will be cleaner. Use of the volatile keyword is redundant as per gcc 14.2.0 manual section 6.48.2.7 Goto Labels: > Also note that an asm goto statement is always implicitly considered volatile. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 # 1 Signed-off-by: Jisheng Zhang <jszhang@kernel.org> [Cyril Bur: Rewritten commit message] Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-5-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: uaccess: use input constraints for ptr of __put_user()Jisheng Zhang1-9/+9
Putting ptr in the inputs as opposed to output may seem incorrect but this is done for a few reasons: - Not having it in the output permits the use of asm goto in a subsequent patch. There are bugs in gcc [1] which would otherwise prevent it. - Since the output memory is userspace there isn't any real benefit from telling the compiler about the memory clobber. - x86, arm and powerpc all use this technique. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 # 1 Signed-off-by: Jisheng Zhang <jszhang@kernel.org> [Cyril Bur: Rewritten commit message] Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-4-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: implement user_access_begin() and familiesJisheng Zhang1-0/+76
Currently, when a function like strncpy_from_user() is called, the userspace access protection is disabled and enabled for every word read. By implementing user_access_begin() and families, the protection is disabled at the beginning of the copy and enabled at the end. The __inttype macro is borrowed from x86 implementation. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-3-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: save the SR_SUM status over switchesBen Dooks3-0/+14
When threads/tasks are switched we need to ensure the old execution's SR_SUM state is saved and the new thread has the old SR_SUM state restored. The issue was seen under heavy load especially with the syz-stress tool running, with crashes as follows in schedule_tail: Unable to handle kernel access to user memory without uaccess routines at virtual address 000000002749f0d0 Oops [#1] Modules linked in: CPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 Hardware name: riscv-virtio,qemu (DT) epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 ra : task_pid_vnr include/linux/sched.h:1421 [inline] ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264 epc : ffffffe00008c8b0 ra : ffffffe00008c8ae sp : ffffffe025d17ec0 gp : ffffffe005d25378 tp : ffffffe00f0d0000 t0 : 0000000000000000 t1 : 0000000000000001 t2 : 00000000000f4240 s0 : ffffffe025d17ee0 s1 : 000000002749f0d0 a0 : 000000000000002a a1 : 0000000000000003 a2 : 1ffffffc0cfac500 a3 : ffffffe0000c80cc a4 : 5ae9db91c19bbe00 a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba s2 : 0000000000040000 s3 : ffffffe00eef96c0 s4 : ffffffe022c77fe0 s5 : 0000000000004000 s6 : ffffffe067d74e00 s7 : ffffffe067d74850 s8 : ffffffe067d73e18 s9 : ffffffe067d74e00 s10: ffffffe00eef96e8 s11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2 t5 : ffffffc4043cafba t6 : 0000000000040000 status: 0000000000000120 badaddr: 000000002749f0d0 cause: 000000000000000f Call Trace: [<ffffffe00008c8b0>] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 [<ffffffe000005570>] ret_from_exception+0x0/0x14 Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace b5f8f9231dc87dda ]--- The issue comes from the put_user() in schedule_tail (kernel/sched/core.c) doing the following: asmlinkage __visible void schedule_tail(struct task_struct *prev) { ... if (current->set_child_tid) put_user(task_pid_vnr(current), current->set_child_tid); ... } the put_user() macro causes the code sequence to come out as follows: 1: __enable_user_access() 2: reg = task_pid_vnr(current); 3: *current->set_child_tid = reg; 4: __disable_user_access() The problem is that we may have a sleeping function as argument which could clear SR_SUM causing the panic above. This was fixed by evaluating the argument of the put_user() macro outside the user-enabled section in commit 285a76bb2cf5 ("riscv: evaluate put_user() arg before enabling user access")" In order for riscv to take advantage of unsafe_get/put_XXX() macros and to avoid the same issue we had with put_user() and sleeping functions we must ensure code flow can go through switch_to() from within a region of code with SR_SUM enabled and come back with SR_SUM still enabled. This patch addresses the problem allowing future work to enable full use of unsafe_get/put_XXX() macros without needing to take a CSR bit flip cost on every access. Make switch_to() save and restore SR_SUM. Reported-by: syzbot+e74b94fe601ab9552d69@syzkaller.appspotmail.com Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Cyril Bur <cyrilbur@tenstorrent.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Link: https://lore.kernel.org/r/20250410070526.3160847-2-cyrilbur@tenstorrent.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski26-80/+221
Cross-merge networking fixes after downstream PR (net-6.15-rc6). No conflicts. Adjacent changes: net/core/dev.c: 08e9f2d584c4 ("net: Lock netdevices during dev_shutdown") a82dc19db136 ("net: avoid potential race between netdev_get_by_index_lock() and netns switch") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08Merge tag 's390-6.15-4' of ↵Linus Torvalds5-18/+40
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Heiko Carstens: - Fix potential use-after-free bug and missing error handling in PCI code - Fix dcssblk build error - Fix last breaking event handling in case of stack corruption to allow for better error reporting - Update defconfigs * tag 's390-6.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs s390/pci: Fix missing check for zpci_create_device() error return s390: Update defconfigs s390/dcssblk: Fix build error with CONFIG_DAX=m and CONFIG_DCSSBLK=y s390/entry: Fix last breaking event handling in case of stack corruption s390/configs: Enable options required for TC flow offload s390/configs: Enable VDPA on Nvidia ConnectX-6 network card
2025-05-08arm64: proton-pack: Add new CPUs 'k' values for branch mitigationJames Morse2-0/+3
Update the list of 'k' values for the branch mitigation from arm's website. Add the values for Cortex-X1C. The MIDR_EL1 value can be found here: https://developer.arm.com/documentation/101968/0002/Register-descriptions/AArch> Link: https://developer.arm.com/documentation/110280/2-0/?lang=en Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
2025-05-08arm64/fpsimd: Allow CONFIG_ARM64_SME to be selectedMark Rutland1-1/+0
Now that the known issues with SME have been addressed, allow SME to be selected. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Daniel Kiss <daniel.kiss@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Richard Sandiford <richard.sandiford@arm.com> Cc: Sander De Smalen <sander.desmalen@arm.com> Cc: Tamas Petz <tamas.petz@arm.com> Cc: Todd Kjos <tkjos@google.com> Cc: Will Deacon <will@kernel.org> Cc: Yury Khrustalev <yury.khrustalev@arm.com> Tested-By: Luis Machado <luis.machado@arm.com> Link: https://lore.kernel.org/r/20250508132644.1395904-21-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08arm64/fpsimd: ptrace: Gracefully handle errorsMark Rutland1-35/+26
Within sve_set_common() we do not handle error conditions correctly: * When writing to NT_ARM_SSVE, if sme_alloc() fails, the task will be left with task->thread.sme_state==NULL, but TIF_SME will be set and task->thread.fp_type==FP_STATE_SVE. This will result in a subsequent null pointer dereference when the task's state is loaded or otherwise manipulated. * When writing to NT_ARM_SSVE, if sve_alloc() fails, the task will be left with task->thread.sve_state==NULL, but TIF_SME will be set, PSTATE.SM will be set, and task->thread.fp_type==FP_STATE_FPSIMD. This is not a legitimate state, and can result in various problems, including a subsequent null pointer dereference and/or the task inheriting stale streaming mode register state the next time its state is loaded into hardware. * When writing to NT_ARM_SSVE, if the VL is changed but the resulting VL differs from that in the header, the task will be left with TIF_SME set, PSTATE.SM set, but task->thread.fp_type==FP_STATE_FPSIMD. This is not a legitimate state, and can result in various problems as described above. Avoid these problems by allocating memory earlier, and by changing the task's saved fp_type to FP_STATE_SVE before skipping register writes due to a change of VL. To make early returns simpler, I've moved the call to fpsimd_flush_task_state() earlier. As the tracee's state has already been saved, and the tracee is known to be blocked for the duration of sve_set_common(), it doesn't matter whether this is called at the start or the end. For consistency I've moved the setting of TIF_SVE earlier. This will be cleared when loading FPSIMD-only state, and so moving this has no resulting functional change. Note that we only allocate the memory for SVE state when SVE register contents are provided, avoiding unnecessary memory allocations for tasks which only use FPSIMD. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Fixes: baa8515281b3 ("arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE") Fixes: 5d0a8d2fba50 ("arm64/ptrace: Ensure that SME is set up for target when writing SSVE state") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250508132644.1395904-20-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08arm64/fpsimd: ptrace: Mandate SVE payload for streaming-mode stateMark Rutland1-1/+11
When a task has PSTATE.SM==1, reads of NT_ARM_SSVE are required to always present a header with SVE_PT_REGS_SVE, and register data in SVE format. Reads of NT_ARM_SSVE must never present register data in FPSIMD format. Within the kernel, we always expect streaming SVE data to be stored in SVE format. Currently a user can write to NT_ARM_SSVE with a header presenting SVE_PT_REGS_FPSIMD rather than SVE_PT_REGS_SVE, placing the task's FPSIMD/SVE data into an invalid state. To fix this we can either: (a) Forbid such writes. (b) Accept such writes, and immediately convert data into SVE format. Take the simple option and forbid such writes. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250508132644.1395904-19-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08arm64/fpsimd: ptrace: Do not present register data for inactive modeMark Rutland1-14/+18
The SME ptrace ABI is written around the incorrect assumption that SVE_PT_REGS_FPSIMD and SVE_PT_REGS_SVE are independent bit flags, where it is possible for both to be clear. In reality they are different values for bit 0 of the header flags, where SVE_PT_REGS_FPSIMD is 0 and SVE_PT_REGS_SVE is 1. In cases where code was written expecting that neither bit flag would be set, the value is equivalent to SVE_PT_REGS_FPSIMD. One consequence of this is that reads of the NT_ARM_SVE or NT_ARM_SSVE will erroneously present data from the other mode: * When PSTATE.SM==1, reads of NT_ARM_SVE will present a header with SVE_PT_REGS_FPSIMD, and FPSIMD-formatted data from streaming mode. * When PSTATE.SM==0, reads of NT_ARM_SSVE will present a header with SVE_PT_REGS_FPSIMD, and FPSIMD-formatted data from non-streaming mode. The original intent was that no register data would be provided in these cases, as described in commit: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Luckily, debuggers do not consume the bogus register data. Both GDB and LLDB read the NT_ARM_SSVE regset before the NT_ARM_SVE regset, and assume that when the NT_ARM_SSVE header presents SVE_PT_REGS_FPSIMD, it is necessary to read register contents from the NT_ARM_SVE regset, regardless of whether the NT_ARM_SSVE regset provided bogus register data. Fix the code to stop presenting register data from the inactive mode. At the same time, make the manipulation of the flag clearer, and remove the bogus comment from sve_set_common(). I've given this a quick spin with GDB and LLDB, and both seem happy. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250508132644.1395904-18-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08arm64/fpsimd: ptrace: Save task state before generating SVE headerMark Rutland1-3/+3
As sve_init_header_from_task() consumes the saved value of PSTATE.SM and the saved fp_type, both must be saved before the header is generated. When generating a coredump for the current task, sve_get_common() calls sve_init_header_from_task() before saving the task's state. Consequently the header may be bogus, and the contents of the regset may be misleading. Fix this by saving the task's state before generting the header. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Fixes: b017a0cea627 ("arm64/ptrace: Use saved floating point state type to determine SVE layout") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250508132644.1395904-17-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08arm64/fpsimd: ptrace/prctl: Ensure VL changes leave task in a valid stateMark Rutland1-65/+72
Currently, vec_set_vector_length() can manipulate a task into an invalid state as a result of a prctl/ptrace syscall which changes the SVE/SME vector length, resulting in several problems: (1) When changing the SVE vector length, if the task initially has PSTATE.ZA==1, and sve_alloc() fails to allocate memory, the task will be left with PSTATE.ZA==1 and sve_state==NULL. This is not a legitimate state, and could result in a subsequent null pointer dereference. (2) When changing the SVE vector length, if the task initially has PSTATE.SM==1, the task will be left with PSTATE.SM==1 and fp_type==FP_STATE_FPSIMD. Streaming mode state always needs to be saved in SVE format, so this is not a legitimate state. Attempting to restore this state may cause a task to erroneously inherit stale streaming mode predicate registers and FFR contents, behaving non-deterministically and potentially leaving information from another task. While in this state, reads of the NT_ARM_SSVE regset will indicate that the registers are not stored in SVE format. For the NT_ARM_SSVE regset specifically, debuggers interpret this as meaning that PSTATE.SM==0. (3) When changing the SME vector length, if the task initially has PSTATE.SM==1, the lower 128 bits of task's streaming mode vector state will be migrated to non-streaming mode, rather than these bits being zeroed as is usually the case for changes to PSTATE.SM. To fix the first issue, we can eagerly allocate the new sve_state and sme_state before modifying the task. This makes it possible to handle memory allocation failure without modifying the task state at all, and removes the need to clear TIF_SVE and TIF_SME. To fix the second issue, we either need to clear PSTATE.SM or not change the saved fp_type. Given we're going to eagerly allocate sve_state and sme_state, the simplest option is to preserve PSTATE.SM and the saves fp_type, and consistently truncate the SVE state. This ensures that the task always stays in a valid state, and by virtue of not exiting streaming mode, this also sidesteps the third issue. I believe these changes should not be problematic for realistic usage: * When the SVE/SME vector length is changed via prctl(), syscall entry will have cleared PSTATE.SM. Unless the task's state has been manipulated via ptrace after entry, the task will have PSTATE.SM==0. * When the SVE/SME vector length is changed via a write to the NT_ARM_SVE or NT_ARM_SSVE regsets, PSTATE.SM will be forced immediately after the length change, and new vector state will be copied from userspace. * When the SME vector length is changed via a write to the NT_ARM_ZA regset, the (S)SVE state is clobbered today, so anyone who cares about the specific state would need to install this after writing to the NT_ARM_ZA regset. As we need to free the old SVE state while TIF_SVE may still be set, we cannot use sve_free(), and using kfree() directly makes it clear that the free pairs with the subsequent assignment. As this leaves sve_free() unused, I've removed the existing sve_free() and renamed __sve_free() to mirror sme_free(). Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") Fixes: baa8515281b3 ("arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250508132644.1395904-16-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-13 11:30:43 +0300