Documentation/arch/riscv/patch-acceptance.rst

   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
  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
  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
  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.)
  46
  47 Additionally, the RISC-V specification allows implementers to create
  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
  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
  58 (Implementers, may, of course, maintain their own Linux kernel trees containing
  59 code for any custom extensions that they wish.)