Lines Matching +full:on +full:- +full:soc
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 -----------
37 small group of people are capable of maintaining. Instead, the SoC subsystem
42 on a vendor level, responsible for multiple product lines. For several reasons,
48 sending pull requests to the main SoC tree. These trees are usually, but not
51 What the SoC tree is not, however, is a location for architecture-specific code
55 Submitting Patches for Given SoC
58 All typical platform related patches should be sent via SoC submaintainers
59 (platform-specific maintainers). This includes also changes to per-platform or
63 Submitting Patches to the Main SoC Maintainers
66 The main SoC maintainers can be reached via the alias soc@kernel.org only in
69 1. There are no platform-specific maintainers.
71 2. Platform-specific maintainers are unresponsive.
73 3. Introducing a completely new SoC platform. Such new SoC work should be sent
76 soc@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS
79 platform-specific maintainers, who are going to be responsible for handling
80 patches for the platform from now on.
82 Note that the soc@kernel.org is usually not the place to discuss the patches,
87 ------------------------------------
96 Perhaps one of the most important things to highlight is that dt-bindings
104 expected impact on existing users, such as bootloaders or other operating
117 warnings in the "make dtbs_check" step. If a devicetree change depends on
118 missing additions to a header file in include/dt-bindings/, it will fail the
123 * Avoid defining custom macros in include/dt-bindings/ for hardware constants
124 that can be derived from a datasheet -- binding macros in header files should
144 platform that are set at the SoC level, like CPU cores, are contained in a file
145 named $soc.dtsi, for example, jh7100.dtsi. Integration details, that will vary
146 from board to board, are described in $soc-$board.dts. An example of this is
147 jh7100-beaglev-starlight.dts. Often many boards are variations on a theme, and
148 frequently there are intermediate files, such as jh7100-common.dtsi, which sit
149 between the $soc.dtsi and $soc-$board.dts files, containing the descriptions of
152 Some platforms also have System on Modules, containing an SoC, which are then
153 integrated into several different boards. For these platforms, $soc-$som.dtsi
154 and $soc-$som-$board.dts are typical.
156 Directories are usually named after the vendor of the SoC at the time of its
163 with the dt-bindings that describe the ABI. Please read the section
164 "Running checks" of Documentation/devicetree/bindings/writing-schema.rst for
165 more information on the validation of devicetrees.
168 add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
176 Just as the main SoC tree has several branches, it is expected that
179 SoC maintainers. Each branch should be usable by itself and avoid
180 regressions that originate from dependencies on other branches.
182 Small sets of patches can also be sent as separate emails to soc@kernel.org,
186 top-level branches, e.g. for a treewide rework, or the addition of new SoC
191 SoC tree. An example here would be one branch for devicetree warning fixes, one
199 While there is no cut-off time for late pull requests, it helps to only send
208 summarising the changes in the pull request. For more detail on sending pull
209 requests, please see Documentation/maintainer/pull-requests.rst.