diff options
Diffstat (limited to 'Documentation/process/maintainer-soc.rst')
| -rw-r--r-- | Documentation/process/maintainer-soc.rst | 48 |
1 files changed, 40 insertions, 8 deletions
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst index 12637530d68f..3ba886f52a51 100644 --- a/Documentation/process/maintainer-soc.rst +++ b/Documentation/process/maintainer-soc.rst @@ -10,7 +10,7 @@ Overview The SoC subsystem is a place of aggregation for SoC-specific code. The main components of the subsystem are: -* devicetrees for 32- & 64-bit ARM and RISC-V +* 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 @@ -30,10 +30,13 @@ 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, each taking care of individual platforms -and driver subdirectories. +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, @@ -43,14 +46,43 @@ 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. The main SoC maintainers can be reached via the -alias soc@kernel.org if there is no platform-specific maintainer, or if they -are unresponsive. +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 (scripts/get_maintainer.pl might not provide correct +addresses in such case). + +Submitting Patches to the Main SoC Maintainers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The main SoC maintainers can be reached via the alias soc@kernel.org only in +following cases: + +1. There are no platform-specific maintainers. + +2. Platform-specific maintainers are unresponsive. + +3. Introducing a completely new SoC platform. Such new SoC work should be sent + first to common mailing lists, pointed out by scripts/get_maintainer.pl, for + community review. After positive community review, work should be sent to + soc@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS + files, MAINTAINERS file entry and optionally initial drivers with their + Devicetree bindings. The MAINTAINERS file entry should list new + platform-specific maintainers, who are going to be responsible for handling + patches for the platform from now on. + +Note that the soc@kernel.org is usually not the place to discuss the patches, +thus work sent to this address should be already considered as acceptable by +the community. + Information for (new) Submaintainers ------------------------------------ @@ -65,8 +97,8 @@ Perhaps one of the most important things to highlight is that dt-bindings document the ABI between the devicetree and the kernel. Please read Documentation/devicetree/bindings/ABI.rst. -If changes are being made to a devicetree that are incompatible with old -kernels, the devicetree patch should not be applied until the driver is, or an +If changes are being made to a DTS that are incompatible with old +kernels, the DTS patch should not be applied until the driver is, or an appropriate time later. Most importantly, any incompatible changes should be clearly pointed out in the patch description and pull request, along with the expected impact on existing users, such as bootloaders or other operating |