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