summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-12-16MIPS: Move IP27 timer to request_percpu_irq()Marc Zyngier1-8/+2
Teach the SGI IP27 timer about request_percpu_irq(), which ultimately will allow for the removal of the antiquated setup_percpu_irq() API. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251210082242.360936-5-maz@kernel.org
2025-12-16MIPS: Move IP30 timer to request_percpu_irq()Marc Zyngier3-15/+2
Teach the SGI IP30 timer about request_percpu_irq(), which ultimately will allow for the removal of the antiquated setup_percpu_irq() API. Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251210082242.360936-4-maz@kernel.org
2025-12-15ARM: dts: ixp4xx: Fix up Actiontec MI424WR DTS filesLinus Walleij3-1/+22
The KS8995 switch was unconditionally wired to EthC (eth1) on both MI424WR variants, this is wrong: the D revision has the switch connected to EthB (eth0) so pull this assingment out of the generic MI424WR DTSI file and make it a property of the respective variants instead. Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20251211-ixp4xx-actiontec-dts-fix-v1-1-97af8e79d474@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2025-12-15Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"Tomas Melin1-5/+0
This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime. Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20251125-revert-zynqmp-optee-v1-1-d2ce4c0fcaf6@vaisala.com
2025-12-15MIPS: Fix a reference leak bug in ip22_check_gio()Haoxiang Li1-1/+2
If gio_device_register fails, gio_dev_put() is required to drop the gio_dev device reference. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-12-15MIPS: Alchemy: Remove bogus static/inline specifiersThierry Reding1-2/+1
The recent io_remap_pfn_range() rework applied the static and inline specifiers to the implementation of io_remap_pfn_range_pfn() on MIPS Alchemy, mirroring the same change on other platforms. However, this function is defined in a source file and that definition causes a conflict with its declaration. Fix this by dropping the specifiers. Fixes: c707a68f9468 ("mm: abstract io_remap_pfn_range() based on PFN") Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-12-15xtensa: align: validate access in fast_load_storeRicky Ringler1-2/+8
access_ok() is used only in user mode and branches to .Linvalid_instruction on fault. Kernel mode skips access_ok(). Tested-by: Ricky Ringler <richard.rringler@gmail.com> Signed-off-by: Ricky Ringler <richard.rringler@gmail.com> Message-ID: <20251215143323.2771889-1-richard.rringler@gmail.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2025-12-15init: remove deprecated "load_ramdisk" and "prompt_ramdisk" command line ↵Askar Safin1-1/+1
parameters ...which do nothing. They were deprecated (in documentation) in 6b99e6e6aa62 ("Documentation/admin-guide: blockdev/ramdisk: remove use of "rdev"") in 2020 and in kernel messages in c8376994c86c ("initrd: remove support for multiple floppies") in 2020. Signed-off-by: Askar Safin <safinaskar@gmail.com> Link: https://patch.msgid.link/20251119222407.3333257-2-safinaskar@gmail.com Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15arm64: dts: ti: k3-am62-lp-sk-nand: Rename pinctrls to fix schema warningsWadim Egorov1-1/+1
Rename pinctrl nodes to comply with naming conventions required by pinctrl-single schema. Fixes: e569152274fec ("arm64: dts: ti: am62-lp-sk: Add overlay for NAND expansion card") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251127122733.2523367-3-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15arm64: dts: ti: k3-am642-phyboard-electra-x27-gpio1-spi1-uart3: Fix schema ↵Wadim Egorov1-4/+4
warnings Rename pinctrl nodes to comply with naming conventions required by pinctrl-single schema. Also, replace invalid integer assignment in SPI node with a boolean to align with omap-spi schema. Fixes: 638ab30ce4c6 ("arm64: dts: ti: am64-phyboard-electra: Add DT overlay for X27 connector") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251127122733.2523367-2-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15arm64: dts: ti: k3-am642-phyboard-electra-peb-c-010: Fix icssg-prueth schema ↵Wadim Egorov1-5/+2
warning Reduce length of dma-names and dmas properties for icssg1-ethernet node to comply with ti,icssg-prueth schema constraints. The previous entries exceeded the allowed count and triggered dtschema warnings during validation. Fixes: e53fbf955ea7 ("arm64: dts: ti: k3-am642-phyboard-electra: Add PEB-C-010 Overlay") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251127122733.2523367-1-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15arm64/gcs: Flush the GCS locking state on execMark Brown1-0/+1
When we exec a new task we forget to flush the set of locked GCS mode bits. Since we do flush the rest of the state this means that if GCS is locked the new task will be unable to enable GCS, it will be locked as being disabled. Add the expected flush. Fixes: fc84bc5378a8 ("arm64/gcs: Context switch GCS state for EL0") Cc: <stable@vger.kernel.org> # 6.13.x Reported-by: Yury Khrustalev <Yury.Khrustalev@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Tested-by: Yury Khrustalev <yury.khrustalev@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-12-15arm64/efi: Remove unneeded SVE/SME fallback preserve/store handlingArd Biesheuvel1-110/+20
Since commit 7137a203b251 ("arm64/fpsimd: Permit kernel mode NEON with IRQs off"), the only condition under which the fallback path is taken for FP/SIMD preserve/restore across a EFI runtime call is when it is called from hardirq or NMI context. In practice, this only happens when the EFI pstore driver is called to dump the kernel log buffer into a EFI variable under a panic, oops or emergency_restart() condition, and none of these can be expected to result in a return to user space for the task in question. This means that the existing EFI-specific logic for preserving and restoring SVE/SME state is pointless, and can be removed. Instead, kill the task, so that an exceedingly unlikely inadvertent return to user space does not proceed with a corrupted FP/SIMD state. Also, retain the preserve and restore of the base FP/SIMD state, as that might belong to kernel mode use of FP/SIMD. (Note that EFI runtime calls are never invoked reentrantly, even in this case, and so any interrupted kernel mode FP/SIMD usage will be unrelated to EFI) Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-12-15arm64: mm: Simplify check in arch_kfence_init_pool()Kevin Brodsky1-17/+16
TL;DR: checking force_pte_mapping() in arch_kfence_init_pool() is sufficient Commit ce2b3a50ad92 ("arm64: mm: Don't sleep in split_kernel_leaf_mapping() when in atomic context") recently added an arm64 implementation of arch_kfence_init_pool() to ensure that the KFENCE pool is PTE-mapped. Assuming that the pool was not initialised early, block splitting is necessary if the linear mapping is not fully PTE-mapped, in other words if force_pte_mapping() is false. arch_kfence_init_pool() currently makes another check: whether BBML2-noabort is supported, i.e. whether we are *able* to split block mappings. This check is however unnecessary, because force_pte_mapping() is always true if KFENCE is enabled and BBML2-noabort is not supported. This must be the case by design, since KFENCE requires PTE-mapped pages in all cases. We can therefore remove that check. The situation is different in split_kernel_leaf_mapping(), as that function is called unconditionally regardless of the configuration. If BBML2-noabort is not supported, it cannot do anything and bails out. If force_pte_mapping() is true, there is nothing to do and it also bails out, but these are independent checks. Commit 53357f14f924 ("arm64: mm: Tidy up force_pte_mapping()") grouped these checks into a helper, split_leaf_mapping_possible(). This isn't so helpful as only split_kernel_leaf_mapping() should check both. Revert the parts of that commit that introduced the helper, reintroducing the more accurate comments in split_kernel_leaf_mapping(). Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-12-15arm64: dts: rockchip: Fix voltage threshold for volume keys for Pinephone ProOndrej Jirman1-2/+2
Previously sometimes pressing the volume-down button would register as a volume-up button. Match the thresholds as shown in the Pinephone Pro schematic. Tests: ~ $ evtest // Mashed the volume down ~100 times with varying intensity Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 // Mashed the volume up ~100 times with varying intensity Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1 Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0 Fixes: d3150ed53580 ("arm64: dts: rockchip: Add support for volume keys to rk3399-pinephone-pro") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Link: https://patch.msgid.link/20251124-ppp_light_accel_mag_vol-down-v5-4-f9a10a0a50eb@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-12-15arm64: dts: rockchip: Add accelerometer sensor to Pinephone ProOndrej Jirman1-0/+6
Pinephone Pro uses mpu6500 according to the schematic. This was verified via `monitor-sensor --accel`. While rotating the device, the output was correct (eg. when it was face up, left edge was up, vertical, etc.). Co-developed-by: Martijn Braam <martijn@brixit.nl> Signed-off-by: Martijn Braam <martijn@brixit.nl> Co-developed-by: Kamil Trzciński <ayufan@ayufan.eu> Signed-off-by: Kamil Trzciński <ayufan@ayufan.eu> Signed-off-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Link: https://patch.msgid.link/20251124-ppp_light_accel_mag_vol-down-v5-2-f9a10a0a50eb@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-12-15arm64: dts: rockchip: Enable SPDIF audio on Rock 5 ITXTorsten Duwe1-0/+23
The Rock5 ITX has an S/PDIF (TOSLINK) socket in its I/O-shield, whose TX signal is wired to GPIO4 C1. Activate SPDIF TX unit 1 and select the proper pinmux (M2). Signed-off-by: Torsten Duwe <duwe@lst.de> Link: https://patch.msgid.link/20251124183056.B853068C4E@verein.lst.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-12-15arm64: dts: rockchip: Add overlay for the PCIe slot on RK3576 EVB1Alexey Charkov2-0/+36
Rockchip RK3576 EVB1 has an onboard PCIe slot (PCIe 2.1, x4 mechanically, x1 electrically), but it shares pins and PHY with the only USB3 Type-A port. There is a physical switch next to the slot to transfer respective pins connection from the USB3 port to the PCIe slot, but apart from flipping the switch one must also disable the USB3 host controller to prevent it from claiming the PHY before the PCIe slot can become usable. Add an overlay to disable the USB3 host port and instead enable the PCIe slot, along with its pin configs. The physical switch must still be flipped to the "ON - PCIe1" position for this to work. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://patch.msgid.link/20251202-evb1-pcie1-v2-1-810693b1b72f@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-12-15ARM: dts: rockchip: Add vdec node for RK3288Alex Bee1-1/+16
RK3288 contains a Rockchip VDEC block that only support HEVC decoding. Add a vdec node for this. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://patch.msgid.link/20250905161942.3759717-8-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-12-15arm64: dts: renesas: r9a09g047e57-smarc: Enable USB3HOSTBiju Das2-0/+18
Enable USB3.2 Gen2 Host controller(a.k.a USB3HOST) on the RZ/G3E SMARC EVK platform. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250916150255.4231-9-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-12-15arm64: dts: renesas: r9a09g047: Add USB3 PHY/Host nodesBiju Das1-0/+30
Add USB3 PHY/Host nodes to RZ/G3E ("R9A09G047") SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250916150255.4231-8-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-12-15arm64: dts: morello: Add CMN PMURobin Murphy1-0/+7
Although CMN-Skeena is mildly modified for the Morello hardware architecture, it still identifies itself as CMN-600 r3p1. Since there are also no documented changes to its PMU functionality, we can make the PMU accessible via the standard CMN-600 binding. In general, PMU registers are non-functional on CMN Fast Models, so this is only meaningful for the real SDP hardware. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Message-Id: <cbeb3832ded539c8c4616d49d3133078a34f88ad.1748350539.git.robin.murphy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2025-12-15arm64: defconfig: Drop duplicate CONFIG_OMAP_USB2 entryLad Prabhakar1-1/+0
CONFIG_OMAP_USB2 is already enabled as a module in the default defconfig since commit 8a703a728a745 ("arm64: defconfig: Enable USB2 PHY Driver"). Remove the duplicate entry to fix the following warning: arch/arm64/configs/defconfig:1705:warning: override: reassigning to symbol OMAP_USB2 Fixes: 91fe3315cdf9f ("arm64: defconfig: Enable missing AMD/Xilinx drivers") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20251015150728.118296-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2025-12-15arm64: defconfig: Enable missing AMD/Xilinx driversMichal Simek1-0/+43
Over years number of upstream drivers have grown for AMD/Xilinx SOCs (ZynqMP, Versal, Versal NET) but they are not enabled by default in defconfig that's why enable all drivers for these SOCs including USB5744 on board USB hub available on Kria ZynqMP based SOMs and Carrier Cards. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/457c3a128e300241afd20da693d1d80a35d1ece6.1758099050.git.michal.simek@amd.com
2025-12-15arm64: dts: xilinx: fix zynqmp opp-table-cpuNeal Frager2-9/+9
Since the following commit, the zynqmp clk driver uses the common divider_round_rate() when determining the appropriate clock divider for a requested clock frequency: https://github.com/torvalds/linux/commit/1fe15be1fb613534ecbac5f8c3f8744f757d237d This means that all the calculations will be in kHz when determining the appropriate clock divider for a given cpufreq request. The problem with this is that the zynqmp.dtsi and zynqmp-clk-ccf.dtsi files have frequency definitions in Hz, so when dividing requested values in kHz, errors can occur with the rounding. For example, the current pss_ref_clk frequency is 33333333 Hz which generates a cpufreq parent clock frequency of 1199999988 Hz which is the same as the highest opp-table-cpu frequency in the zynqmp.dtsi. But if a user requests the value 1199999 kHz as recommended in the available frequencies: root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 299999 399999 599999 1199999 root@zynqmp:/ # echo 1199999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed The calculation will be: 1199999988 / 1199999000 = 1.000001 This will get rounded up to a divider value of 2 giving the following result. root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 599999 Also, if a user tries to work around this calculation by using any larger values, it still will not fix the problem because the driver will use the largest opp in kHz which leads to the same calculation error. User requests 1200000 root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed Driver converts any value greater than 1199999 to the largest opp which is 1199999 and then calculates the divider value with the same calculation. The calculation will still be: 1199999988 / 1199999000 = 1.000001 This will get rounded up to a divider value of 2 giving the following result. root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 599999 This means there is no way to configure the zynqmp for the fastest opp using the current dtsi files. To fix this issue, this patch updates the zynqmp opp-table-cpu and pss_ref_clk, so the clock rates are calculated correctly. root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 400000 600000 1200000 root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 1200000 Signed-off-by: Neal Frager <neal.frager@amd.com> Acked-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20251111070555.1169130-1-neal.frager@amd.com
2025-12-15arm64: dts: xilinx: add soc-specific spi compatibles for zynqmp/versal-netConor Dooley2-4/+4
Unlike zynq, which has a specific compatible for the Cadence spi controller, zynqmp and versal-net do not have specific compatibles. In order to "encourage" people to use soc-specific compatibles for new devices using this IP, add specific compatibles for these devices, with a fallback to the existing compatible for the r1p6 version of the IP so that there will be no functional change. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20251001-cheesy-shucking-c55431bbcae3@spud Signed-off-by: Michal Simek <michal.simek@amd.com>
2025-12-14arm64/simd: Avoid pointless clearing of FP/SIMD bufferArd Biesheuvel1-1/+8
The buffer provided to kernel_neon_begin() is only used if the task is scheduled out while the FP/SIMD is in use by the kernel, or when such a section is interrupted by a softirq that also uses the FP/SIMD. IOW, this happens rarely, and even if it happened often, there is still no reason for this buffer to be cleared beforehand, which happens unconditionally, due to the use of a compound literal expression. So define that buffer variable explicitly, and mark it as __uninitialized so that it will not get cleared, even when -ftrivial-auto-var-init is in effect. This requires some preprocessor gymnastics, due to the fact that the variable must be defined throughout the entire guarded scope, and the expression ({ struct user_fpsimd_state __uninitialized st; &st; }) is problematic in that regard, even though the compilers seem to permit it. So instead, repeat the 'for ()' trick that is also used in the implementation of the guarded scope helpers. Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Kees Cook <keescook@chromium.org> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Fixes: 4fa617cc6851 ("arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack") Link: https://lore.kernel.org/r/20251209054848.998878-2-ardb@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-12-14s390/stacktrace: Do not fallback to RA registerJens Remus1-16/+2
The logic to fallback to the return address (RA) register value in the topmost frame when stack tracing using back chain is broken in multiple ways: When assuming the RA register 14 has not been saved yet one must assume that a new user stack frame has not been allocated either. Therefore the back chain would not contain the stack pointer (SP) at entry, but the caller's SP at its entry instead. Therefore when falling back to the RA register 14 value it would also be necessary to fallback to the SP register 15 value. Otherwise an invalid combination of RA register 14 and caller's SP at its entry (from the back chain) is used. In the topmost frame the back chain contains either the caller's SP at its entry (before having allocated a new stack frame in the prologue), the SP at entry (after having allocated a new stack frame), or an uninitialized value (during static/dynamic stack allocation). In both cases where the back chain is valid either the caller or prologue must have saved its respective RA to the respective frame. Therefore, if the RA obtained from the frame pointed to by the back chain is invalid, this does not indicate that the IP in the topmost frame is still early in the prologue and the RA has not been saved. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-12-14s390/pci: Annotate lock context imbalance in zpci_release_device()Benjamin Block1-0/+1
When checking `arch/s390/pci/pci.c` with `sparse` during build, the following complaint is reported: arch/s390/pci/pci.c: note: in included file (through include/linux/smp.h, include/linux/lockdep.h, include/linux/spinlock.h, include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h): ./include/linux/list.h:237:25: warning: context imbalance in 'zpci_release_device' - unexpected unlock But this is expected, as zpci_release_device() is expected to be called with `zpci_list_lock` held, as part of `kref_put_lock()` or similar. Reflect this by annotating the function with the appropriate __releases(). Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-12-14s390/pci: Fix cyclic dead-lock in zpci_zdev_put() and zpci_scan_devices()Benjamin Block3-29/+90
When triggering PCI device recovery by writing into the SysFS attribute `recover` of a Physical Function with existing child SR-IOV Virtual Functions, lockdep is reporting a possible deadlock between three threads: Thread (A) Thread (B) Thread (C) | | | recover_store() zpci_scan_devices() zpci_scan_devices() lock(pci_rescan_remove_lock) | | | | | | | zpci_bus_scan_busses() | | lock(zbus_list_lock) | zpci_add_device() | | lock(zpci_add_remove_lock) | | | ┴ | | zpci_bus_scan_bus() | | lock(pci_rescan_remove_lock) ┴ | zpci_zdev_put() | lock(zpci_add_remove_lock) | ┴ zpci_bus_get() lock(zbus_list_lock) In zpci_bus_scan_busses() the `zbus_list_lock` is taken for the whole duration of the function, which also includes taking `pci_rescan_remove_lock`, among other things. But `zbus_list_lock` only really needs to protect the modification of the global registration `zbus_list`, it can be dropped while the functions within the list iteration run; this way we break the cycle above. Break up zpci_bus_scan_busses() into an "iterator" zpci_bus_get_next() that iterates over `zbus_list` element by element, and acquires and releases `zbus_list_lock` as necessary, but never keep holding it. References to `zpci_bus` objects are also acquired and released. The reference counting on `zpci_bus` objects is also changed so that all put() and get() operations are done under the protection of `zbus_list_lock`, and if the operation results in a modification of `zpci_bus_list`, this modification is done in the same critical section (apart the very first initialization). This way objects are never seen on the list that are about to be released and/or half-initialized. Fixes: 14c87ba8123a ("s390/pci: separate zbus registration from scanning") Suggested-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-12-14s390/ipl: Clear SBP flag when bootprog is setSven Schnelle2-12/+37
With z16 a new flag 'search boot program' was introduced for list-directed IPL (SCSI, NVMe, ECKD DASD). If this flag is set, e.g. via selecting the "Automatic" value for the "Boot program selector" control on an HMC load panel, it is copied to the reipl structure from the initial ipl structure. When a user now sets a boot prog via sysfs, the flag is not cleared and the bootloader will again automatically select the boot program, ignoring user configuration. To avoid that, clear the SBP flag when a bootprog sysfs file is written. Cc: stable@vger.kernel.org Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-12-14x86/cpu: Drop vestigial PBE logic in AMD/Hygon/Centaur/CyrixAndrew Cooper4-24/+0
Besides formatting changes, this logic dates back to Linux 2.4.0-test11 in November 2000. Prior to "Massive cleanup of CPU detection and bug handling", c->x86_capability was a single u32 containing cpuid(1).edx, cpuid(0x80000001).edx, or a synthesis thereof. X86_FEATURE_AMD3D was defined as the top bit this single u32. After "Massive cleanup of CPU detection and bug handling", c->x86_capability became an array with AMD's extended feature leaf split away from Intel's basic feature leaf. AMD doc #20734-G states that 3DNow is only enumerated in the extended feature leaf, and that other vendors where using this bit too. i.e. AMD never produced a CPU which set bit 31 in the basic leaf, meaning that there's nothing to clear out in the first place. This logic looks like it was relevant in the pre-"Massive cleanup" world but ought to have been dropped when c->x86_capability was properly split. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Pu Wen <puwen@hygon.cn> Link: https://patch.msgid.link/20251126125147.880275-1-andrew.cooper3@citrix.com
2025-12-14x86/cpu/amd: Use ZEN_MODEL_STEP_UCODE() for erratum_1386_microcode[]Andrew Cooper1-2/+2
... to simplify the result. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20251126113442.877024-1-andrew.cooper3@citrix.com
2025-12-14x86/cpu/amd: Correct the microcode table for ZenbleedAndrew Cooper1-21/+9
The good revisions are tied to exact steppings, meaning it's not valid to match on model number alone, let alone a range. This is probably only a latent issue. From public microcode archives, the following CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the model ranges. They're likely pre-production steppings, and likely didn't get Zenbleed microcode, but it's still incorrect to compare them to a different steppings revision. Either way, convert the logic to use x86_match_min_microcode_rev(), which is the preferred mechanism. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: x86@kernel.org Link: https://patch.msgid.link/20251126130352.880424-1-andrew.cooper3@citrix.com
2025-12-14ARM: dts: aspeed: g6: Drop clocks property from arm,armv7-timerAndrew Jeffery1-1/+0
The property is not specified by the binding, nor used by the driver. Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: ast2600-evb: Tidy up A0 work-around for UART5Andrew Jeffery1-0/+1
Changing the compatible changes the properties allowed - snps,dw-apb-uart doesn't specify no-loopback-test, so remove it. Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: g6: Drop unspecified aspeed,ast2600-udma nodeAndrew Jeffery2-13/+0
There's neither a binding defined nor a driver that matches on the compatible, so drop it from the devicetree until someone is motivated to solve the problems. Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: Drop syscon compatible from EDAC in g6 dtsiAndrew Jeffery1-1/+1
Its presence is not required by the binding, its addition was not discussed in commit aac82707fa45 ("ARM: dts: aspeed: Add AST2600 EDAC into common devicetree"), and its inconsistent with the g4 and g5 dtsis. Further, the corresponding driver instantiates its own regmap rather than fetching the syscon regmap, in theory breaking any users of the syscon, but of which there appear to be none in-tree. Drop it for now, and we can add it back with the necessary rework if it's ever required. Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: Use specified wp-inverted property for AST2600 EVBAndrew Jeffery1-2/+2
While sdhci-pltfm supports sdhci,wp-inverted, it also supports the un-prefixed and specified wp-inverted property. Switch the EVB devicetree to use the specified property to remove warnings when checking the DTB. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: Remove sdhci-drive-type property from AST2600 EVBAndrew Jeffery1-2/+0
The property isn't specified in the bindings and is not used by the corresponding driver, so drop it. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: Add NVIDIA MSX4 HPMMarc Olberding2-0/+247
The NVIDIA MSX4 HPM (host platform module) is a reference board for managing up to 8 PCIe connected NVIDIA GPUs via ConnectX-8 (CX8) SuperNICs. The BMC manages all GPUs and CX8s for both telemetry and firmware update via MCTP over USB. The host CPUs are dual socket Intel Granite Rapids processors. For more detail on this architecture: https://developer.nvidia.com/blog/nvidia-connectx-8-supernics-advance-ai-platform-architecture-with-pcie-gen6-connectivity/ Signed-off-by: Marc Olberding <molberding@nvidia.com> Link: https://patch.msgid.link/20251126-msx1_devicetree-v5-2-e508d13e2dda@nvidia.com [arj: Reflow text to wrap at limit, whitespace, grammar] Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: clemente: move hdd_led to its own gpio-leds groupAlex Wang1-1/+6
The gpio-leds driver requires all GPIOs in a group to be available; if any GPIO in the group is not available the whole group will not be created. The hdd_led GPIO is only present after standby power is enabled, which can prevent other LEDs in the same group from being created and blocks properly setting 'bmc_ready_noled'. Move the 'hdd_led' node into a separate gpio-leds group so that other LEDs are not blocked and the 'bmc_ready_noled' flag can be set correctly. Fixes: b5dd16228216 ("ARM: dts: aspeed: clemente: Add HDD LED GPIO") Signed-off-by: Alex Wang <alex.ts.wang@fii-foxconn.com> Link: https://patch.msgid.link/20251127-leo-dts-add-shunt-resistor-v2-1-c77dfbfb826c@fii-foxconn.com [arj: Fix patch subject, add Fixes: tag] Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: clemente: add gpio line name to io expanderKimi Chen1-1/+1
The chassis power cycle process requires a forced shutdown before cutting off the standby power. The SCM CPLD implements a hard shutdown host function that is controlled through the IO expander in the Clemente platform. This change adds a new GPIO line named "shdn_force_l_cpld" to the PCA9555 IO expander's gpio-line-names at index 10. When asserted, this GPIO signals the CPLD to pull the HPM's SHDN_FORCE_L pin low, which triggers a forced host shutdown. Signed-off-by: Kimi Chen <kimi.zy.chen@fii-foxconn.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: santabarbara: Enable ipmb device for OCP debug cardFred Chen1-0/+7
Add an IPMB node for OCP debug card to support IPMI communication. Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: santabarbara: Add swb IO expander and gpio line namesFred Chen1-4/+18
Add IO expander emulated by the switch board CPLD to handle UART and SPI mux control signals. Also add SGPIO labels with FM_MODULE_PWR_EN_N_* signals, which control power to each ASIC module individually. Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: clemente: Add EEPROMs for boot and data drive FRUsLeo Wang1-0/+30
Add EEPROM devices on the I2C buses used for the boot and data NVMe drives. These EEPROMs store FRU information for each drive, allowing the BMC to identify. Signed-off-by: Leo Wang <leo.jt.wang@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: harma: add fanboard presence sgpioDaniel Hsu1-2/+6
Add the SGPIO definition for detecting fanboard presence on the Harma platform. This allows the BMC to determine whether the fanboard is attached. Signed-off-by: Daniel Hsu <Daniel-Hsu@quantatw.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14ARM: dts: aspeed: bletchley: remove WDTRST1 assertion from wdt1Cosmo Chou1-6/+0
Remove the external signal configuration from wdt1 to prevent the WDTRST1 pin from being asserted during watchdog resets. The WDTRST1 pin was originally configured to reset the TPM during watchdog events. However, the pin is incorrectly routed to SRST# on the hardware, causing unintended system resets. Since the TPM is not currently utilized on this platform, remove the external signal configuration to avoid the incorrect reset behavior. Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-14x86/boot/e820: Use <linux/sizes.h> symbols for literalsIngo Molnar1-3/+3
Use the human-readable SZ_* constants. Suggested-by: Nikolay Borisov <nik.borisov@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/92a15c2d-055c-4f4e-b232-32030a8e5e54@suse.com
2025-12-14x86/boot/e820: Make sure e820_search_gap() finds all gapsIngo Molnar1-18/+41
The current implementation of e820_search_gap() searches gaps in a reverse search from MAX_GAP_END back to 0, contrary to what its main comment claims: * Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB). But gaps can not only be beyond E820 RAM ranges, they can be below them as well. For example this function will not find the proper PCI gap for simplified memory map layouts that have a single RAM range that crosses the 4GB boundary. Rework the function to have a proper forward search of E820 table entries. This makes the code somewhat bigger: text data bss dec hex filename 7613 44072 0 51685 c9e5 e820.o.before 7645 44072 0 51717 ca05 e820.o.after but it now both implements what it claims to do, and is more straightforward to read. ( This also allows 'idx' to be the regular u32 again, not an 'int' underflowing to -1. ) Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H . Peter Anvin <hpa@zytor.com> Cc: Andy Shevchenko <andy@kernel.org> Cc: Arnd Bergmann <arnd@kernel.org> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Juergen Gross <jgross@suse.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Paul Menzel <pmenzel@molgen.mpg.de> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://patch.msgid.link/20250515120549.2820541-29-mingo@kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-27 16:57:21 +0300