Documentation/process/maintainer-soc.rst

Source file repositories/reference/linux-study-clean/Documentation/process/maintainer-soc.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/maintainer-soc.rst
Extension
.rst
Size
10036 bytes
Lines
220
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

=============
SoC Subsystem
=============

Overview
--------

The SoC subsystem is a place of aggregation for SoC-specific code.
The main components of the subsystem are:

* devicetrees (DTS) for 32- & 64-bit ARM and RISC-V
* 32-bit ARM board files (arch/arm/mach*)
* 32- & 64-bit ARM defconfigs
* SoC-specific drivers across architectures, in particular for 32- & 64-bit
  ARM, RISC-V and Loongarch

These "SoC-specific drivers" do not include clock, GPIO etc drivers that have
other top-level maintainers. The drivers/soc/ directory is generally meant
for kernel-internal drivers that are used by other drivers to provide SoC-
specific functionality like identifying an SoC revision or interfacing with
power domains.

The SoC subsystem also serves as an intermediate location for changes to
drivers/bus, drivers/firmware, drivers/reset and drivers/memory.  The addition
of new platforms, or the removal of existing ones, often go through the SoC
tree as a dedicated branch covering multiple subsystems.

The main SoC tree is housed on git.kernel.org:
  https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/

Maintainers
-----------

Clearly this is quite a wide range of topics, which no one person, or even
small group of people are capable of maintaining.  Instead, the SoC subsystem
is comprised of many submaintainers (platform maintainers), each taking care of
individual platforms and driver subdirectories.
In this regard, "platform" usually refers to a series of SoCs from a given
vendor, for example, Nvidia's series of Tegra SoCs.  Many submaintainers operate
on a vendor level, responsible for multiple product lines.  For several reasons,
including acquisitions/different business units in a company, things vary
significantly here.  The various submaintainers are documented in the
MAINTAINERS file.

Most of these submaintainers have their own trees where they stage patches,
sending pull requests to the main SoC tree.  These trees are usually, but not
always, listed in MAINTAINERS.

What the SoC tree is not, however, is a location for architecture-specific code
changes.  Each architecture has its own maintainers that are responsible for
architectural details, CPU errata and the like.

Submitting Patches for Given SoC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All typical platform related patches should be sent via SoC submaintainers
(platform-specific maintainers).  This includes also changes to per-platform or
shared defconfigs. Note that scripts/get_maintainer.pl might not provide
correct addresses for the shared defconfig, so ignore its output and manually
create CC-list based on MAINTAINERS file or use something like
``scripts/get_maintainer.pl -f drivers/soc/FOO/``.

Submitting Patches to the Main SoC Maintainers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The main SoC maintainers can be reached via the alias soc@kernel.org only in
following cases:

Annotation

Implementation Notes