Raspberry Pi linux: a vendor kernel tree on rpi-6.18.y with two CI workflows and no releases

Version identity comes from the Makefile and the branch name, not from a release

There are no GitHub releases in this repository, so the version lives in two places that have to agree. The Makefile header sets VERSION to 6, PATCHLEVEL to 18, and SUBLEVEL to 60, leaves EXTRAVERSION empty, and gives the tree its codename, Baby Opossum Posse. The default branch is rpi-6.18.y, which matches that 6.18 line. For a reproducible kernel source snapshot, pin an exact Git commit; a branch can move and Makefile version numbers do not identify every change. The project description also sets a boundary on where questions belong: issues unrelated to the Linux kernel should go to the community forum at forums.raspberrypi.com, so the issue tracker here is for kernel changes rather than for board support.

The Makefile stops you before anything else if your Make is older than 4.0

The first thing this build does is check its own tools. The Makefile raises an error saying GNU Make >= 4.0 is required when the Make in use lacks the output-sync feature, and it prints your actual MAKE_VERSION in the message, so a failure here is a toolchain problem rather than a configuration problem. It then sets MAKEFLAGS to include -rR, which switches off make's built-in rules and variables, and the comment gives two reasons: it increases performance and it avoids hard-to-debug behaviour. Locale handling is pinned too, with LC_ALL unexported and LC_COLLATE and LC_NUMERIC forced to C before being exported. The build is recursive, and the comment is explicit about the rule sub-Makefiles are supposed to follow, which is that they should only ever modify files in their own directory. What none of this covers is what to build. The same header warns that its comments target the developer and says not to expect to learn how to build the kernel by reading it, pointing instead at the README file in the root.

The default target is __all, and any target starting with two underscores is refused

Running make with no arguments on this tree does something that surprises people coming from other build systems. The default target is declared as PHONY with the name __all, and a guard sits above it that turns any goal beginning with __ into an error stating that those targets are for internal use only. Meanwhile the documentation comment tells you that executing make help gives a list of the usual targets and that more information sits in ./README. What this cannot do is tell you what to type next, since neither the target list nor the build recipe appears in the Makefile itself. The consequence is that the file you would naturally reach for is the one that disclaims the job, so time spent reading Makefile comments for build instructions is wasted by design. Treat make help and ./README as the entry points and the Makefile as something you consult only when you need to know how a target is spelled or why a guard fired.

Everything you are told to read lives under Documentation/, and the online copy is upstream

The README hands you off to documentation immediately. The first pointer is Documentation/admin-guide/README.rst, which is where kernel developers and users are sent to start, and the guides there can be rendered in several formats. Two make targets do the rendering:

make htmldocs

make pdfdocs

The subdirectory is not purely prose, either: it holds various text files, several of them written in Restructured Text markup. The second pointer matters more for anyone running a Raspberry Pi image, which is Documentation/process/changes.rst, described as containing the requirements for building and running the kernel along with the problems that may result from upgrading. What that cannot do is cover this tree specifically, because the same README also points at the formatted documentation online at kernel.org/doc/html/latest/, which is the upstream view rather than the vendor one. The consequence is that when a doc and your kernel disagree, the branch and the Makefile decide, and when you upgrade a board image, changes.rst is the file that tells you what to expect.

Four badges across two branches, and nothing in them proves a kernel booted on hardware

The build status section is the only part of the README with live data in it, and it covers two branches rather than one. There are badges for rpi-6.12.y and for rpi-6.18.y, and each pair points at the same two workflows: kernel-build.yml and dtoverlaycheck.yml. That gives you a second maintenance signal alongside the default branch, since 6.12.y is still being built and checked while 6.18.y is the branch you land on by default. The second workflow name is also the most Raspberry Pi specific signal in the whole repository, since device tree overlays are how the board describes its own hardware to the kernel. What these badges cannot do is tell you the kernel ran on a device. They report that a build completed and that an overlay check passed, and the README says nothing further about hardware validation. The consequence is that a green badge belongs in a review as evidence of a clean compile, not as evidence that a board booted, so any claim about working hardware needs testing you arranged yourself.

samples/ is a catalogue of kernel subsystems, each a Kconfig and Makefile pair

The samples directory is the easiest way to see what this kernel contains, and its layout is uniform. The directory has samples/Kconfig and samples/Makefile at its top and one subdirectory per subsystem or mechanism. The names cover a wide spread: acrn, auxdisplay, binderfs, bpf, cgroup, check-exec, configfs, connector, coresight, damon, fanotify, fprobe, ftrace, hid, hidraw, hung_task, hw_breakpoint, kdb, kfifo, kmemleak, kobject, kprobes, and landlock, among others. Enabling one is a configuration decision rather than a build command, since each sample is wired into Kconfig. What samples cannot do is promise a stable interface. They exist to show how a kernel facility is meant to be used from userspace, and they are not the API surface for your application. The consequence is that a sample is evidence that a facility exists in this tree and a reasonable model for calling it, while the interface itself is the kernel version's business and moves.

The repository records no license, and the tree keeps its own linter and license files

The licensing picture in this repository needs two passes to read. The license field on the repository page reads NOASSERTION, so any tool that trusts that field alone learns nothing at all. The tree itself carries COPYING and a LICENSES/ directory, and the Makefile header opens with an SPDX-License-Identifier of GPL-2.0. What that cannot do is settle the question for a scanner or a downstream packager, which is why you have to read the files rather than the field, and per-file licensing is exactly the kind of thing the kernel tree tracks rather than assumes. The same pattern runs through tooling. The root holds .clang-format, .clippy.toml, .cocciconfig, .pylintrc, .rustfmt.toml, .editorconfig, .get_maintainer.ignore, and .mailmap, so patches are checked by the tools those files configure rather than by taste. The consequence is that a contribution is expected to satisfy the configured formatters before it satisfies a reviewer.

Editorial conclusion

Use this tree when you are building or patching a kernel for Raspberry Pi hardware, or when you need to know what a vendor kernel change did to a subsystem. Ignore it for general Linux questions, which belong on the Raspberry Pi community forum, and for distribution questions it does not answer. Before you build, read Documentation/process/changes.rst for the requirements and upgrade pitfalls, confirm your Make is 4.0 or newer, and check whether the 6.12.y or 6.18.y branch is the one your board image expects.

Frequently asked questions

Official sources

1. Issues
2. raspberrypi/linux on GitHub
3. README