The effort to remove legacy Arm support from Linux has become a concrete set of patches. On September 8, 2026, kernel developer Arnd Bergmann posted 13 changes that, by the first tally, delete 55,679 lines. The proposal moves from deprecation in Linux 7.3 toward removal, but reading names like STM32 and PXA as the end of support for an entire product family would misjudge its scope. Some machines in the same family remain. The proposal selects among CPU revisions that are hard to maintain and older board support that was never migrated. What can be kept depends on the age of the hardware, but also on who still uses it with current Linux and on the state of the implementation. Bergmann's proposal shows where those boundaries lie.
Starting with 13 patches, and the roles of 7.4 and 7.5
The first posting changes 371 files, adding 115 lines and deleting 55,679. The deleted lines include not only executable code but also configuration files and device trees, which describe hardware configuration. The figure therefore reflects the size of the source-tree cleanup. It is not a measurement of kernel execution speed or of how much smaller the binaries installed on each device would become.
The 13 patches are also only the first batch of the overall cleanup. According to Bergmann, the work grew larger than expected and now stands at 300 patches on his machine, some of which need to be split into smaller changes. What he submitted this time is mainly machine-specific implementation and the parts that depend directly on the configuration options being removed and are easy to eliminate.
The timeline has to be read by type of work. The September 8 cover letter divides it as follows.
| Stage | Target | Description at time of posting |
|---|---|---|
| Deprecation | Marks old machines and features for removal | To be done in Linux 7.3, with support kept for LTS use |
| Machine support removal (this batch) | Machine-specific implementation and some directly dependent code | Original removal target is 7.4; the 13 patches were posted |
| Follow-up cleanup | Drivers and architecture features that become unused | Some could go into 7.4, but many target 7.5 to simplify dependencies |
This table matches the targets and timing in Bergmann's first posting. The description of 7.5 as the main target refers to the follow-up cleanup not included in this batch. It does not mean all 13 patches are postponed to 7.5, nor that any of them is confirmed for a particular release.
Removing the machine-specific code first makes it easier to identify, afterward, the drivers that only that code used. On the other hand, while the corresponding drivers have not yet all disappeared, active users have time to say they need them. Bergmann explicitly mentions this grace period.
Where removal ends differently for STM32 and PXA
For STM32, the microcontrollers being removed are clearly separated from the application-class SoCs that remain. For PXA, removing the old board files still leaves support for machines that boot using device trees. Comparing what each patch says it removes and what remains reveals differences that a list of product names does not.
| Family | Support being removed now | Scope that remains / distinctions stated in the patch |
|---|---|---|
| PXA | Old board files left behind without migration | Raumfeld speakers with PXA300. Basic PXA250/PXA270 support also remains and may work with external device trees |
| Orion / Dove | Remaining old board files | Orion5x and Dove have device-tree support for other machines |
| i.MX31 | Support for the SoC using ARM1136r0 | i.MX35, which uses ARM1136r1, does not have the same problem, and the patch says there is no reason to remove it |
| i.MX without an MMU | Support for running Linux on the Cortex-M side, etc. | For example, Linux on the Cortex-M4 of the i.MX7D and Linux on its Cortex-A7 are separate execution paths |
| STM32 | Microcontroller support for STM32F4/F7/H7 | Families using the Cortex-A7 in STM32MP1 and the Cortex-A35 in STM32MP2 |
The table is based on the September 8 proposals for PXA, Orion/Dove, i.MX31, i.MX without an MMU and STM32. "Remains" describes the scope of this removal and is not a guarantee of future maintenance. Operation of PXA with external device trees is likewise described only as a possibility.
The unit of removal is finer than the product brand. Even within one SoC, support for running Linux on the Cortex-A side, which has a memory management unit (MMU), is separated from the Cortex-M side, which does not. Knowing only that you use an i.MX7D is not enough to judge the impact.
SA1100, Footbridge and RiscPC are also among the targets this time, as are OMAP24xx and Axxia, and on the microcontroller side the LPC18xx family, SAMV7 and the MPS2 evaluation platform. The full list cannot be read as "the end of 32-bit Arm," however. Some 32-bit CPU support remains, such as the i.MX35 and STM32MP1 in the table.
Who does the extra work when old support stays?
The old PXA board files were not removed in the 2022 cleanup either; they were kept as a starting point for migrating to device trees. According to Bergmann, though, the target boards were never migrated afterward. The hope that keeping them would help future porting did not translate into actual work.
Board files are the traditional approach of describing each machine's hardware configuration and initialization in kernel code. Device trees, by contrast, describe attached peripherals, interrupts and so on as data passed to the kernel. Linux's official documentation explains their role in separating hardware description from board and driver implementation, reducing per-machine hard-coding and making it easier to use common code.
Still, if old board files remain, every change to shared mechanisms creates work to bring the old descriptions along. Linus Walleij, who supported the PXA removal, cited his experience of repeatedly restructuring code to eliminate fixed GPIO assignments and replied that he was tired of continuing when nobody benefits. GPIO refers to general-purpose input/output pins used to control peripherals and other devices, and the work of updating how they are handled extended even to old machines.
Even after migration to device trees, CPU-specific exceptions can remain. OMAP24xx, which connects to the Nokia N800/N810, and the ARM1136r0 used by i.MX31 are examples. Bergmann's deprecation patch notes that this revision is incompatible with CONFIG_SMP, the multiprocessor support setting, and lacks extensions found in the later ARMv6k. Turning hardware connection information into data does not remove the need for separate code to absorb CPU differences.
The slightly newer ARM1136r1 used by the i.MX35 does not have the same problem. Keeping it because of this difference is a more concrete judgment than drawing a uniform line by years elapsed. The question is how much work today's developers must do to maintain each exception.
Why microcontrollers still in production are also targeted
For LPC18xx and LPC43xx, there is a further explanation. In the removal patch, Bergmann says these microcontrollers are still in production as of 2026 but that there are no known users running Linux on them. A product remaining on the market does not mean Linux support for it needs to be maintained.
In the STM32 proposal too, Bergmann explains that newer microcontroller products use small real-time operating systems (RTOS) and that only the STM32MP family is relevant to Linux. This is, however, the proposer's account of known uses and actual usage. It is not proof, from a survey of Linux installations, that the number is zero.
Conversely, there are exceptions for older machines where users are visible. In the July deprecation proposal, S3C64XX was kept because Mark Brown uses it, and OMAP1 was expected to see its remaining board files migrated to device trees. Even for an old implementation, the judgment changes if there are concrete users or an update path.
The side doing the removal also has to verify that remaining machines are not broken. In the SA1100 removal this time, the discussion covered the register layout of the RTC driver, which handles clock functions, and the consistency of compatible strings that identify devices. In a September 8 reply, Bergmann explained that the problematic behavior existed before the change as well and reported that he had dropped the relevant identifier entry. No new hardware failure was reported, but it shows that removing a machine requires checking the conditional branches in shared drivers.
Deleting more than 50,000 lines is not a matter of simply erasing directories that look unneeded. It means separating out shared parts while removing paths nobody uses. That effort is one reason machine support and the drivers that follow are being cleaned up in stages.
Update paths to check before relying on LTS
What this proposal directly changes is the hardware support that can be selected in future Linux. If a device runs on an existing kernel, deleting code from mainline does not erase software already installed. The impact appears when you try to update to a newer version.
Bergmann envisions using 7.3 as an LTS, drawing a path that keeps the old support before moving to removal. This assumption cannot simply be replaced with a guarantee of how many years a particular device will be maintained. According to kernel.org's explanation, long-term releases bring important fixes into older series, and their selection depends on factors such as product-side demand and maintainer capacity. The official designation of 7.3 and its end-of-life date need to be confirmed from definitive information.
Kernels provided by device makers or distributions also have their own maintenance policies. Support in mainline, actual operation on a device, and continued delivery of fixes are separate conditions to check. A device that boots on an old version may not keep receiving updates for it.
Users should first go beyond the name of the chip family and confirm the exact machine and CPU, and who supplies the kernel they currently use. Is it a PXA that runs on device trees, or does it depend on board files being removed? Are you using the Cortex-A side of an i.MX, or running Linux on the Cortex-M side? Once that is clear, you can tell whether this change cuts off your update path.
The condition for keeping old devices connected to new Linux is whether remaining users can show the configuration and operating status they need, and whether anyone is willing to take on the changes required to maintain it. Bringing that concrete information into the discussion before the corresponding drivers disappear is what matters.