Skip to main content

TECH VEDA

Embedded Linux on Edge-AI 23rd Sept 2026 enrollingLinux kernel & Device drivers starts on 26th Oct 2026 enrollingCorporate on-site training - Submit proposal Pick your modulessignup for free monthly live Masterclass Register
News

Kernel & Embedded News: 7.2-rc2 Speeds poll(); Buildroot LTS at 3 Years

Linux 7.2-rc2 makes poll() several times faster, the RTL8723BS driver still dominates staging, Buildroot LTS moves to three years, and Calixto launches a TI AM62L system-on-module.

Kernel & Embedded News: 7.2-rc2 Speeds poll(); Buildroot LTS at 3 Years

This edition is about the cost of keeping Linux running over a product’s life, and where that cost is falling. Linux 7.2-rc2 arrived on 6 July with a rework of the poll() path that makes it several times faster at no cost to you. The 7.2 staging tree is again dominated by cleanups to one old Realtek WiFi driver, a reminder that some maintenance never ends. Buildroot has extended its long-term support to three years, and Calixto Systems has launched a small TI AM62L system-on-module aimed at industrial products.

A poll() speed-up already visible in Linux 7.2, the long-running RTL8723BS staging cleanup, Buildroot’s move to a three-year LTS, and Calixto’s postage-stamp AM62L system-on-module.

The connecting theme this edition is maintenance and long-term supportability. Two items show the ongoing engineering burden inside the kernel, one shows a build system trying to reduce that burden for product teams, and the last shows new silicon shipping with a real support story. None of these is a headline feature, but each affects how much work a Linux product costs you over several years.

In this edition

  • Linux 7.2-rc2 speeds up poll(). Linus Torvalds released the second 7.2 release candidate on 6 July, and testing shows the poll() path is now several times faster after a change to how it allocates memory. (Phoronix)
  • One Realtek driver still dominates staging. The RTL8723BS WiFi driver took 154 cleanup patches in the 7.2 cycle, the bulk of the staging pull, nine years after it entered staging. (Phoronix)
  • Buildroot LTS is now three years. Buildroot’s long-term support has moved from one year to a three-year model, funded through a sponsorship programme. (Buildroot)
  • Calixto AM62L STAMP SOM. An Indian vendor launched a 40×40 mm TI AM62L system-on-module for industrial automation, HMIs, and EV chargers. (CNX Software)

Linux 7.2-rc2 and a faster poll() path

Linus Torvalds released Linux 7.2-rc2 on 6 July 2026 and described it as a very normal release candidate, slightly smaller than the equivalent point in the 7.1 cycle. The merge window that closed with 7.2-rc1 pulled a little over 7,000 non-merge changesets, and about a third of those were AMD GPU register definitions added late in the cycle. In other words, the bulk of 7.2 is routine driver and core work rather than large new subsystems.

The change worth noting is in the poll() path. Phoronix testing on an AMD EPYC Sorano system, run on 21 June against the 7.2 development tree, showed poll() running several times faster than on 7.1 stable, with lower socket latency and measurable gains in TCP and QUIC throughput. UDP was unchanged. The reported cause is a change in how the poll code allocates memory, moving from a page allocation to the kmalloc() interface. Because this is a generic change and not tied to AMD hardware, the same benefit should appear on other systems, including Arm-based boards.

For most teams this is the kind of improvement you get simply by moving to a newer kernel. poll() and its relatives sit under a large amount of event-loop and network code, so a faster poll() helps servers, gateways, and any userspace that waits on many file descriptors. Separate testing on Threadripper showed similar I/O and poll gains alongside a few regressions, which is normal for a release candidate. The practical step is to add 7.2 to your test matrix once it stabilises and measure the poll-heavy parts of your workload, rather than assuming the gain transfers unchanged to your device.

The RTL8723BS driver still dominates the staging tree

For the 7.2 merge window, the staging pull request was again dominated by cleanups to the Realtek RTL8723BS WiFi driver, which took 154 patches this cycle. Greg Kroah-Hartman described the work as the bulk of the staging merge, given all of the wrappers and issues involved in that driver. The RTL8723BS is an 802.11 b/g/n chip with Bluetooth 4.0, and it entered the staging area in 2017 with Linux 4.12. Nearly a decade later it has still not graduated to the mainline networking subsystem. (Phoronix, 25 June 2026)

This matters more for embedded work than the age of the chip suggests. The RTL8723BS is an SDIO part used on many low-cost single-board computers, tablets, and set-top designs, so a large installed base still depends on this exact driver. Code that lives in staging does not meet the kernel’s normal quality and API standards, which is why it needs continuous cleanup and why it can break across kernel upgrades.

If your product uses this chip, treat the WiFi path as a real test item on every kernel bump rather than assuming stability. The wider lesson is about part selection. A cheaper radio that depends on a staging driver can carry a maintenance cost for years, and that cost lands on your team, not the vendor. When you choose a wireless part for a new design, prefer one whose driver is already in mainline and out of staging.

Buildroot extends long-term support to three years

Buildroot has moved its long-term support to a three-year model, with a new LTS branch started roughly every two years and ordinary stable releases every three months in between. The change is funded through the Buildroot LTS Sponsoring programme, which pays for maintainer time instead of relying only on volunteers, with sponsorship tiers priced from 1,000 to 8,000 euros. Sponsors at the higher tiers can raise LTS and security queries directly. (Buildroot LTS, Mind)

For product teams this closes a real gap. Buildroot has long been the simpler choice for small, fixed-function images, but its previous one-year support horizon did not fit hardware that stays in the field for five to ten years. A three-year branch with regular security updates gives you a supported base to build on, and a clearer story when a regulator or customer asks how you will patch a shipped device.

This also narrows the old decision between Buildroot and the Yocto Project. Teams sometimes chose Yocto mainly for its longer support windows; that reason is now weaker for products that fit Buildroot’s model. If you maintain older Buildroot images, plan a migration onto a current LTS branch so that security fixes reach you without a full re-base. We cover both build systems and this kind of lifecycle planning in our embedded Linux training, because the maintenance decision usually matters more than the initial build.

Calixto’s AM62L STAMP SOM for industrial products

Calixto Systems, an Indian vendor, has launched the AM62L STAMP SOM, a 40×40 mm system-on-module built around the Texas Instruments AM62L, a dual-core Arm Cortex-A53 running at up to 1.25 GHz. The module carries up to 2 GB of LPDDR4x and 8 or 16 GB of eMMC, and it exposes Gigabit Ethernet, two USB 2.0 OTG ports, dual SD, MIPI DSI and parallel RGB display, McASP audio, and a wide set of industrial interfaces including CAN FD, eight UARTs, four SPI buses, five I2C buses, and ADC, DAC, PWM, and GPMC. It also integrates hardware security blocks: AES, RSA and ECC acceleration, DRBG, a true random number generator, and a unique device identifier. An evaluation kit is available. (CNX Software, 6 July 2026)

The AM62L is TI’s lower-cost, lower-power member of the Sitara AM62 family, aimed at HMIs, EV chargers, industrial automation, and smart retail. The value of a module like this is not raw performance but a supported, mainline-friendly platform on a small footprint, which lets a team put a Linux design into production without laying out a complex SoC on their own board.

The hardware security blocks are the part to plan around. TRNG, key acceleration, and a unique device ID are the building blocks for secure boot, measured boot, and device identity, and these are exactly the features that the EU Cyber Resilience Act and similar rules push products toward. If you are selecting a module for a new industrial design, confirm the maturity of the vendor BSP and how closely it tracks mainline before you commit, because that determines your long-term update burden more than any single interface on the datasheet.

References

— Raghu Bharadwaj

Was this worth your time?
RB
Raghu Bharadwaj

Founder, TECH VEDA — 20+ years teaching the Linux kernel, device drivers and embedded systems.

Follow on LinkedIn