kernel/git/stable/linux.git/arch/arm, branch linux-6.18.y

syscore: Pass context data to callbacks

2026-09-14T11:36:10+00:00

[ Upstream commit a97fbc3ee3e2a536fafaff04f21f45472db71769 ] Several drivers can benefit from registering per-instance data along with the syscore operations. To achieve this, move the modifiable fields out of the syscore_ops structure and into a separate struct syscore that can be registered with the framework. Add a void * driver data field for drivers to store contextual data that will be passed to the syscore ops. Acked-by: Rafael J. Wysocki (Intel) Signed-off-by: Thierry Reding Stable-dep-of: cee0d90bceae ("Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition") Signed-off-by: Sasha Levin

ARM: dts: helios4: add SATA regulator supplies

2026-09-14T11:35:46+00:00

[ Upstream commit 7a90520e8c9a8f48fe6f3e741cf34d8c2b6dbc61 ] The ahci-mvebu driver and libahci_platform request three supplies on SATA controller and port nodes: - ahci-supply (controller power) - phy-supply (PHY power) - target-supply (disk power per port) Without them the regulator core prints notices at boot, e.g.: supply ahci not found, using dummy regulator supply phy not found, using dummy regulator supply target not found, using dummy regulator The SATA controller and PHY inside the Armada 388 SoC are powered by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD rail. Wire the existing fixed regulators accordingly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

ARM: dts: helios4: add vcc-supply to GPIO expander

2026-09-14T11:35:46+00:00

[ Upstream commit c23988f84496e937dd255564cb30bec67608dcc6 ] The pca953x driver requests a 'vcc' supply, producing: pca953x 0-0020: supply vcc not found, using dummy regulator The PCA9655 (PCA9555-compatible) expander is powered by the same always-on 3.3V rail as the other I2C devices on the bus. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

ARM: dts: helios4: add vcc-supply to EEPROM

2026-09-14T11:35:46+00:00

[ Upstream commit ef65cf08bd1aa723de2854d02fb8eb8cca273c90 ] The at24 driver requests a 'vcc' supply for the EEPROM, producing 'supply vcc not found, using dummy regulator' at boot when the property is missing. The EEPROM sits on the Helios 4 and is powered by the same always-on 3.3V rail used by other on-board I2C devices. Add vcc-supply = <®_3p3v> to silence the warning. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin

ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults

2026-09-14T11:35:36+00:00

[ Upstream commit 1039bffd6ae9c75b42b7d148d6c1106134107b66 ] When CONFIG_DEBUG_USER=y, and cmdline "user_debug=31" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the "oops" state, acquiring a lock may risk a deadlock. Co-developed-by: Qi Xi Fixes: 6d021b724481 ("ARM: dump pgd, pmd and pte states on unhandled data abort faults") Link: https://lore.kernel.org/20260716014022.2823-1-xieyuanbin1@huawei.com Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Linus Walleij Signed-off-by: Qi Xi Signed-off-by: Xie Yuanbin Signed-off-by: Russell King Signed-off-by: Sasha Levin

ARM: 9481/2: breakpoint: CFI breakpoints only on demand

2026-09-14T11:35:36+00:00

[ Upstream commit 8ed9bff906cf8036531d1559f10e82733a52b41f ] This removes the stub hw_breakpoint_cfi_handler() from ARM, making it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless CFI is actively used in the kernel. When not instrumenting with CFI, or when a breakpoint is issued in userspace, we fall through to return 1 from hw_breakpoint_pending() "unhandled fault" so userspace can make use of this breakpoint. Tested with LKDTM and this command line: echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT still works as expected. Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/ Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints") Reported-by: slipher Suggested-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Sasha Levin

ARM: lpc32xx: only run SoC init on LPC32xx hardware

2026-09-14T11:35:08+00:00

[ Upstream commit 717ea4000867e6dffee5e1ed92150a9704ae9f68 ] lpc32xx_check_uid() and lpc32xx_pm_init() are arch_initcalls that poke LPC32xx-only registers. Since the multiplatform conversion they also run on other ARCH_MULTI_V5 boards where access faults e.g. on versatile: Unable to handle kernel paging request at virtual address f4004130 PC is at lpc32xx_check_uid+0x2c/0x9c Drop the arch_initcall() registrations and call both functions directly from lpc3250_machine_init(), the machine's .init_machine hook. The calls are placed in link order (common.c, pm.c, phy3250.c) to keep their previous relative ordering. Fixes: 75bf1bd7d2f9 ("ARM: lpc32xx: allow multiplatform build") Suggested-by: Arnd Bergmann Signed-off-by: Karl Mehltretter Reviewed-by: Vladimir Zapolskiy Reviewed-by: Arnd Bergmann Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sasha Levin

ARM: dts: allwinner: a10: Fix PMU interrupt

2026-09-14T11:35:05+00:00

[ Upstream commit eb7051f756460d7b951e94d9656e31ebb631ba28 ] The Performance Monitoring Unit of the Cortex-A8 cores in the Allwinner A10 SoC is connected to interrupt line 66, not 3. This is shown in the manual (where interrupt 3 is assigned to UART2, also in our .dtsi), but has also been confirmed by triggering an PMU overflow interrupt and inspecting the IRQ controller status registers (from U-Boot). Please note that "perf stat" does not use interrupts, this might explain why this evaded the initial testing. Fixes: 7e345d25c796 ("ARM: dts: sun4i-a10: Add PMU node") Signed-off-by: Andre Przywara Link: https://patch.msgid.link/20260720215128.5761-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin

ARM: imx: fix device_node refcount leaks in imx7_src_init()

2026-09-14T11:34:24+00:00

[ Upstream commit 3de939b2ac843d56d88e2ab1e1b1f667cba9e1d4 ] imx7_src_init() obtains two device_node references via of_find_compatible_node() - one for "fsl,imx7d-src" and one for "fsl,imx7d-gpc" - reusing the same np variable, but never calls of_node_put() on either. On every i.MX7D boot up to two device_node refcounts are leaked: - The "fsl,imx7d-src" node is leaked both when of_iomap() fails (the early return after the mapping) and when it succeeds, because np is then overwritten by the second of_find_compatible_node() call without releasing the prior reference. - The "fsl,imx7d-gpc" node is leaked on every path leaving the function after it is acquired. Release each reference immediately after of_iomap() consumes the node. of_iomap() maps the node's registers but does not retain a reference to the device_node, so it is safe to put the node once mapped; this also drops the first reference before np is reused for the second lookup. Found by static analysis tool CodeQL. Fixes: e34645f45805 ("ARM: imx: add smp support for imx7d") Signed-off-by: Weigang He Signed-off-by: Frank Li Signed-off-by: Sasha Levin

ARM: imx: fix device_node refcount leak in imx_src_init()

2026-09-14T11:34:24+00:00

[ Upstream commit 936407c3563ac745cbbb9953c0cf2472128a22f4 ] imx_src_init() obtains a device_node reference via of_find_compatible_node() matching "fsl,imx51-src" and uses it only to call of_iomap(). It never releases that reference: on the success path the function returns at the end without of_node_put(np), leaking one device_node refcount on every boot of an i.MX5/6 platform. Release the reference right after of_iomap(). of_iomap() maps the node's registers but does not retain a reference to the device_node, so the node can be put once the mapping is done. The early return on a NULL np needs no put. Found by static analysis tool CodeQL. Fixes: bd3d924d71a4 ("ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53") Signed-off-by: Weigang He Signed-off-by: Frank Li Signed-off-by: Sasha Levin