Google’s Tensor G5 Is Moving Into Mainline Linux 7.4

Realistic color-pencil editorial illustration of a Pixel 10 phone opened on a workbench with its Tensor G5 silicon and a Linux development terminal nearby.

Google’s Tensor G5 is taking an important step toward becoming a first-class citizen in the upstream Linux kernel. Initial support for the SoC family and three Pixel 10 boards has been accepted into the SoC tree for the upcoming Linux 7.4 development cycle.

The change is deeper than adding another phone model to a compatibility list. Tensor G5 is getting a new ARCH_GOOGLE architecture entry in the kernel, reflecting the fact that Google’s fifth-generation mobile SoC is no longer treated as a derivative of Samsung’s Exynos platform. Earlier Tensor generations grew out of that Samsung lineage; G5 moves onto Google’s own architectural branch.

The upstream work covers the Laguna Tensor G5 SoC family plus initial device-tree support for the Pixel 10 codenames Frankel, Blazer and Mustang — corresponding to the Pixel 10, Pixel 10 Pro and Pixel 10 Pro XL. The relevant patch series was accepted after several revisions, according to the Linux kernel mailing-list record.

Technical diagram explaining the stages from Tensor G5 device-tree support to mainline Linux boot and later Android integration.
Mainline kernel support is only the beginning: device trees and early boot land first, while subsystem drivers and Android integration continue separately.

What has actually landed

The upstream patch set introduces the architecture definition, Google-specific device-tree directory, initial board descriptions and kernel configuration needed to recognize the Tensor G5 family. The September v3 submission described the current target plainly: the early device trees are sufficient to boot the phones into an initramfs BusyBox shell.

That matters because a Linux kernel cannot properly initialize unfamiliar hardware simply because its CPU instruction set is already supported. The kernel also needs a structured description of the board: which devices exist, where their registers live, how interrupts are wired, which clocks and regulators feed them, and how the pieces relate to one another.

On ARM systems, much of that information arrives through the Device Tree. Upstreaming those descriptions gives mainline Linux enough knowledge to begin booting the hardware without depending entirely on a vendor-maintained kernel fork.

Earlier coverage examined the kernel-upgrade work surrounding Pixel 10; the upstream Linux 7.4 changes now provide the concrete mainline architecture and device-tree foundation.

Mainline support is not the same as a production Pixel kernel

This distinction is easy to lose in headlines. Pixel 10 owners should not expect an ordinary Android update to replace Google’s production kernel with Linux 7.4 overnight. Android devices use Google’s Generic Kernel Image model plus vendor modules, hardware-specific drivers, firmware interfaces and a substantial validation process.

The first upstream Tensor G5 support is foundational. Major subsystems such as graphics, cameras, cellular modems, media accelerators and other platform-specific hardware can require separate drivers and additional upstream work before a mainline kernel can operate the complete phone like production Android does.

That is why “boots mainline Linux” and “fully supports the device” are very different milestones. The current achievement is that the kernel now has a clean upstream place for Google-designed silicon and an accepted representation of the Pixel 10 boards on top of it.

Linux and Pixel users are already discussing what the mainline work means — and, importantly, what it does not immediately change on production Android devices.

Why Tensor G5 needs its own Linux architecture entry

Google says Tensor G5 is fabricated on a 3 nm process and uses a CPU complex built around Arm Cortex-X4, Cortex-A725 and Cortex-A520 cores, alongside Google’s fourth-generation TPU. The company’s original Tensor G5 overview focused on AI, imaging and efficiency, but the upstream kernel work reveals another architectural change: the platform has diverged far enough from older Exynos-derived Tensor chips to justify its own kernel family.

That separation matters to maintainers. Instead of carrying Google-specific assumptions inside Samsung platform code indefinitely, Linux can model the hardware according to its actual ancestry. The result is cleaner platform organization and a better base for future Google silicon.

Why upstreaming matters

Mainline hardware support reduces the amount of permanently out-of-tree code needed to keep a platform alive. It also exposes code to the broader Linux review process, makes changes easier to test against future kernels and can improve long-term maintainability after the original product generation is no longer new.

The same principle is one reason projects across the Linux ecosystem continually work to move vendor code upstream instead of freezing hardware support into a single shipping kernel. BitcoinVersus recently covered the continuing Linux 7.3 development cycle and the broader relationship between applications and the kernel through system calls.

For Tensor G5, upstreaming is still early, but the direction is clear. Google’s newest mobile silicon is no longer just hardware supported inside Android’s production tree; it now has an architectural foothold in mainline Linux itself.

For the detailed kernel-side status, see Michael Larabel’s Phoronix report and the accepted upstream patch discussion linked above.


Editor’s Note: BitcoinVersus.Tech covers computing, semiconductors, infrastructure and open-source engineering from an independent technical perspective.

Disclaimer: This article is for informational and educational purposes and does not constitute financial, investment or purchasing advice.

Leave a comment