kernel-msm is Motorola's Android kernel tree, and its README is a patch contract

A vendor kernel tree, version 5.10.136

The repository is described as a Linux kernel for Motorola devices using an MSM based chipset, and it is a full kernel source tree rather than a patch set or a driver. The top level holds the directories you would expect from a kernel: `arch/`, `block/`, `Documentation/`, `android/`, `LICENSES/`, `MAINTAINERS`, `OWNERS`, `Kbuild`, `Kconfig` and the top level `Makefile`, alongside `Android.bp` for the Android build system and a `CREDITS` file.

The version comes from the Makefile, where `VERSION = 5`, `PATCHLEVEL = 10` and `SUBLEVEL = 136` give 5.10.136, and the release name is set to `Dare mighty things`. The same file carries the SPDX identifier GPL-2.0.

Two details in that Makefile are worth reading. It exports `KERNEL_SUPPORTS_NESTED_COMPOSITES := y`, and the comment explains why: it indicates that a particular change is present in the kernel so that out-of-tree modules can act on it. The file also states plainly that its comments are targeted only to the developer and that you should not expect to learn how to build the kernel by reading it, pointing instead at `make help` and the top level README for that.

On the repository as a project, the default branch is `android-13-release-ttz`, an Android 13 release branch for a particular target, the repository is not archived, the last push was on 2026-10-19, and there are no GitHub releases, so the branch structure is the versioning scheme.

The README is a submission guide, not documentation

The README's title is How do I submit patches to Android Common Kernels, and that is the entire document. There is no description of the hardware, no build walkthrough and no feature list, which is unusual enough to be worth saying plainly: this repository's README is a contract for contributors rather than a manual for users.

The contract has two routes, and the README ranks them explicitly.

The best route is to make all of your changes to upstream Linux, and, if appropriate, backport to the stable releases. The README says these patches will be merged automatically in the corresponding common kernels. If the patch is already in upstream Linux, you post a backport of the patch that conforms to the requirements below. There is one condition on going upstream: do not send patches upstream that contain only symbol exports, because additions of `EXPORT_SYMBOL_GPL()` require an in-tree modular driver that uses the symbol, so the new driver or the changes to an existing driver have to be in the same patchset as the export. And when sending upstream, the commit message must contain a clear case for why the patch is needed and beneficial to the community, with the note that enabling out-of-tree drivers or functionality is not a persuasive case.

The second, less good route is to develop patches out of tree. The README is blunt that, unless the patch fixes an Android specific bug, these are very unlikely to be accepted unless they have been coordinated with [email protected].

So the intended workflow is upstream first, and a vendor tree that keeps itself in step by merging what upstream already accepted.

Common kernel patch requirements, in full

The requirements section is short enough to quote almost in full, and it is the most useful part of the repository for anyone who ships kernel patches.

All patches must conform to the Linux kernel coding standards and pass `script/checkpatch.pl`. Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86 and x86_64 architectures. If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch: `UPSTREAM:`, `BACKPORT:`, `FROMGIT:`, `FROMLIST:` or `ANDROID:`. All patches must have a `Change-Id:` tag, and if an Android bug has been assigned there must be a `Bug:` tag. All patches must have a `Signed-off-by:` tag by the author and the submitter.

The structural requirement is the one most people forget. A `Change-Id:` is what ties a patch to a Gerrit review, and a `Signed-off-by:` records the sign-off, but the type tag is what tells a reviewer how to read the change at all. It is a small amount of ceremony that makes a queue of hundreds of patches reviewable, and it is the reason the rest of the README is organised around tag types.

Five subject tags, each with its own trailer rules

The tag system is the heart of the process, and the README gives an example for each case. A cherry-pick from mainline with no changes at all is tagged `UPSTREAM:` and adds a `(cherry picked from commit ...)` line:

        UPSTREAM: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <[email protected]>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        Signed-off-by: Joe Smith <[email protected]>

If the patch requires any changes from the upstream version, the tag becomes `BACKPORT:` instead, with comments about the changes under the `(cherry picked from commit ...)` line.

A patch already merged into an upstream maintainer tree but not yet into mainline is tagged `FROMGIT:`, and the origin is recorded as `(cherry picked from commit <sha1> <repo> <branch>)`. The README insists that this must be a stable maintainer branch, not a rebased one, so `linux-next` is not a valid source.

A patch submitted to LKML but not accepted anywhere is tagged `FROMLIST:`, with a `Link:` tag pointing at the submittal on lore.kernel.org and a `Bug:` tag, which the README says is required for patches not accepted into a maintainer tree:

        FROMLIST: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <[email protected]>

        Bug: 135791357
        Link: https://lore.kernel.org/lkml/[email protected]/
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <[email protected]>

And a patch fixing Android specific code is tagged `ANDROID:` with a `Fixes:` tag citing the patch that introduced the bug. A new feature is also `ANDROID:`, but needs a `Bug:` tag instead.

Build configs describe the fleet this kernel serves

The build configuration files are where the scope of the tree becomes visible, and there are many of them. They cover the generic kernel image with `build.config.gki` and a set of GKI variants for aarch64 and x86_64, including `build.config.gki.aarch64.fips140` and its `fips140_eval_testing` companion, `build.config.gki_kasan` for aarch64 and x86_64, `build.config.gki_kprobes` for aarch64 and x86_64, and `build.config.gki_consolidate.aarch64`.

Then there is the device layer. `build.config.msm.common` and `build.config.msm.gki` are the shared MSM base, and the chipset variants are separate files: `build.config.msm.lahaina`, `build.config.msm.parrot`, `build.config.msm.waipio` with a `waipio.tuivm` variant, and `build.config.msm.vm` for the virtual machine target. Alongside them sit `build.config.db845c`, `build.config.hikey960`, `build.config.moto`, `build.config.anorak`, `build.config.neo_la`, `build.config.neo_le`, `build.config.rockchip`, `build.config.sxr.common`, `build.config.amlogic` and `build.config.allmodconfig` for each architecture.

The `samples/` directory is a directory of sample subsystems, each with its own `Kconfig` and `Makefile`: `samples/binderfs/`, `samples/bpf/`, `samples/configfs/`, `samples/crypto/`, `samples/ftrace/`, `samples/kprobes/`, `samples/livepatch/`, `samples/seccomp/`, `samples/timers/` and others, alongside sample `Makefile` and `Kconfig` files at the top of that directory.

So the tree serves a fleet rather than a single board, and the naming of the configs is a map of that fleet.

Where this kernel fits, and where it does not

The reason the README spends all its words on patch submission is that this tree is a consumer of upstream rather than a competitor to it. A vendor tree exists to carry the patches upstream does not want or cannot take yet, the SoC support, the device specific glue and the downstream configuration. The contribution process exists to keep that gap small and to make sure anything that could go upstream does go upstream.

The alternative approach is exactly the one the README calls the best. Keep the change in mainline Linux, land it there, and then backport it, and the vendor tree becomes a thin delta that the merge tooling can apply automatically. The difference in approach is who owns the code. In a downstream-only tree, the fix lives in a repository that only the vendor sees, and the next kernel version brings a conflict instead of a fix. In an upstream-first tree, the fix is in every distro that has already merged it, and the vendor tree carries only the parts that genuinely cannot go upstream.

The tree is also the wrong base for a new product. The kernel version is pinned at 5.10.136, the build configs are named after specific chipsets and boards, and the default branch is an Android 13 release branch for one target. A team starting something new wants a kernel version their platform supports and a configuration they own, not a manifest of someone else's fleet.

One thing the README does not cover, and it is the obvious question for an outsider, is how to build a kernel for a specific device from this tree. The repository has the `build.config.*` files and a `Makefile` that says to use `make help`, and the top level `README` is referenced from it, but the walkthrough is not in the README that is published here.

Editorial conclusion

Adopt kernel-msm if you are building or maintaining Android on Motorola MSM hardware and need the device specific tree rather than a general kernel. Do not adopt it as a base for a new product, since the tree is tied to specific SoCs, specific Android releases and a set of build configs that only make sense for that fleet. Verify first that the branch you want exists, the default is android-13-release-ttz, that the kernel version in the Makefile matches what your bootloader expects, and that any patch you intend to submit carries the subject tag and the Change-Id, Bug and Signed-off-by trailers the README requires.

Frequently asked questions

Official sources

1. Issues
2. MotorolaMobilityLLC/kernel-msm on GitHub
3. README