Documentation/process/maintainer-soc.rst

1 .. SPDX-License-Identifier: GPL-2.0
4 SoC Subsystem
8 --------
10 The SoC subsystem is a place of aggregation for SoC-specific code.
13 * devicetrees for 32- & 64-bit ARM and RISC-V
14 * 32-bit ARM board files (arch/arm/mach*)
15 * 32- & 64-bit ARM defconfigs
16 * SoC-specific drivers across architectures, in particular for 32- & 64-bit
17   ARM, RISC-V and Loongarch
19 These "SoC-specific drivers" do not include clock, GPIO etc drivers that have
20 other top-level maintainers. The drivers/soc/ directory is generally meant
21 for kernel-internal drivers that are used by other drivers to provide SoC-
22 specific functionality like identifying an SoC revision or interfacing with
25 The SoC subsystem also serves as an intermediate location for changes to
27 of new platforms, or the removal of existing ones, often go through the SoC
30 The main SoC tree is housed on git.kernel.org:
31   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
34 small group of people are capable of maintaining.  Instead, the SoC subsystem
39 on a vendor level, responsible for multiple product lines.  For several reasons,
45 sending pull requests to the main SoC tree.  These trees are usually, but not
46 always, listed in MAINTAINERS.  The main SoC maintainers can be reached via the
47 alias soc@kernel.org if there is no platform-specific maintainer, or if they
50 What the SoC tree is not, however, is a location for architecture-specific code
55 ------------------------------------
64 Perhaps one of the most important things to highlight is that dt-bindings
72 expected impact on existing users, such as bootloaders or other operating
85 warnings in the "make dtbs_check" step.  If a devicetree change depends on
86 missing additions to a header file in include/dt-bindings/, it will fail the
91 * Avoid defining custom macros in include/dt-bindings/ for hardware constants
92   that can be derived from a datasheet -- binding macros in header files should
112 platform that are set at the SoC level, like CPU cores, are contained in a file
113 named $soc.dtsi, for example, jh7100.dtsi.  Integration details, that will vary
114 from board to board, are described in $soc-$board.dts.  An example of this is
115 jh7100-beaglev-starlight.dts.  Often many boards are variations on a theme, and
116 frequently there are intermediate files, such as jh7100-common.dtsi, which sit
117 between the $soc.dtsi and $soc-$board.dts files, containing the descriptions of
120 Some platforms also have System on Modules, containing an SoC, which are then
121 integrated into several different boards. For these platforms, $soc-$som.dtsi
122 and $soc-$som-$board.dts are typical.
124 Directories are usually named after the vendor of the SoC at the time of its
131 with the dt-bindings that describe the ABI.  Please read the section
132 "Running checks" of Documentation/devicetree/bindings/writing-schema.rst for
133 more information on the validation of devicetrees.
136 add any new warnings.  For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
144 Just as the main SoC tree has several branches, it is expected that
147 SoC maintainers.  Each branch should be usable by itself and avoid
148 regressions that originate from dependencies on other branches.
150 Small sets of patches can also be sent as separate emails to soc@kernel.org,
154 top-level branches, e.g. for a treewide rework, or the addition of new SoC
159 SoC tree.  An example here would be one branch for devicetree warning fixes, one
167 While there is no cut-off time for late pull requests, it helps to only send
176 summarising the changes in the pull request.  For more detail on sending pull
177 requests, please see Documentation/maintainer/pull-requests.rst.