From patchwork Tue Sep 24 13:08:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Krzysztof Kozlowski X-Patchwork-Id: 13810968 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3018ACF9C6B for ; Tue, 24 Sep 2024 13:10:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=bBqAdCr/Tagnq8w6gUFIkMYJLmwI/sDayqKEKgevhjY=; b=UVbbOyTRwhsrKdimW9QF3KlSp0 OrlVdc2KRijUbcVCxdfblGcS5pbV2qJxNxHufJbfAQw2vOWGMVAa9pFNQAAI3uaxYU81ubOVjyn5O x2mgPb0pT+YY+W4kOkEJZZUqQou5p7/Ckfst+YkBTBFkoMxdZpsZ1kAUmNWizt6rSwrf/N+rCrDDD BhXzo9Ad4+3f2op2GyI9wtEZmHz3ahbkAU4R3q7PJEjixWdI+VbMrxDpdQVa9mdOYcrACpByG53Vw Zo+iwUrNKfCBoljxZVjMCQKGvhyxGYZesV63vLjYKGEooKvvXvKGEdrXp/tqxL6o0ZNwgh62TNPi9 d+UNVmSg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1st5Iv-00000002P5S-0lFv; Tue, 24 Sep 2024 13:10:09 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1st5Hk-00000002OtK-2giW for linux-arm-kernel@lists.infradead.org; Tue, 24 Sep 2024 13:08:58 +0000 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a8a7dddd2bdso57992066b.2 for ; Tue, 24 Sep 2024 06:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1727183334; x=1727788134; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=bBqAdCr/Tagnq8w6gUFIkMYJLmwI/sDayqKEKgevhjY=; b=zcW6A547ivBDgRr2fr9/z60ayWd8DmSEMJKMiMzu81qkKKNvGaVwHRXMVZaP0yd1tu oIi43/NZMkcSfqDhviGgnp774Kfnz9LywFLkuYYLd9GOWW9aBQIK+/f9W6MYzccyFQW3 Cuw58xpBy6i71sS5rARU1LScOlq3/AYAyDYByBWhXHZ70HZm4fR3mQAKTjmSoG4sGB1E wdjoBKU5UBgb2QYLJTX/2/9+jPwJ2BF1io+w3BOYfXt6COGibdKjhv7CNDhDFxLxp+EM bW//xOqNgXa+wj3WjoDZZMHBF9qVcd4Vg4E9Tv+6yUq2tTNxa6cWX2BsgGtli4CCNuPq lf1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727183334; x=1727788134; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bBqAdCr/Tagnq8w6gUFIkMYJLmwI/sDayqKEKgevhjY=; b=n+CIUvBmROG48drUKK5r6Gruz0OEqw1QuHSi0F+l2Jd19SsEMZ6ULXZF8Krs5UDN+S Izol4Fd9uBkZioTTBQv/v5JcKJ+M29Crc2yUCL4ll4Uq33DwKldYX1BfVbFWlCNaH3j4 Khvj/1KWWuKizbTCAc/+Jn12dmLoDsVP6C9Vu2DKv6caaAIxpl2Q2OU97A5XfOcNHD23 IPAUhHK1YvRnDHwVC3c6BM1SbJJhLifr1JS1SnwsijyQDFnnONmc+2O2HBZxjnvI4K7i /u4+zNdyFyMH2cKJfJrENxiEE9ItBsby+MJFGgcZ+Wd+9Mc5CBAglswmvswQ4hD/xJ8+ NPnw== X-Forwarded-Encrypted: i=1; AJvYcCXMMG4uayWIRiHOsGLTyZ17ruoE6+AcU19QsEOzogyaR7k8mmh65YC88Ji5QflhosIJRRtCSfLbnM8Q1BSkuAy7@lists.infradead.org X-Gm-Message-State: AOJu0YyC4bPS5chut58wP/8fPwV8nnyakGizLu8lJ7Poe86yJxFfrywa FhJzXapdRXi41Ae/48s/+8f8zdqBMGbClqLF5RY9nb5bYaJx59k8oCoHSdUcud8= X-Google-Smtp-Source: AGHT+IG141L2UlovN7HIS3we1HyzW+NcX2RskLqTWDHr34a9VPY4jl2ref868d0s1ndXxBhKwv/sJA== X-Received: by 2002:a17:906:dc8f:b0:a8d:2de6:cb59 with SMTP id a640c23a62f3a-a90d4fc3661mr716363766b.3.1727183333891; Tue, 24 Sep 2024 06:08:53 -0700 (PDT) Received: from krzk-bin.. ([178.197.211.167]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93930f8440sm82236666b.182.2024.09.24.06.08.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Sep 2024 06:08:53 -0700 (PDT) From: Krzysztof Kozlowski To: Arnd Bergmann , Olof Johansson , soc@kernel.org, Jonathan Corbet , linux-arm-kernel@lists.infradead.org, workflows@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski , Linus Walleij , Alexandre Belloni , Will Deacon , Kevin Hilman , Palmer Dabbelt , Geert Uytterhoeven , Conor Dooley , =?utf-8?q?Heiko_St=C3=BCbner?= Subject: [PATCH] Documentation/process: maintainer-soc: clarify submitting patches Date: Tue, 24 Sep 2024 15:08:31 +0200 Message-ID: <20240924130831.38861-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240924_060856_705797_6D0A34DC X-CRM114-Status: GOOD ( 18.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Patches for SoCs are expected to be picked up by SoC submaintainers. The main SoC maintainers should be addressed only in few cases. Rewrite the section about maintainer handling to document above expectation. Signed-off-by: Krzysztof Kozlowski Cc: Linus Walleij Cc: Alexandre Belloni Cc: Will Deacon Cc: Kevin Hilman Cc: Palmer Dabbelt Cc: Geert Uytterhoeven Cc: Conor Dooley Cc: Heiko Stübner --- During our LPC ad-hoc BoF, we discussed improving Maintainer SoC docs and I think I volunteered to write something. The trouble is that whatever I won't write in my notes, escapes my memory. I believe this is what we discussed. Was there anything more to write/document? --- Documentation/process/maintainer-soc.rst | 42 +++++++++++++++++++++--- 1 file changed, 37 insertions(+), 5 deletions(-) diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst index 12637530d68f..dc0136e8d852 100644 --- a/Documentation/process/maintainer-soc.rst +++ b/Documentation/process/maintainer-soc.rst @@ -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 usual 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 after community review. 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 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 not a place to discuss the patches, thus work +sent to this address should be already considered as acceptable by the +community. + Information for (new) Submaintainers ------------------------------------