Basic support for the Pixel 10 series, powered by the Google Tensor G5, has moved a step closer to being merged into Linux 7.4. On October 5, 2026, Krzysztof Kozlowski, the SoC maintainer, sent a pull request that includes a new architecture category for Google, "ARCH_GOOGLE," along with hardware definitions for three devices: the Pixel 10, Pixel 10 Pro, and Pixel 10 Pro XL.
The groundwork for booting upstream Linux is falling into place. But what has been confirmed so far goes only as far as booting a minimal in-memory environment and running commands. Between recognizing and booting a device and using it day to day, with a working display and connectivity, a great deal of implementation and testing remains.
What ARCH_GOOGLE says about changes in SoC design
Linux previously classified the Tensor chips under Samsung's SoC family. In his pull request, Kozlowski explains that the early Google GS101 was based on a Samsung design, which is why it was grouped under that family.
The Tensor G5, codenamed "Laguna," has moved to a different design. The kernel therefore gains a new "ARCH_GOOGLE" category for Google-designed SoCs, and the files describing the device configurations are placed in a dedicated Google directory.
What this change reflects is which SoC family Linux treats the Tensor G5 as belonging to. It does not mean a new CPU instruction set has been introduced. The hardware definitions being added list one Arm Cortex-X4, five Cortex-A725 and two Cortex-A520 cores. Google designing its own SoC is not the same as designing every circuit, including the CPU, entirely in-house.
Development materials for USB support make the distinction clearer. In a USB support proposal from October 2025, Google's Roy Luo explained that the Tensor G5 also uses a Synopsys USB block.
However, because the way that block is integrated into the SoC has changed, clock and reset control, register access methods and initialization procedures all differ from before. New drivers and hardware definitions are therefore needed.
In other words, even when the same IP, meaning a reusable circuit design, is used as a component, it cannot necessarily be controlled from Linux in the same way. The new ARCH_GOOGLE category is meant to accommodate this kind of change in overall SoC configuration.
The USB material, though, is an earlier proposal that provides background. It does not mean that USB functionality becomes usable all at once with this pull request.
What can boot so far, and what cannot yet be confirmed
Developers are verifying boot with a BusyBox shell running from an initramfs. An initramfs is an initial filesystem unpacked into memory at boot, and BusyBox is a compact collection of basic command-line tools.
This environment lets them check whether the kernel boots and can run commands before bringing up a normal OS from internal storage.
The core of what is being added is a file called a Device Tree, which describes the hardware configuration. The official Linux documentation describes a Device Tree as a data structure of hardware information that the OS can read.
By passing the CPU, interrupt lines, peripheral connections and other details as data, the kernel can use the right drivers for each device's configuration. But describing the hardware is a separate matter from having the drivers that actually operate each circuit.
Based on the fourth version of the Device Tree that Peter Griffin submitted on September 18, and the cover letter describing boot requirements, the scope of this addition can be sorted by function as follows.
| Functional layer | What the description and reports confirm | What cannot be confirmed from them |
|---|---|---|
| Device identification | Frankel is defined as the Pixel 10, Blazer as the Pixel 10 Pro, and Mustang as the Pixel 10 Pro XL | Support for devices not listed, such as the Pixel 10 Pro Fold |
| CPU and boot foundation | CPU configuration, idle states, interrupt controller and timer are described | Battery life of the whole device, or how well resume from sleep works |
| Text input and output | A serial console over UART is defined, and a boot to an in-memory shell is reported | Output on the built-in display, touch input, desktop environment |
| Failure analysis | Reserved memory for logs used in post-reboot investigation | Booting a normal OS environment from internal storage |
| Peripherals needed for daily use | This Device Tree change adds no connection definitions for display, connectivity, AI processing and the like | Practical operation of the camera, calls, AI processing on the TPU, etc. |
Comparing the September 18 proposal with the October 5 pull request, the core of this addition is device identification, CPU boot and log capture. It cannot be confirmed that the display, storage, connectivity, AI processing and similar features have reached a practically usable state.
This table sorts the device definitions, CPU-related descriptions, UART and log memory contained in the fourth version, and cross-checks them against the list of changes in the October 5 pull request. A change fixing Device Tree validation warnings was also added along the way.
Separate support proposals exist for USB and other features, so this table alone cannot be used to conclude that no related drivers exist in upstream Linux.
The text console also has requirements on the device side. The Device Tree describes the UART in a disabled state, and the bootloader enables it when it is configured to use the console. The baud rate is likewise set by the bootloader.
The changes also reserve a "ramoops" region used for post-crash investigation, as well as a memory region for storing bootloader logs. This is also groundwork for building up support while investigating the causes of boot failures.
The description of CPU idle states does not by itself mean better battery life. Beyond the mechanisms that let the CPU rest, smartphone power efficiency can only be assessed once the whole device, including the display and peripherals, is verified to reduce power use appropriately and resume correctly.
Debate over handling device differences, and bootloader requirements
The initial proposal dates back to November 2025. What changed on the way to merging was not only the supported features but also how device-specific differences are passed to Linux.
Originally, the series used "overlays," which layer per-model differences on top of a common Device Tree, but the approach drew continued debate.
In the second version in July 2026, Griffin removed the overlays and switched to the standard upstream Linux arrangement of a separate file for each of the three models. In the September 18 cover letter, he explains that he wants to separate the overlay issues from merging the initial Laguna/Pixel 10 support.
Having each model's file reference a common SoC definition reduces duplication while still letting each model's configuration be expressed individually.
For the fourth version with this revised structure, Kozlowski notified that he had applied four patches on September 29. A series of changes including fixes for validation warnings was then sent on October 5 as a pull request for Linux 7.4.
Being pulled into a maintainer's tree is not the same as being merged into an official Linux release. What can be said with certainty about this news is that it has advanced as far as the pull request toward integration into Linux 7.4.
Meanwhile, compatibility issues remain between a Device Tree definition acceptable to upstream Linux and one that actually boots on existing devices.
The September 18 proposal notes that when an alias called "ufs0," used for the UFS internal storage, and an empty node were removed, the bootloader at the time treated the missing alias as a fatal error.
While waiting for a newer bootloader, the developer explains that the needed nodes will be supplied through Linaro's build-support tool "pixelscripts." The approach keeps unnecessary entries out of the upstream Device Tree and adds the information the device's boot requirements need at build time.
This is, however, a workaround presented as of September 18, and whether it is still required on every device needs separate confirmation. Also, the fact that an empty node can be added does not mean reading and writing storage over UFS is complete.
Why build up upstream Linux support separately from Android updates
Android already has a mechanism for separating a common kernel from device-specific implementations. According to Google's official explanation of the Generic Kernel Image (GKI), GKI is built from the Android Common Kernel, and SoC- and board-specific functionality is separated into loadable vendor modules.
The design stabilizes the interface between the kernel and the modules, making it easier to update each independently.
That is why hardware working on production Android does not necessarily mean the same features are available on plain upstream Linux. The control handled by vendor modules and similar components must be rebuilt as drivers and hardware definitions usable in upstream Linux.
This effort likewise does not mean the Pixel 10's Android will be updated to Linux 7.4, nor is it an announcement that the device's support period will be extended.
Still, it matters that a common foundation for adding drivers and other support is moving closer to the official development line. If the configuration for identifying and booting the three models can be used as a shared baseline, later work can proceed peripheral by peripheral more easily.
The decision to separate the overlay debate and merge the initial support first also fits a development approach of building consensus on the parts that can move forward.
To bring the Pixel 10 to the point where it can be used day to day on upstream Linux, booting from internal storage and display interaction must be verified on real hardware, along with connectivity and power-saving behavior. Once these can be confirmed reproducibly, including each device's bootloader requirements, developers can move from a minimal in-memory test environment toward an OS environment that can be used continuously.