User guide

This page serves the purpose of providing pointers and a brief introduction to contributing to the Linux Kernel, using the tools available as well as wrappers maintained by Analog Devices Inc.

Tip

When using ADI Linux repository, the Continuous integration system automates most checks inside a container (container). See Interactive run for interactive usage.

Code checkers

There are many checkers to catch issues before submitting changes to the Kernel mailing lists. ci/build.sh combines all of the checkers so that they can be run with one command using a standard configuration. The checkers supported by build.sh are as follows.

Checkpatch

Checkpatch (scripts/checkpatch.pl) is a perl script which checks for trivial style violations in patches and optionally corrects them. Checkpatch can also be run on file contexts and without the kernel tree.

It is the bare-minimum tool before submitting any patch series.

Usage:

./scripts/checkpatch.pl [OPTION]... [FILE]...

Important

You must always adjust the style to match the guidelines of the Subsytems you are collaborating to.

To run it as a low-budget lsp server, do:

while true; do \
  scripts/checkpatch.pl --color=always drivers/power/supply/max77928_charger.c  \
                        --strict \
                        --ignore FILE_PATH_CHANGES \
                        --ignore LONG_LINE \
                        --ignore LONG_LINE_STRING \
                        --ignore LONG_LINE_COMMENT \
                        --ignore PARENTHESIS_ALIGNMENT \
                        --ignore CAMELCASE \
                        --ignore UNDOCUMENTED_DT_STRING \
                        --strict \ > /tmp/output ; clear ; cat /tmp/output ; \
done

Sparse and smatch

Sparse is a semantic checker for C programs; it can be used to find a number of potential problems with kernel code. Usage:

~/linux$

make C=1

And Smatch is a static analysis tool for C mostly for the linux kernel. Usage:

~/linux$

make C=1 CHECK="smatch -p=kernel"

Further reading: Finding locking bugs with Smatch

GCC fanalyzer

GCC’s -fanalyzer enables an static analysis of program flow which looks for “interesting” interprocedural paths through the code, and issues warnings for problems found on them.

Since it is a flag, it must be appended to the compile command, either to the KCFLAGS:

~/linux$

make KCFLAGS=" -fanalyzer"

To analyze a single file, generate compile commands with ./scripts/clang-tools/gen_compile_commands.py, extract the compile command for the .c file and append -fanalyzer.

Clang static analyzer

Clang static analyzer is a source code analysis tool that finds bugs in C, C++, and Objective-C programs.

Since it is a flag, it must be appended to the compile command, either to the KCFLAGS:

~/linux$

make LLVM=1 KCFLAGS=" --analyze -Xanalyzer"

To analyze a single file, generate compile commands with ./scripts/clang-tools/gen_compile_commands.py, extract the compile command for the .c file and append --analyze -Xanalyzer.

Devicetree

The “Open Firmware Device Tree”, or simply Devicetree (DT), is a data structure and language for describing hardware. More specifically, it is a description of hardware that is readable by an operating system so that the operating system doesn’t need to hard code details of the machine.

Even though some devicetrees are provided with the Linux Kernel, in general, a custom devicetree will need to be written to describe a specific board or device, using the protopytes provided by the Documentation/devicetree/bindings/**/*.yaml files.

When submitting dt-bindings, you must check:

~/linux$

make dt_binding_chec CONFIG_DTC=y DT_CHECKER_FLAGS=-m  DT_SCHEMA_FILES="./path/to/.yaml"

For warnings and erros and resolve accordingly.

B4

B4 is a tool created to make it easier for project developers and maintainers to use a distributed development workflow that relies on patches and distribution lists for code contributions and review.

Take some time to try it out, and understand how it simplies many tasks. B4 tools is not currently leveraged by continuous integration, and you must run it locally.

The section that you will most interested in is the Contributor overview, where the contributor workflow is extensively detailed, as well as the tools to ease it, such as b4 prep, b4 send, and b4 trailers.

Subsytems

The Linux kernel is organized into subsystems—logical divisions around functionality such as core APIs (memory, scheduling, locking, timers), driver interfaces (networking, storage, input, etc.), and various device-oriented modules (IIO, USB, SPI, etc.). Each subsystem encapsulates its own APIs, conventions, and lifecycle, helping maintain modularity and clarity. For an up-to-date map of these subsystems and their interfaces, see Kernel subsystem documentation.

IIO Subsytem

The Industrial I/O subsystem is intended to provide support for devices that in some senses are analog to digital or digital to analog converters (ADCs, DACs). Devices that fall into this category are: ADCs, accelerometers, gyros, IMUs, capacitance to digital converters, pressure sensors, light and proximity sensors, temperature sensors, magnetometers, DACs, DDS (Direct Digital Synthesis), variable/programmable gain amplifiers (VGA, PGA). These devices typically would be connected via SPI or I2C.

The overall aim is to fill the gap between the somewhat similar hwmon and input subsystems. Hwmon is very much directed at low sample rate sensors used in applications such as fan speed control and temperature measurement.

To continuous capture data based on a trigger source, Industrial IIO device buffers are used.