1.. SPDX-License-Identifier: GPL-2.0 2 3arch/riscv maintenance guidelines for developers 4================================================ 5 6Overview 7-------- 8The RISC-V instruction set architecture is developed in the open: 9in-progress drafts are available for all to review and to experiment 10with implementations. New module or extension drafts can change 11during the development process - sometimes in ways that are 12incompatible with previous drafts. This flexibility can present a 13challenge for RISC-V Linux maintenance. Linux maintainers disapprove 14of churn, and the Linux development process prefers well-reviewed and 15tested code over experimental code. We wish to extend these same 16principles to the RISC-V-related code that will be accepted for 17inclusion in the kernel. 18 19Patchwork 20--------- 21 22RISC-V has a patchwork instance, where the status of patches can be checked: 23 24 https://patchwork.kernel.org/project/linux-riscv/list/ 25 26If your patch does not appear in the default view, the RISC-V maintainers have 27likely either requested changes, or expect it to be applied to another tree. 28 29Automation runs against this patchwork instance, building/testing patches as 30they arrive. The automation applies patches against the current HEAD of the 31RISC-V `for-next` and `fixes` branches, depending on whether the patch has been 32detected as a fix. Failing those, it will use the RISC-V `master` branch. 33The exact commit to which a series has been applied will be noted on patchwork. 34Patches for which any of the checks fail are unlikely to be applied and in most 35cases will need to be resubmitted. 36 37Submit Checklist Addendum 38------------------------- 39We'll only accept patches for new modules or extensions if the 40specifications for those modules or extensions are listed as being 41unlikely to be incompatibly changed in the future. For 42specifications from the RISC-V foundation this means "Frozen" or 43"Ratified", for the UEFI forum specifications this means a published 44ECR. (Developers may, of course, maintain their own Linux kernel trees 45that contain code for any draft extensions that they wish.) 46 47Additionally, the RISC-V specification allows implementers to create 48their own custom extensions. These custom extensions aren't required 49to go through any review or ratification process by the RISC-V 50Foundation. To avoid the maintenance complexity and potential 51performance impact of adding kernel code for implementor-specific 52RISC-V extensions, we'll only consider patches for extensions that either: 53 54- Have been officially frozen or ratified by the RISC-V Foundation, or 55- Have been implemented in hardware that is widely available, per standard 56 Linux practice. 57 58(Implementers, may, of course, maintain their own Linux kernel trees containing 59code for any custom extensions that they wish.) 60