<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/arch/arm, branch linux-5.10.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.10.y</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.10.y'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2026-09-14T11:19:11+00:00</updated>
<entry>
<title>ARM: dts: helios4: add SATA regulator supplies</title>
<updated>2026-09-14T11:19:11+00:00</updated>
<author>
<name>Rosen Penev</name>
<email>rosenp@gmail.com</email>
</author>
<published>2026-07-09T00:50:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=af39b8083d8d2365ecc462d469e8e054e4f1406d'/>
<id>urn:sha1:af39b8083d8d2365ecc462d469e8e054e4f1406d</id>
<content type='text'>
[ 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 &lt;rosenp@gmail.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: helios4: add vcc-supply to GPIO expander</title>
<updated>2026-09-14T11:19:11+00:00</updated>
<author>
<name>Rosen Penev</name>
<email>rosenp@gmail.com</email>
</author>
<published>2026-07-09T00:50:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3206b509efd9cc5e94695dbc6b6e0f7a9291b9dd'/>
<id>urn:sha1:3206b509efd9cc5e94695dbc6b6e0f7a9291b9dd</id>
<content type='text'>
[ 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 = &lt;&amp;reg_3p3v&gt; to silence the warning.

Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev &lt;rosenp@gmail.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: helios4: add vcc-supply to EEPROM</title>
<updated>2026-09-14T11:19:11+00:00</updated>
<author>
<name>Rosen Penev</name>
<email>rosenp@gmail.com</email>
</author>
<published>2026-07-09T00:50:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2ff79256f5142c5ffdab59f2ff527af14501e321'/>
<id>urn:sha1:2ff79256f5142c5ffdab59f2ff527af14501e321</id>
<content type='text'>
[ 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 = &lt;&amp;reg_3p3v&gt; to silence the warning.

Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev &lt;rosenp@gmail.com&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults</title>
<updated>2026-09-14T11:19:09+00:00</updated>
<author>
<name>Xie Yuanbin</name>
<email>xieyuanbin1@huawei.com</email>
</author>
<published>2026-07-28T02:16:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ab14f07952adfe735d86a53518f8cd576dfd5892'/>
<id>urn:sha1:ab14f07952adfe735d86a53518f8cd576dfd5892</id>
<content type='text'>
[ 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 &lt; TASK_SIZE). This is because
the lock of tsk-&gt;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 &lt;xiqi2@huawei.com&gt;

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) &lt;ljs@kernel.org&gt;
Reviewed-by: Linus Walleij &lt;linusw@kernel.org&gt;
Signed-off-by: Qi Xi &lt;xiqi2@huawei.com&gt;
Signed-off-by: Xie Yuanbin &lt;xieyuanbin1@huawei.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: lpc32xx: only run SoC init on LPC32xx hardware</title>
<updated>2026-09-14T11:19:03+00:00</updated>
<author>
<name>Karl Mehltretter</name>
<email>kmehltretter@gmail.com</email>
</author>
<published>2026-07-13T19:25:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=28ebe062adc9967c42edcb2142d6f9c20195c1a3'/>
<id>urn:sha1:28ebe062adc9967c42edcb2142d6f9c20195c1a3</id>
<content type='text'>
[ 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 &lt;arnd@arndb.de&gt;
Signed-off-by: Karl Mehltretter &lt;kmehltretter@gmail.com&gt;
Reviewed-by: Vladimir Zapolskiy &lt;vz@kernel.org&gt;
Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Vladimir Zapolskiy &lt;vz@mleia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: dts: allwinner: a10: Fix PMU interrupt</title>
<updated>2026-09-14T11:19:02+00:00</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2026-07-20T21:51:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=045eb7d43c0ca108aa9b812c0e551c9e65c425be'/>
<id>urn:sha1:045eb7d43c0ca108aa9b812c0e551c9e65c425be</id>
<content type='text'>
[ 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 &lt;andre.przywara@arm.com&gt;
Link: https://patch.msgid.link/20260720215128.5761-1-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai &lt;wens@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: imx: fix device_node refcount leak in imx_src_init()</title>
<updated>2026-09-14T11:18:53+00:00</updated>
<author>
<name>Weigang He</name>
<email>geoffreyhe2@gmail.com</email>
</author>
<published>2026-06-10T05:06:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=111c315f10d9fe99c43d39dd28c43efcb30ecb74'/>
<id>urn:sha1:111c315f10d9fe99c43d39dd28c43efcb30ecb74</id>
<content type='text'>
[ 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 &lt;geoffreyhe2@gmail.com&gt;
Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ARM: npcm: Fix OF node refcount leaks in SMP setup</title>
<updated>2026-08-19T15:12:11+00:00</updated>
<author>
<name>Yuho Choi</name>
<email>dbgh9129@gmail.com</email>
</author>
<published>2026-05-25T03:38:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=233bf02dafee18f3385a7f71b11587788a9daaf9'/>
<id>urn:sha1:233bf02dafee18f3385a7f71b11587788a9daaf9</id>
<content type='text'>
[ Upstream commit 8eb052f48331474c2789d07b7f11165c323bd2f9 ]

npcm7xx_smp_boot_secondary() and npcm7xx_smp_prepare_cpus() look up
the GCR and SCU nodes with of_find_compatible_node(). The returned
nodes are used for of_iomap(), but the node references are never
released.

of_iomap() does not consume the device node reference, and iounmap()
only releases the MMIO mapping. Drop each node reference after the
corresponding mapping attempt.

Fixes: 7bffa14c9aed ("arm: npcm: add basic support for Nuvoton BMCs")
Signed-off-by: Yuho Choi &lt;dbgh9129@gmail.com&gt;
Reviewed-by: Avi Fishman &lt;avifishman70@gmail.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@codeconstruct.com.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: pca953x: Make platform teardown callback return void</title>
<updated>2026-07-24T13:49:22+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2026-07-20T02:35:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9e59e2152c2794eb118f16bd9d82c4abc65974ce'/>
<id>urn:sha1:9e59e2152c2794eb118f16bd9d82c4abc65974ce</id>
<content type='text'>
[ Upstream commit 6a8f359c3132e4f51bdb263ad74ec632c65e55fd ]

All platforms that provide a teardown callback return 0. New users are
supposed to not make use of platform support, so there is no
functionality lost.

This patch is a preparation for making i2c remove callbacks return void.

Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Acked-by: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Stable-dep-of: 1f0bdc2884b6 ("usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ARM: imx31: Fix IIM mapping leak in revision check</title>
<updated>2026-07-24T13:48:58+00:00</updated>
<author>
<name>Yuho Choi</name>
<email>dbgh9129@gmail.com</email>
</author>
<published>2026-05-25T04:01:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a7d800bd2fc7da02f54f5e25e81d48ce2ffde4b4'/>
<id>urn:sha1:a7d800bd2fc7da02f54f5e25e81d48ce2ffde4b4</id>
<content type='text'>
[ Upstream commit ccb4b54b8ecf1ebafef96d538cd6c5c8455bb390 ]

mx31_read_cpu_rev() maps the IIM registers with of_iomap() to read the
silicon revision, but returns without unmapping the MMIO mapping.

Keep the normalized revision value in a local variable and route the
return path through iounmap() after the revision register has been read.

Fixes: 3172225d45bd ("ARM: imx31: Retrieve the IIM base address from devicetree")
Signed-off-by: Yuho Choi &lt;dbgh9129@gmail.com&gt;
Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
