From ed843ae947f83b1d0758d8eec2e8690e3d716d6e Mon Sep 17 00:00:00 2001 From: Costa Shulyupin Date: Sat, 30 Sep 2023 21:52:00 +0300 Subject: docs: move riscv under arch and fix all in-tree references. Architecture-specific documentation is being moved into Documentation/arch/ as a way of cleaning up the top-level documentation directory and making the docs hierarchy more closely match the source hierarchy. Signed-off-by: Costa Shulyupin Reviewed-by: Conor Dooley Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20230930185354.3034118-1-costa.shul@redhat.com --- Documentation/riscv/patch-acceptance.rst | 59 -------------------------------- 1 file changed, 59 deletions(-) delete mode 100644 Documentation/riscv/patch-acceptance.rst (limited to 'Documentation/riscv/patch-acceptance.rst') diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst deleted file mode 100644 index 634aa222b410..000000000000 --- a/Documentation/riscv/patch-acceptance.rst +++ /dev/null @@ -1,59 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -arch/riscv maintenance guidelines for developers -================================================ - -Overview --------- -The RISC-V instruction set architecture is developed in the open: -in-progress drafts are available for all to review and to experiment -with implementations. New module or extension drafts can change -during the development process - sometimes in ways that are -incompatible with previous drafts. This flexibility can present a -challenge for RISC-V Linux maintenance. Linux maintainers disapprove -of churn, and the Linux development process prefers well-reviewed and -tested code over experimental code. We wish to extend these same -principles to the RISC-V-related code that will be accepted for -inclusion in the kernel. - -Patchwork ---------- - -RISC-V has a patchwork instance, where the status of patches can be checked: - - https://patchwork.kernel.org/project/linux-riscv/list/ - -If your patch does not appear in the default view, the RISC-V maintainers have -likely either requested changes, or expect it to be applied to another tree. - -Automation runs against this patchwork instance, building/testing patches as -they arrive. The automation applies patches against the current HEAD of the -RISC-V `for-next` and `fixes` branches, depending on whether the patch has been -detected as a fix. Failing those, it will use the RISC-V `master` branch. -The exact commit to which a series has been applied will be noted on patchwork. -Patches for which any of the checks fail are unlikely to be applied and in most -cases will need to be resubmitted. - -Submit Checklist Addendum -------------------------- -We'll only accept patches for new modules or extensions if the -specifications for those modules or extensions are listed as being -unlikely to be incompatibly changed in the future. For -specifications from the RISC-V foundation this means "Frozen" or -"Ratified", for the UEFI forum specifications this means a published -ECR. (Developers may, of course, maintain their own Linux kernel trees -that contain code for any draft extensions that they wish.) - -Additionally, the RISC-V specification allows implementers to create -their own custom extensions. These custom extensions aren't required -to go through any review or ratification process by the RISC-V -Foundation. To avoid the maintenance complexity and potential -performance impact of adding kernel code for implementor-specific -RISC-V extensions, we'll only consider patches for extensions that either: - -- Have been officially frozen or ratified by the RISC-V Foundation, or -- Have been implemented in hardware that is widely available, per standard - Linux practice. - -(Implementers, may, of course, maintain their own Linux kernel trees containing -code for any custom extensions that they wish.) -- cgit v1.2.3