Linux 7.1 broadens embedded SoC support, exFAT moves to iomap in 7.2, USB4STREAM lands for peer-to-peer transfers, silicon vendors begin moving their Yocto BSP layers to the new Wrynose LTS, and AI-generated patches strain ARM64 review.
This edition looks at the current 7.1 and 7.2 cycle, and the new Yocto LTS, from an embedded point of view. The pattern is steady, useful progress in the fundamentals that product teams rely on: more boards supported out of the box, faster removable-storage I/O, a new high-speed transfer path, and the first signs of silicon vendors moving their build-system layers to the new long-term-support release. Alongside that, there is a process problem worth tracking, because the volume of AI-generated patches is starting to affect how quickly maintainers can review real work.
In this edition
- Linux 7.1 widens embedded SoC support. The 7.1 release adds in-tree support for NXP S32N79, Renesas RZ/G3L, Microchip PIC64GX, SpacemiT K3, Toradex Verdin AM62 variants, and many more Arm and RISC-V parts.
- exFAT moves to the iomap framework in 7.2. The exFAT maintainer converted the filesystem to iomap, improving throughput on SD cards and USB drives.
- USB4STREAM merged for 7.2. A new Intel-developed protocol exposes /dev/tbstreamX devices for raw, low-latency data transfer between two USB4 or Thunderbolt connected systems.
- Vendors begin moving BSP layers to Yocto 6.0 “Wrynose”. The new Wrynose LTS is out, and NXP’s meta-freescale is porting on master while TI and Jetson layers trail.
- AI-generated patches strain ARM64 review. The KVM/arm64 pull request for 7.2 carried no new features because reviewers are overwhelmed by AI-generated fix patches.
Linux 7.1 widens embedded SoC support
Linus Torvalds released Linux 7.1 on 14 June 2026. The headline desktop and server items are routine this time, but the architecture trees tell a more interesting story for embedded teams, because the breadth of newly supported industrial and automotive parts is large.
On the Arm side, 7.1 adds the NXP S32N79, an automotive processor with eight Cortex-A78AE cores and twelve Cortex-R52 cores, plus around 22 additional industrial boards built on NXP i.MX8M and i.MX9. Renesas added the RZ/G3L (r9a08g046), a Cortex-A55 industrial part in the same family as the existing G3E and G3S. Texas Instruments contributed four Toradex Verdin AM62 module variants. On RISC-V, Microchip added the PIC64GX, described as a PolarFire SoC without the FPGA, and SpacemiT K3 device-tree support advanced with I2C, Ethernet, PMIC, and pin control.
There are also core changes that matter for products. NTFS was replaced with a completely rewritten driver that uses iomap and promises active maintenance, the high-resolution-timer core was rewritten so the scheduler can use high-resolution timers without a performance penalty, and Landlock gained coverage for Unix domain sockets. RISC-V removed XIP kernel support because nobody was using it, and raised COMMAND_LINE_SIZE to 2048 to match other architectures.
The practical point is upgrade economics. When your SoC lands in mainline, you stop carrying a large vendor patch stack against an older base, and your bring-up and long-term maintenance both become cheaper. I recommend that teams starting a new design in the next year check whether their target is now supported in 7.1 or queued for 7.2 before committing to a vendor BSP kernel, because the difference in maintenance burden over a product lifetime is significant.
exFAT moves to the iomap framework in 7.2
Namjae Jeon, the exFAT maintainer, converted exFAT to the kernel iomap framework during the 7.2 merge window, around 20 June. iomap is the modern block-mapping layer already used by XFS, the new NTFS driver, and others, and it reduces per-page overhead on buffered I/O.
For embedded products this matters more than it might appear, because exFAT is the default format on most SD cards and USB drives above 32 GB. Dashcams, cameras, medical recorders, and media appliances write large sequential files to exFAT volumes constantly, and the iomap conversion improves throughput on exactly that pattern.
The work is internal, so there is no API change and no application change required. The practical approach is to fold it into your normal kernel evaluation: when you move a storage-heavy device to a 7.2-based kernel, measure sustained write throughput to your actual exFAT media rather than assuming the gain, since results depend on card quality and block size.
USB4STREAM merged for 7.2
The USB and Thunderbolt subsystem pull for 7.2 merged USB4STREAM, an Intel-developed protocol for sending raw packets directly between two hosts over a USB4 or Thunderbolt link. It exposes /dev/tbstreamX character devices, so any program that can read and write a file descriptor can move data across the link without a network stack.
This opens up uses that previously needed Ethernet-over-USB or a custom gadget driver: fast host-to-host file transfer, sharing a camera between two systems, or streaming raw sensor and instrument data. For machine vision, test equipment, and industrial data acquisition, a simple low-latency byte pipe between two boxes is useful, and the read/write interface keeps the application side straightforward.
This is early support, so I would treat it as something to prototype rather than ship in the near term. The interface and tooling will mature over the next few cycles. If you have a product idea that depends on high-bandwidth host-to-host transfer, the recommendation is to build a proof of concept now to understand the throughput and latency on your hardware, and plan production use for a later, settled kernel.
Silicon vendors begin moving their BSP layers to Yocto 6.0 “Wrynose”
The Yocto Project released version 6.0, “Wrynose”, on 13 May 2026 as a Long Term Support series supported until April 2030. It is built on Linux 6.18 LTS with a large toolchain update (GCC 15.2, glibc 2.43, LLVM 22.1, Rust 1.94). The change that matters most for product teams is the compliance tooling: sbom-cve-check replaces the older cve-check class, SBOMs are produced in SPDX 3.0 with package URLs, and SPDX 2.x output has been dropped. The EU Cyber Resilience Act is the main reason this LTS is being adopted faster than the previous one.
The question for most teams is when their silicon vendor’s BSP layer will support it. The community layers develop against poky master first and only cut a named LTS branch once the toolchain and kernel breakage is resolved. Support therefore arrives in two stages: master builds against Wrynose, then a stable wrynose branch is tagged a few weeks to a couple of months later.
NXP is the furthest along. The meta-freescale layer has active commits through late June, with GCC 15 build fixes and recipe references already moving to the lf-6.18.y NXP BSP that matches the Wrynose kernel. A stable wrynose branch has not been published yet, so the work is in progress rather than complete. Two structural changes are worth noting: meta-freescale-distro is being folded into meta-freescale and kept only as a thin compatibility layer for the Wrynose lifetime, and new fragments let you select the mainline-tracking BSP (linux-fslc) or the NXP downstream BSP (linux-imx) with DISTRO set to poky. NXP also stopped Scarthgap BSP backports in April 2026, which signals that it expects teams to move forward.
The other major vendors trail by varying amounts. Texas Instruments tracks Yocto on meta-ti, but its validated Processor SDK is built on the Arago distribution and usually lags by an LTS cycle, so a TI-blessed Wrynose SDK will arrive months later. NVIDIA Jetson support through meta-tegra is community-maintained and gated on NVIDIA’s own JetPack and L4T releases, so it tends to lag the most. Rockchip is split between an upstream-tracking community layer and a downstream vendor-style layer.
The practical approach depends on your silicon. NXP i.MX teams can start evaluating on meta-freescale master now, but should wait for the tagged wrynose branch before fixing a product base. TI and Jetson teams should plan to stay on Scarthgap a while longer and budget for the lag, keeping in mind that Scarthgap BSP backports are already ending. For anyone driven by Cyber Resilience Act timelines, I recommend beginning the SBOM and CVE workflow changes now on whatever LTS you are on, because that work is independent of the vendor branch and is the part that takes longest to get right.
AI-generated patches strain ARM64 review
The KVM/arm64 pull request for 7.2 was unusual: it contained no new features at all, only fixes. The maintainer explained that it is becoming too hard to review new work when, in his words, so many AI-fuelled fixes hit the list. The same effect was reported for the general ARM64 architecture changes this cycle.
This is a maintainer-capacity problem, not a hardware problem. A large volume of machine-generated patches, many of them low value or subtly wrong, consumes the limited review time that would otherwise go to substantial features. The cost is paid by everyone downstream, because feature work that real products need is delayed while reviewers triage the queue. It is worth noting that the trend is not uniformly negative; QEMU has begun adjusting its policy to allow some AI-assisted contributions under clear rules, and some genuinely useful driver work this cycle was AI-assisted.
For engineering teams the lesson is about people and process. The scarce skill is no longer generating a patch; it is reading kernel code carefully enough to judge whether a change is correct, safe, and worth merging. If your team contributes upstream, hold AI-assisted submissions to the same standard as any other patch, disclose the assistance, and do not add to the review burden with unverified changes. This is also the kind of judgement we emphasise in our kernel internals training at TECH VEDA, because the ability to verify a change against the source is what separates a useful contributor from a noisy one.
My broader read is that the 7.x series is in a healthy, incremental phase for embedded work, with the storage, connectivity, and board-support fundamentals all moving in the right direction, and the vendor build systems steadily catching up on the new LTS. The constraint to watch is human review capacity, and teams that invest in engineers who can read and verify kernel code will be better placed as that constraint tightens.
References
- CNX Software — Linux 7.1 Release: Main changes, Arm, RISC-V, and MIPS architectures
- Phoronix — exFAT File-System Enjoys Better Performance On Linux 7.2 With IOmap Conversion
- Phoronix — USB4STREAM Merged For Linux 7.2
- The Yocto Project — Yocto Project 6.0 “Wrynose” is here!
- meta-freescale — OpenEmbedded/Yocto Project BSP Layer for NXP’s Platforms
- Phoronix — “So Many AI-Fueled Fixes” Means No New ARM64 KVM Features For Linux 7.2
- Phoronix — AI/LLM patch activity impacting ARM64 Linux kernel development
- Phoronix — QEMU Shifting On AI Policy To Allow Some AI/LLM-Generated Contributions
— Raghu Bharadwaj
