Kernel & Embedded News: Linux 7.2 Final RC; FFmpeg 9.0 Released

Two themes connect this edition: a release process adjusting to the fix volume that AI review tools generate, and the value of measuring what you assume — a lockdown mode that did not lock everything, and a crypto accelerator measured slower than the CPU it serves. Alongside them sit a major userspace release and two hardware announcements at different layers of an embedded product.

In this edition

• Linux 7.2-rc7 is the final planned release candidate. Torvalds released 7.2-rc7 on 9 August and expects the stable kernel on 16 August, calling the AI-driven fix volume “the new normal”.
• FFmpeg 9.0 “Lei” is released. The 4 August release bumps the major version of all seven libraries, rewrites swscale, decodes animated WebP, and turns on TLS certificate verification by default.
• Kernel lockdown left legacy PCI files open since 2019. A queued PCI fix adds the missing lockdown checks to the legacy_io and legacy_mem sysfs handlers.
• Removal of Qualcomm’s QCE crypto driver is proposed. Eric Biggers posted a patch to delete the driver after measuring it far slower than the ARMv8 Crypto Extensions; the discussion is ongoing.
• ESP32-S31 enters mass production. Espressif’s dual-core RISC-V SoC combines Wi-Fi 6, Bluetooth 5.4 with Classic and LE Audio, 802.15.4 and a Gigabit Ethernet MAC in one chip.
• Radxa reveals two Qualcomm-based system-on-modules. The rCore-Q8280 and rCore-Q6490 pair a Snapdragon 8cx Gen 3 and a Dragonwing QCS6490 with very different product-availability commitments.

Linux 7.2 closes with a large final RC, and Torvalds calls it the new normal

Linus Torvalds released Linux 7.2-rc7 on Sunday, 9 August. By the seventh release candidate a development cycle has usually gone quiet. This one has not, and Torvalds was direct about the reason:

“I can’t say that I’m exactly thrilled about the size of this all, but it is what it is: the new normal with a lot of fixes, many of them due to review by various AI tools.”

He added that nothing in the RC looks particularly worrying — it is small fixes spread across drivers, filesystems, networking and architecture code, with s390 crypto, Btrfs and netfilter ipset standing out in the diffstat. He sees no value in delaying the release, so 7.2 stable is expected on 16 August unless a serious problem appears and forces an rc8.

The memory-management side closed a race condition that could produce a use-after-free and had been in the kernel for around eight years. Btrfs brought back its fixup worker infrastructure to deal with a silent data-loss case. The hardware-monitoring subsystem took a batch of fixes its maintainer described as mostly critical or high severity, many of them for defects the hwmon maintainer credits to the Sashiko AI review bot.

The practical shift is not the release date; it is that AI review has permanently raised the fix density of every late RC and every stable point release that follows. Downstream kernels will carry more patches per update, and the burden of deciding what matters moves further onto the teams consuming them.

What it means for teams planning on 7.2

If your next BSP or distribution baseline targets 7.2 — Ubuntu 26.10 is expected to ship it as the default kernel — put rc7 on your target hardware this week rather than waiting for the tag. The delta from rc7 to final is normally small, so problems found now can still be reported as release blockers. Teams using Btrfs on embedded storage should read the fixup-worker change specifically, since silent data loss is the failure mode that never shows up in a quick test. Expect the 7.2.y stable series to move fast in its first weeks, and budget regression-test time for point releases accordingly.

FFmpeg 9.0 is released: an ABI break and new defaults that affect devices

FFmpeg 9.0 “Lei” was released on 4 August, about four and a half months after 8.1, carrying more than 2,200 commits from over 160 authors. It bumps the major version of all seven libraries — libavutil 61, libavcodec 63, libavformat 63, libavdevice 63, libavfilter 12, libswscale 10, libswresample 7 — which means an ABI break across the board. Jean-Baptiste Kempf’s release write-up is the best single overview.

The largest engineering effort is the multi-year rewrite of swscale: conversions are now decomposed into operation lists compiled by C, x86 SIMD, AArch64 NEON or Vulkan SPIR-V backends, though the new paths stay behind SWS_UNSTABLE for now. Elsewhere, FFmpeg finally decodes animated WebP (a ticket open since 2015), and the AAC decoder handles the 960-sample frames used by DAB+ digital radio. A large body of NEON work speeds up software conversion on Arm boards, and the DNN filters gain an ONNX Runtime backend for running inference inside a filter graph.

For device teams, the removals and default changes matter more than the features. TLS peer certificates are now verified by default, so a product that pulls streams or updates from an endpoint with a self-signed or expired certificate will start failing after the upgrade. The OpenMAX encoders are gone, which removes the last supported path for old OMX-based encode pipelines. On the command line, -vsync is removed in favour of -fps_mode, and NVENC drops SDKs older than 11.1.

What to check before you upgrade

Plan the 9.0 upgrade as a porting exercise, not a version bump. Every application linking the libav* libraries needs a rebuild against seven new sonames, so coordinate the migration with your distribution or Yocto layer rather than upgrading one recipe in isolation. Search startup scripts for removed CLI flags, and test every TLS endpoint your product contacts against the new verification default — the correct response to a failure is fixing the certificate, not disabling verification. Pipelines still using OMX encoders should schedule the move to V4L2 M2M or vendor plugins now.

A lockdown gap: legacy PCI sysfs files stayed writable since 2019

Kernel lockdown mode restricts what root can do to a running kernel — no writes to /dev/mem, no direct PCI BAR access, and so on. It is commonly enabled together with UEFI Secure Boot, and many product security arguments lean on it: even if an attacker gains root, the kernel itself stays out of reach.

It turns out two interfaces were missed. The legacy_io and legacy_mem sysfs files, which give access to legacy port I/O and legacy PCI memory space, never received lockdown checks. Krzysztof Wilczyński explains it plainly in the fix now queued in the PCI subsystem’s next branch:

“As a result, root can still write arbitrary I/O ports and map the legacy I/O and memory spaces while the kernel is locked down, which is the same capability the lockdown is meant to remove.”

The checks were added elsewhere in 2019 by commit eb627e17727e (“PCI: Lock down BAR access when the kernel is locked down”), covering config-space writes, resource mmap and resource I/O writes — but not the legacy handlers. The new patch adds the missing security_locked_down(LOCKDOWN_PCI_ACCESS) checks, targets the 7.3 merge window, and is marked as a fix for the 2019 commit, so backports into stable series are the likely next step.

The instructive part is how the gap survived for seven years. Lockdown is not a single global switch; it is a collection of per-interface checks, and every interface that can reach kernel memory has to opt in individually. A new or overlooked interface fails open, not closed. Security audits should therefore test observed behaviour on the shipped kernel instead of trusting the feature description.

How to check your device

First confirm what lockdown state your product actually runs in — the bracketed entry is the active mode:

raghu@techveda.org:~$ cat /sys/kernel/security/lockdown
none [integrity] confidentiality

If your threat model counts on lockdown to keep root away from the running kernel, add this patch to your tracking list and pick it up when it reaches your stable series; it is a small, self-contained backport. Where the platform exposes the legacy PCI files, a direct write attempt under lockdown makes a useful acceptance test.

Qualcomm’s QCE crypto driver faces removal for being slower than the CPU

In late July, kernel crypto maintainer Eric Biggers proposed removing the Qualcomm Crypto Engine (QCE) driver — around 3,500 lines under drivers/crypto/qce — from the kernel outright. The driver had already been marked broken earlier in July over its performance and bug history; the removal patch followed new measurements.

The numbers in his benchmark mail are direct: a SHA-256 workload that takes 0.10 seconds through the ARMv8 Crypto Extensions took 10.76 seconds through QCE, using over 50 times more CPU time — much of it in hardirq and softirq context. Even with recent locking changes rolled back, the engine remained roughly 48 times slower than the CPU instructions. The offload engine costs more than it saves: per-request DMA setup, interrupts and completions dominate at typical request sizes. The discussion is ongoing — at least one developer has offered to keep maintaining the driver, and Greg Kroah-Hartman has been brought into the thread — so removal is proposed, not decided.

The general lesson applies beyond Qualcomm. Crypto offload engines were useful when CPUs lacked AES and SHA instructions; on any Armv8 core with the Crypto Extensions, that assumption needs re-testing, and BSPs frequently enable vendor crypto drivers by default without anyone measuring them.

What to do on Qualcomm-based products

If your BSP builds the QCE driver, benchmark both paths on your hardware — dm-crypt via cryptsetup benchmark, or the kernel’s tcrypt tests — before trusting the offload. Should the removal go through, nothing breaks functionally: the kernel crypto API falls back to the next-priority implementation, which on these SoCs is the faster CPU path. The same measurement habit is worth applying to any vendor offload block in your tree, not only crypto.

ESP32-S31 enters mass production: one chip for Wi-Fi 6, Thread and Bluetooth

Espressif announced on 27 July that the ESP32-S31 has entered mass production and is available for purchase. The chip pairs two 32-bit RISC-V cores at up to 320 MHz — one with a 128-bit data path and SIMD instructions — with a 40 MHz low-power coprocessor, 512 KB of on-chip SRAM, support for 250 MHz DDR PSRAM, and up to 60 GPIOs.

The radio set is the notable part. One chip carries 2.4 GHz Wi-Fi 6, Bluetooth 5.4 including both LE Audio and Classic BR/EDR, and IEEE 802.15.4 for Zigbee and Thread, plus a Gigabit Ethernet MAC. Matter is supported over both Wi-Fi and Thread, and HMI support covers camera and LCD interfaces, capacitive touch, and a 2D graphics accelerator.

Be clear about what this is: a microcontroller programmed with ESP-IDF, not a Linux part. Its relevance to a Linux product is as the radio side of the design. A hub or gateway that needs Wi-Fi, Thread and Bluetooth today often carries two or three radio chips with separate antennas, drivers and certification effort; consolidating them into one part reduces board area and RF integration work. Bluetooth Classic support is increasingly rare in new silicon, which matters for products that still talk to older audio and serial-profile devices.

Where it fits in a Linux design

Espressif’s ESP-Hosted and ESP-AT frameworks let the chip serve as a connectivity co-processor next to a Linux SoC, with the application processor driving it over SDIO, SPI or UART. For a Matter-capable gateway, that structure keeps the protocol radios and their certified stacks on one side and your Linux application on the other. Before committing a BOM, verify module-level regulatory certification for your target markets and check long-term availability terms — Espressif publishes a longevity commitment per product line, and the difference between chip and module sourcing affects both.

Radxa’s rCore SoMs bring Snapdragon and Dragonwing to the edge

Radxa has added two Qualcomm-based system-on-modules to its rCore line, aimed at edge AI, multimedia, robotics and industrial products. The rCore-Q8280 (50 × 80 mm) is built on the Snapdragon 8cx Gen 3 (SC8280XP): eight Kryo cores at up to 3.0 GHz, an Adreno 690 GPU, a Qualcomm AI Engine rated at 29+ TOPS, up to 32 GB of LPDDR4X, and nine PCIe Gen3 lanes. The rCore-Q6490 (42 × 36 mm) uses the Dragonwing QCS6490: an eight-core Kryo 670, Adreno 643, a Hexagon NPU rated at up to 12 dense TOPS, up to 16 GB of LPDDR5, and five 4-lane MIPI CSI camera interfaces supporting sensors up to 64 MP.

The TOPS numbers are vendor ratings aggregated across CPU, GPU and NPU, so compare candidates by running your own model, not by the datasheet figure. The more decision-relevant numbers are the availability commitments: Radxa states the Q8280 will remain available until at least June 2029, while the Q6490 carries a commitment through at least June 2036. For an industrial product with a ten-year service life, that difference outweighs the performance gap.

Software support also splits along product lines. The Q8280 lists desktop-style distributions — Debian, Ubuntu, Armbian and others — while the Q6490 lists Yocto alongside Ubuntu and Windows 11 IoT Enterprise, which signals where Radxa expects each module to be designed in. Pricing and retail availability have not been announced for either module.

How to evaluate them

Treat the two modules as different products rather than two variants of the same design. The Q8280 is a laptop-class SoC repurposed for compute-heavy edge boxes; the Q6490 is the one shaped for long-life, camera-heavy embedded designs. Before shortlisting either, ask which kernel the vendor images track, what the upgrade path looks like over the module’s life, and how much of the SoC support is upstream versus carried in a vendor tree — on a Qualcomm part, that answer determines your maintenance cost more than any spec-sheet line. Get it in writing, and prototype your camera pipeline early if the five CSI interfaces are the reason you are looking at the Q6490.

References

• Linux 7.2-rc7 announcement — Linus Torvalds, lore.kernel.org
• Linux 7.2-rc7 Released Following Another Exhausting AI-Driven Week — Phoronix
• FFmpeg 9.0 Changelog — code.ffmpeg.org
• FFmpeg 9.0 — Jean-Baptiste Kempf
• PCI: Add missing lockdown checks for legacy I/O and memory handlers — git.kernel.org (pci/next)
• Proposal to remove the Qualcomm QCE driver — Eric Biggers, lore.kernel.org
• QCE vs ARMv8 CE benchmark thread — lore.kernel.org
• Qualcomm QCE Driver On The Chopping Block — Phoronix
• Linux Accidentally Left Legacy I/O & Memory Handlers Open In Kernel Lockdown Mode — Phoronix
• ESP32-S31 Now in Mass Production and Available for Purchase — Espressif Systems
• ESP32-S31 product page — Espressif Systems
• Radxa Broadens rCore Series with Snapdragon and Dragonwing AI SoMs — LinuxGizmos
• Radxa rCore-Q8280 product page
• Radxa rCore-Q6490 product page

— Raghu Bharadwaj