From aeb218d900e3ea2cc3878ba92cb4758227075358 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Wed, 9 Oct 2024 10:12:19 +0100 Subject: docs: netdev: document guidance on cleanup patches The purpose of this section is to document what is the current practice regarding clean-up patches which address checkpatch warnings and similar problems. I feel there is a value in having this documented so others can easily refer to it. Clearly this topic is subjective. And to some extent the current practice discourages a wider range of patches than is described here. But I feel it is best to start somewhere, with the most well established part of the current practice. Signed-off-by: Simon Horman Link: https://patch.msgid.link/20241009-doc-mc-clean-v2-1-e637b665fa81@kernel.org Signed-off-by: Jakub Kicinski --- Documentation/process/maintainer-netdev.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation/process') diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index c9edf9e7362d..1ae71e31591c 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -355,6 +355,8 @@ just do it. As a result, a sequence of smaller series gets merged quicker and with better review coverage. Re-posting large series also increases the mailing list traffic. +.. _rcs: + Local variable ordering ("reverse xmas tree", "RCS") ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -391,6 +393,21 @@ APIs and helpers, especially scoped iterators. However, direct use of ``__free()`` within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function. +Clean-up patches +~~~~~~~~~~~~~~~~ + +Netdev discourages patches which perform simple clean-ups, which are not in +the context of other work. For example: + +* Addressing ``checkpatch.pl`` warnings +* Addressing :ref:`Local variable ordering` issues +* Conversions to device-managed APIs (``devm_`` helpers) + +This is because it is felt that the churn that such changes produce comes +at a greater cost than the value of such clean-ups. + +Conversely, spelling and grammar fixes are not discouraged. + Resending after review ~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 29ce0bca6d5fc0f14a0b7a2c6551128fc27cb8db Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 25 Sep 2024 11:56:35 +0200 Subject: Documentation/process: maintainer-soc: clarify submitting patches MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Reviewed-by: Linus Walleij Reviewed-by: Kevin Hilman Reviewed-by: Bagas Sanjaya 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 Link: https://lore.kernel.org/r/20240925095635.30452-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann --- Documentation/process/maintainer-soc.rst | 42 ++++++++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 5 deletions(-) (limited to 'Documentation/process') diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst index 12637530d68f..fe9d8bcfbd2b 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 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 ------------------------------------ -- cgit v1.2.3