summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-09dt-bindings: misc: Add device specific bindings for RaspberryPi RP1Andrea della Porta
The RP1 is a MFD that exposes its peripherals through PCI BARs. This schema is intended as minimal support for the clock generator and gpio controller peripherals which are accessible through BAR1. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-3-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09dt-bindings: pinctrl: Add RaspberryPi RP1 gpio/pinctrl/pinmux bindingsAndrea della Porta
Add device tree bindings for the gpio/pin/mux controller that is part of the RP1 multi function device, and relative entries in MAINTAINERS file. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-2-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09dt-bindings: clock: Add RaspberryPi RP1 clock bindingsAndrea della Porta
Add device tree bindings for the clock generator found in RP1 multi function device, and relative entries in MAINTAINERS file. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20250529135052.28398-1-andrea.porta@suse.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm63158: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA blocks for the BCM63158 based on the vendor files 63158_map_part.h and 63158_intr.h from the "bcmopen-consumer" code drop. The DTSI file has clearly been authored for the B0 revision of the SoC: there is an earlier A0 version, but this has the UARTs in the legacy PERF memory space, while the B0 has opened a new peripheral window at 0xff812000 for the three UARTs. It also has a designated AHB peripheral area at 0xff810000 where the DMA resides, the peripheral range window fits these two peripheral groups. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-12-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm6858: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. ARM64 SoCs have additional peripherals at 0xff858000. Extend the peripheral window range to 0x400000 and add the DMA controller at offset 0x59000. Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA blocks for the BCM6858 based on the vendor files 6858_map_part.h and 6858_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-11-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm6856: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. ARM64 SoCs have additional peripherals at 0xff858000. Extend the BCM6856 the PERF window to 0x400000 and add the DMA block at offset 0x59000. Add the watchdog, GPIO blocks, RNG, LED, second UART and DMA blocks for the BCM6856 based on the vendor files 6856_map_part.h and 6856_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 256 possible GPIOs due to having 8 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-10-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARM64: dts: bcm4908: Add BCMBCA peripheralsLinus Walleij
All the BCMBCA SoCs share a set of peripherals at 0xff800000, albeit at slightly varying memory locations on the bus and with varying IRQ assignments. ARM64 SoCs have additional peripherals at 0xff858000, we extend the peripheral bus range to 0x400000 to cover this area. Add the watchdog, remaining GPIO blocks, RNG, and DMA blocks for the BCM4908 based on the vendor files 4908_map_part.h and 4908_intr.h from the "bcmopen-consumer" code drop. This SoC has up to 320 possible GPIOs due to having 10 registers with 32 GPIOs in each available. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20250512-bcmbca-peripherals-arm-v3-9-86f97ab4326f@linaro.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-09ARC: Replace __ASSEMBLY__ with __ASSEMBLER__ in the non-uapi headersThomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize on the __ASSEMBLER__ macro that is provided by the compilers now. This is a completely mechanical patch (done with a simple "sed -i" statement). Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2025-06-09ARC: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headersThomas Huth
__ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for uapi headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2025-06-09ARC: unwind: Use built-in sort swap to reduce code size and improve performanceYu-Chun Lin
The custom swap function used in sort() was identical to the default built-in sort swap. Remove the custom swap function and passes NULL to sort(), allowing it to use the default swap function. This change reduces code size and improves performance, particularly when CONFIG_MITIGATION_RETPOLINE is enabled. With RETPOLINE mitigation, indirect function calls incur significant overhead, and using the default swap function avoids this cost. $ ./scripts/bloat-o-meter ./unwind.o.old ./unwind.o.new add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-22 (-22) Function old new delta init_unwind_hdr.constprop 544 540 -4 swap_eh_frame_hdr_table_entries 18 - -18 Total: Before=4410, After=4388, chg -0.50% Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2025-06-09ARC: atomics: Implement arch_atomic64_cmpxchg using _relaxedJason Gunthorpe
The core atomic code has a number of macros where it elaborates architecture primitives into more functions. ARC uses arch_atomic64_cmpxchg() as it's architecture primitive which disable alot of the additional functions. Instead provide arch_cmpxchg64_relaxed() as the primitive and rely on the core macros to create arch_cmpxchg64(). The macros will also provide other functions, for instance, try_cmpxchg64_release(), giving a more complete implementation. Suggested-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/Z0747n5bSep4_1VX@J2N7QTR9R3 Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2025-06-09cpupower: split unitdir from libdir in MakefileFrancesco Poli (wintermute)
Improve the installation procedure for the systemd service unit 'cpupower.service', to be more flexible. Some distros install libraries to /usr/lib64/, but systemd service units have to be installed to /usr/lib/systemd/system: as a consequence, the installation procedure should not assume that systemd service units can be installed to ${libdir}/systemd/system ... Define a dedicated variable ("unitdir") in the Makefile. Link: https://lore.kernel.org/linux-pm/260b6d79-ab61-43b7-a0eb-813e257bc028@leemhuis.info/T/#m0601940ab439d5cbd288819d2af190ce59e810e6 Fixes: 9c70b779ad91 ("cpupower: add a systemd service to run cpupower") Link: https://lore.kernel.org/r/20250521211656.65646-1-invernomuto@paranoici.org Signed-off-by: Francesco Poli (wintermute) <invernomuto@paranoici.org> Tested-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-06-09selftests/x86: Add a test to detect infinite SIGTRAP handler loopXin Li (Intel)
When FRED is enabled, if the Trap Flag (TF) is set without an external debugger attached, it can lead to an infinite loop in the SIGTRAP handler. To avoid this, the software event flag in the augmented SS must be cleared, ensuring that no single-step trap remains pending when ERETU completes. This test checks for that specific scenario—verifying whether the kernel correctly prevents an infinite SIGTRAP loop in this edge case when FRED is enabled. The test should _always_ pass with IDT event delivery, thus no need to disable the test even when FRED is not enabled. Signed-off-by: Xin Li (Intel) <xin@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Sohil Mehta <sohil.mehta@intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-3-xin%40zytor.com
2025-06-09x86/fred/signal: Prevent immediate repeat of single step trap on return from ↵Xin Li (Intel)
SIGTRAP handler Clear the software event flag in the augmented SS to prevent immediate repeat of single step trap on return from SIGTRAP handler if the trap flag (TF) is set without an external debugger attached. Following is a typical single-stepping flow for a user process: 1) The user process is prepared for single-stepping by setting RFLAGS.TF = 1. 2) When any instruction in user space completes, a #DB is triggered. 3) The kernel handles the #DB and returns to user space, invoking the SIGTRAP handler with RFLAGS.TF = 0. 4) After the SIGTRAP handler finishes, the user process performs a sigreturn syscall, restoring the original state, including RFLAGS.TF = 1. 5) Goto step 2. According to the FRED specification: A) Bit 17 in the augmented SS is designated as the software event flag, which is set to 1 for FRED event delivery of SYSCALL, SYSENTER, or INT n. B) If bit 17 of the augmented SS is 1 and ERETU would result in RFLAGS.TF = 1, a single-step trap will be pending upon completion of ERETU. In step 4) above, the software event flag is set upon the sigreturn syscall, and its corresponding ERETU would restore RFLAGS.TF = 1. This combination causes a pending single-step trap upon completion of ERETU. Therefore, another #DB is triggered before any user space instruction is executed, which leads to an infinite loop in which the SIGTRAP handler keeps being invoked on the same user space IP. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Suggested-by: H. Peter Anvin (Intel) <hpa@zytor.com> Signed-off-by: Xin Li (Intel) <xin@zytor.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Sohil Mehta <sohil.mehta@intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-2-xin%40zytor.com
2025-06-09spi: stm32-ospi: Make usage of reset_control_acquire/release() APIPatrice Chotard
As ospi reset is consumed by both OMM and OSPI drivers, use the reset acquire/release mechanism which ensure exclusive reset usage. This avoid to call reset_control_get/put() in OMM driver each time we need to reset OSPI children and guarantee the reset line stays deasserted. During resume, OMM driver takes temporarily control of reset. Fixes: 79b8a705e26c ("spi: stm32: Add OSPI driver") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patch.msgid.link/20250609-b4-upstream_ospi_reset_update-v6-1-5b602b567e8a@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-09drm/xe/svm: Fix regression disallowing 64K SVM migrationMaarten Lankhorst
When changing the condition from >= SZ_64K, it was changed to <= SZ_64K. This disallows migration of 64K, which is the exact minimum allowed. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5057 Fixes: 794f5493f518 ("drm/xe: Strict migration policy for atomic SVM faults") Cc: stable@vger.kernel.org Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://lore.kernel.org/r/20250521090102.2965100-1-dev@lankhorst.se (cherry picked from commit 531bef26d189b28bf0d694878c0e064b30990b6c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-09accel/amdxdna: Fix incorrect PSP firmware sizeLizhi Hou
The incorrect PSP firmware size is used for initializing. It may cause error for newer version firmware. Fixes: 8c9ff1b181ba ("accel/amdxdna: Add a new driver for AMD AI Engine") Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/20250604143217.1386272-1-lizhi.hou@amd.com
2025-06-09spi: offload: check offload ops existence before disabling the triggerAndres Urian Florez
Add a safe guard in spi_offload_trigger to check the existence of offload->ops before invoking the trigger_disable callback Signed-off-by: Andres Urian Florez <andres.emb.sys@gmail.com> Link: https://patch.msgid.link/20250608230422.325360-1-andres.emb.sys@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-09arm64: dts: rockchip: drop touch panel display from rockpro64Peter Robinson
The touch panel display is an optional add on for the RockPro64 so this should be an DT overlay, drop the panel options in preparation to add this as an overlay. This effectively reverts commit b65155c786c4 so as to add an overlay for it. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20250518215944.178582-1-pbrobinson@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: Use standard PHY reset properties for RK3576 ArmSoM Sige5John Clark
Replace deprecated snps,reset-gpio, snps,reset-active-low, and snps,reset-delays-us in gmac0 and gmac1 nodes with standard reset-gpios, reset-assert-us, and reset-deassert-us in rgmii_phy0 and rgmii_phy1 nodes. Add pinctrl properties to PHY nodes and define gmac0_rst and gmac1_rst in pinctrl node. Reorder phy-handle for consistency. Signed-off-by: John Clark <inindev@gmail.com> Link: https://lore.kernel.org/r/20250520003332.163124-2-inindev@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: add ROCK 5T device treeNicolas Frattaroli
The RADXA ROCK 5T is a single board computer quite similar to the ROCK 5B+, except it has one more PCIe-to-Ethernet controller (at the expense of a USB3 port) and a barrel jack for power input instead. Some pins are shuffled around as well. Add a device tree for it. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250520-add-rock5t-v2-4-1f1971850a20@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: move common ROCK 5B/+ nodes into own treeNicolas Frattaroli
A few device tree nodes are shared between ROCK 5B and ROCK 5B+ that are not shared with ROCK 5T. Move them into their own device tree include. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250520-add-rock5t-v2-3-1f1971850a20@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: rename rk3588-rock-5b.dtsiNicolas Frattaroli
As subsequent patches will add ROCK 5T support, rename the .dtsi file to reflect that it's shared between ROCK 5B, ROCK 5B+ and ROCK 5T. This is done separately from moving the 5B and 5B+ only nodes to a common tree so that the history stays bisectable and the diff easily reviewable. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250520-add-rock5t-v2-2-1f1971850a20@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09dt-bindings: arm: rockchip: add RADXA ROCK 5TNicolas Frattaroli
The RADXA ROCK 5T is a single board computer aimed at industrial use. Its design is similar to the ROCK 5B+, but it does away with one of the USB-C PD inputs, and uses one combination USB3/SATA/PCIe PHY for an additional second 2.5G PCIe network card instead of USB3. Link: https://radxa.com/products/rock5/5t/ Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250520-add-rock5t-v2-1-1f1971850a20@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: Add spi nodes for RK3528Chukun Pan
There are 2 SPI controllers on the RK3528 SoC, describe it. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://lore.kernel.org/r/20250520100102.1226725-3-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: add DTs for Sakura Pi RK3308BHsun Lai
The Sakura Pi RK3308B is a SBC based on the Rockchip RK3308 SoC. Link: https://github.com/Sakura-Pi Link: https://docs.sakurapi.org/article/sakurapi-rk3308b/introduce The device contains the following hardware that is tested/working: - 4 or 8GB eMMC - SDMMC card slot - Realtek SDIO WiFi 5/BT - 256 or 512MB of RAM - USB 2.0 port - OTG port Signed-off-by: Hsun Lai <i@chainsx.cn> Link: https://lore.kernel.org/r/20250521131108.5710-4-i@chainsx.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09dt-bindings: arm: rockchip: Add Sakura Pi RK3308BHsun Lai
This patch adds device tree binding support for Sakura Pi RK3308B, with compatibility for the Rockchip RK3308 SoC. Link: https://docs.sakurapi.org/article/sakurapi-rk3308b/introduce Signed-off-by: Hsun Lai <i@chainsx.cn> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250521131108.5710-3-i@chainsx.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09dt-bindings: vendor-prefixes: Add SakuraPi prefixHsun Lai
Add vendor prefix for SakuraPi.org, which produces development boards like the SakuraPi-RK3308B. Link: https://docs.sakurapi.org Signed-off-by: Hsun Lai <i@chainsx.cn> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250521131108.5710-2-i@chainsx.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: Fix cover detection on PineNoteDiederik de Haas
The SW_MACHINE_COVER switch event was added to input event codes to detect the removal of the back cover of the N900. But on the PineNote its purpose is to detect when the front cover gets closed, just like when a laptop lid is closed. Therefore SW_LID is the appropriate linux code and not SW_MACHINE_COVER. Reported-by: hrdl <git@hrdl.eu> Helped-by: phantomas <phantomas@phantomas.xyz> Link: https://lore.kernel.org/r/270f27c9-afd6-171d-7dce-fe1d71dd8f9a@wizzup.org/ Signed-off-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250526161506.139028-1-didi.debian@cknow.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: Document unused device on i2c1Chris Morgan
Update the i2c1 bus noting that the unknown/unused device at 0x3c is an iSmartWare SW2001 "encryption IC". Based on the documentation I was able to find, this IC appears to be used to authenticate a device for certain programs to ensure they only run on authorized devices as a form of digital rights management. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20250604024119.381337-1-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: support Ethernet Switch adapter for RK3588 JaguarQuentin Schulz
This adds support for the Ethernet Switch adapter connected to the mezzanine connector on RK3588 Jaguar. This adapter has a KSZ9896 Ethernet Switch with 4 1GbE Ethernet connectors, two user controllable LEDs, and an M12 12-pin connector which exposes the following signals: - RS232/RS485 (max 250Kbps/500Kbps, RX pin1, TX pin2) - two digital inputs (pin4 routed to GPIO3_C5 on SoC, pin5 to GPIO4_B4) - two digital outputs (pin7 routed to GPIO3_D3 on SoC, pin8 to GPIO3_D1) - two analog inputs (pin10 to channel1 of ADS1015, pin11 to channel2) Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> [Andrew's review for gmac1 and switch@5f parts] Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20250604-jaguar-mezz-eth-switch-v3-1-c68123240f9e@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09arm64: dts: rockchip: Add DSI panel support for gameforce-aceChris Morgan
Enable the DSI controller, DSI DCPHY, and Huiling hl055fhav028c 1080x1920 panel for the Gameforce Ace. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250603193930.323607-5-macroalpha82@gmail.com [moved lcd_rst pin into a lcd pinctrl group with lcd_bl_en] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-09pinctrl: tb10x: Drop of_match_ptr for ID tableKrzysztof Kozlowski
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it might not be relevant here). This also fixes !CONFIG_OF warning: pinctrl-tb10x.c:815:34: warning: unused variable 'tb10x_pinctrl_dt_ids' [-Wunused-const-variable] Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505301317.EI1caRC0-lkp@intel.com/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/20250601105100.27927-2-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-09pinctrl: MAINTAINERS: Drop bouncing Jianlong HuangKrzysztof Kozlowski
Emails to Jianlong Huang bounce since 9 months, so drop the person from maintainers: 550 5.4.1 Recipient address rejected: Access denied. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/20250528104514.184122-2-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-09pinctrl: st: Drop unused st_gpio_bank() functionKrzysztof Kozlowski
Static inline st_gpio_bank() function is not referenced: pinctrl-st.c:377:19: error: unused function 'st_gpio_bank' [-Werror,-Wunused-function] Fixes: 701016c0cba5 ("pinctrl: st: Add pinctrl and pinconf support.") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/20250528092201.52132-2-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-09pinctrl: qcom: pinctrl-qcm2290: Add missing pinsWojciech Slenska
Added the missing pins to the qcm2290_pins table. Signed-off-by: Wojciech Slenska <wojciech.slenska@gmail.com> Fixes: 48e049ef1238 ("pinctrl: qcom: Add QCM2290 pinctrl driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/20250523101437.59092-1-wojciech.slenska@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-09pinctrl: qcom: switch to devm_gpiochip_add_data()Dmitry Baryshkov
In order to simplify cleanup actions, use devres-enabled version of gpiochip_add_data(). As the msm_pinctrl_remove() function is now empty, drop it and all its calls from the corresponding pinctrl drivers. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/20250513-pinctrl-msm-fix-v2-3-249999af0fc1@oss.qualcomm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-06-09ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP ↵Edip Hazuri
Victus 15-fa1xxx The mute led on those laptops is using ALC245 but requires a quirk to work This patch enables the existing quirk for the devices. Tested on my Victus 16-s1011nt Laptop and my friend's Victus 15-fa1xxx. The LED behaviour works as intended. Cc: <stable@vger.kernel.org> Signed-off-by: Edip Hazuri <edip@medip.dev> Link: https://patch.msgid.link/20250609075943.13934-2-edip@medip.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-09ALSA: ctxfi: Replace deprecated strcpy() with strscpy()Brahmajit Das
strcpy() is deprecated; use strscpy() instead. Use strscpy() to copy the long name because there's no string to format with sprintf(). No functional changes intended. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Brahmajit Das <listout@listout.xyz> Link: https://patch.msgid.link/20250606204000.8156-1-listout@listout.xyz Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-09x86/platform/amd: replace down_timeout() with down_interruptible()Jake Hillion
Currently hsmp_send_message() uses down_timeout() with a 100ms timeout to take the semaphore. However __hsmp_send_message(), the content of the critical section, has a sleep in it. On systems with significantly delayed scheduling behaviour this may take over 100ms. Convert this method to down_interruptible(). Leave the error handling the same as the documentation currently is not specific about what error is returned. Previous behaviour: a caller who competes with another caller stuck in the critical section due to scheduler delays would receive -ETIME. New behaviour: a caller who competes with another caller stuck in the critical section due to scheduler delays will complete successfully. Reviewed-by: Suma Hegde <suma.hegde@amd.com> Tested-by: Suma Hegde <suma.hegde@amd.com> Signed-off-by: Jake Hillion <jake@hillion.co.uk> Link: https://lore.kernel.org/r/20250605-amd-hsmp-v2-2-a811bc3dd74a@hillion.co.uk Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09x86/platform/amd: move final timeout check to after final sleepJake Hillion
__hsmp_send_message sleeps between result read attempts and has a timeout of 100ms. Under extreme load it's possible for these sleeps to take a long time, exceeding the 100ms. In this case the current code does not check the register and fails with ETIMEDOUT. Refactor the loop to ensure there is at least one read of the register after a sleep of any duration. This removes instances of ETIMEDOUT with a single caller, even with a misbehaving scheduler. Tested on AMD Bergamo machines. Suggested-by: Blaise Sanouillet <linux@blaise.sanouillet.com> Reviewed-by: Suma Hegde <suma.hegde@amd.com> Tested-by: Suma Hegde <suma.hegde@amd.com> Signed-off-by: Jake Hillion <jake@hillion.co.uk> Link: https://lore.kernel.org/r/20250605-amd-hsmp-v2-1-a811bc3dd74a@hillion.co.uk Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09platform/x86/amd: pmc: Clear metrics table at start of cycleMario Limonciello
The area of memory that contains the metrics table may contain garbage when the cycle starts. This normally doesn't matter because the cycle itself will populate it with valid data, however commit 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") started to use it during the check() phase. Depending upon what garbage is in the table it's possible that the system will wait 2.5 seconds for even the first cycle, which will be visible to a user. To prevent this from happening explicitly clear the table when logging is started. Fixes: 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250603132412.3555302-1-superm1@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09platform/x86/intel: power-domains: Fix error code in tpmi_init()Dan Carpenter
Return -ENOMEM instead of success if kcalloc() fails. Fixes: e37be5d85c60 ("platform/x86/intel: power-domains: Add interface to get Linux die ID") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/aEKvIGCt6d8Gcx4S@stanley.mountain Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09platform/x86: samsung-galaxybook: Add SAM0426Joshua Grisham
Add device ID SAM0426 (Notebook 9 Pro and similar devices) as reported and tested by GitHub user "diego-karsa" [1]. [1]: https://github.com/joshuagrisham/samsung-galaxybook-extras/issues/69 Signed-off-by: Joshua Grisham <josh@joshuagrisham.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250606130909.207047-1-josh@joshuagrisham.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09ALSA: hda/intel: Add Thinkpad E15 to PM deny listTakashi Iwai
Lenovo Thinkpad E15 with Conexant CX8070 codec seems causing ugly noises after runtime-PM suspend. Disable the codec runtime PM as a workaround. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220210 Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20250608091415.21170-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-06-09platform/x86/intel-uncore-freq: Fail module load when plat_info is NULLSrinivas Pandruvada
Address a Smatch static checker warning regarding an unchecked dereference in the function call: set_cdie_id(i, cluster_info, plat_info) when plat_info is NULL. Instead of addressing this one case, in general if plat_info is NULL then it can cause other issues. For example in a two package system it will give warning for duplicate sysfs entry as package ID will be always zero for both packages when creating string for attribute group name. plat_info is derived from TPMI ID TPMI_BUS_INFO, which is integral to the core TPMI design. Therefore, it should not be NULL on a production platform. Consequently, the module should fail to load if plat_info is NULL. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/platform-driver-x86/aEKvGCLd1qmX04Tc@stanley.mountain/T/#u Fixes: 8a54e2253e4c ("platform/x86/intel-uncore-freq: Uncore frequency control via TPMI") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250606205300.2384494-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09platform/x86: ideapad-laptop: use usleep_range() for EC pollingRong Zhang
It was reported that ideapad-laptop sometimes causes some recent (since 2024) Lenovo ThinkBook models shut down when: - suspending/resuming - closing/opening the lid - (dis)connecting a charger - reading/writing some sysfs properties, e.g., fan_mode, touchpad - pressing down some Fn keys, e.g., Brightness Up/Down (Fn+F5/F6) - (seldom) loading the kmod The issue has existed since the launch day of such models, and there have been some out-of-tree workarounds (see Link:) for the issue. One disables some functionalities, while another one simply shortens IDEAPAD_EC_TIMEOUT. The disabled functionalities have read_ec_data() in their call chains, which calls schedule() between each poll. It turns out that these models suffer from the indeterminacy of schedule() because of their low tolerance for being polled too frequently. Sometimes schedule() returns too soon due to the lack of ready tasks, causing the margin between two polls to be too short. In this case, the command is somehow aborted, and too many subsequent polls (they poll for "nothing!") may eventually break the state machine in the EC, resulting in a hard shutdown. This explains why shortening IDEAPAD_EC_TIMEOUT works around the issue - it reduces the total number of polls sent to the EC. Even when it doesn't lead to a shutdown, frequent polls may also disturb the ongoing operation and notably delay (+ 10-20ms) the availability of EC response. This phenomenon is unlikely to be exclusive to the models mentioned above, so dropping the schedule() manner should also slightly improve the responsiveness of various models. Fix these issues by migrating to usleep_range(150, 300). The interval is chosen to add some margin to the minimal 50us and considering EC responses are usually available after 150-2500us based on my test. It should be enough to fix these issues on all models subject to the EC bug without introducing latency on other models. Tested on ThinkBook 14 G7+ ASP and solved both issues. No regression was introduced in the test on a model without the EC bug (ThinkBook X IMH, thanks Eric). Link: https://github.com/ty2/ideapad-laptop-tb2024g6plus/commit/6c5db18c9e8109873c2c90a7d2d7f552148f7ad4 Link: https://github.com/ferstar/ideapad-laptop-tb/commit/42d1e68e5009529d31bd23f978f636f79c023e80 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218771 Fixes: 6a09f21dd1e2 ("ideapad: add ACPI helpers") Cc: stable@vger.kernel.org Tested-by: Felix Yan <felixonmars@archlinux.org> Tested-by: Eric Long <i@hack3r.moe> Tested-by: Jianfei Zhang <zhangjianfei3@gmail.com> Tested-by: Mingcong Bai <jeffbai@aosc.io> Tested-by: Minh Le <minhld139@gmail.com> Tested-by: Sicheng Zhu <Emmet_Z@outlook.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://lore.kernel.org/r/20250525201833.37939-1-i@rong.moe Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-09drm/msm/dsi/dsi_phy_10nm: Fix missing initial VCO rateKrzysztof Kozlowski
Driver unconditionally saves current state on first init in dsi_pll_10nm_init(), but does not save the VCO rate, only some of the divider registers. The state is then restored during probe/enable via msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() -> dsi_10nm_pll_restore_state(). Restoring calls dsi_pll_10nm_vco_set_rate() with pll_10nm->vco_current_rate=0, which basically overwrites existing rate of VCO and messes with clock hierarchy, by setting frequency to 0 to clock tree. This makes anyway little sense - VCO rate was not saved, so should not be restored. If PLL was not configured configure it to minimum rate to avoid glitches and configuring entire in clock hierarchy to 0 Hz. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/sz4kbwy5nwsebgf64ia7uq4ee7wbsa5uy3xmlqwcstsbntzcov@ew3dcyjdzmi2/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Fixes: a4ccc37693a2 ("drm/msm/dsi_pll_10nm: restore VCO rate during Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/654796/ Link: https://lore.kernel.org/r/20250520111325.92352-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-09drm/msm/disp: Correct porch timing for SDM845James A. MacInnes
Type-C DisplayPort inoperable due to incorrect porch settings. - Re-used wide_bus_en as flag to prevent porch shifting Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: James A. MacInnes <james.a.macinnes@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/636945/ Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-2-4954e51458f4@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-09drm/msm/dp: Disable wide bus support for SDM845James A. MacInnes
When widebus was enabled for DisplayPort in commit c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets") it was clarified that it is only supported on DPU 5.0.0 onwards which includes SC7180 on DPU revision 6.2. However, this patch missed that the description structure for SC7180 is also reused for SDM845 (because of identical io_start address) which is only DPU 4.0.0, leading to a wrongly enbled widebus feature and corruption on that platform. Create a separate msm_dp_desc_sdm845 structure for this SoC compatible, with the wide_bus_supported flag turned off. Fixes: c7c412202623 ("drm/msm/dp: enable widebus on all relevant chipsets") Signed-off-by: James A. MacInnes <james.a.macinnes@gmail.com> [DB: reworded commit text following Marijn's suggestion] Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/636944/ Link: https://lore.kernel.org/r/20250212-sdm845_dp-v2-1-4954e51458f4@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>