[linux-block.git] / Documentation / riscv / patch-acceptance.rst

.. 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.

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
"Frozen" or "Ratified" by the RISC-V Foundation.  (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 implementors 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 to accept patches for extensions that
have been officially frozen or ratified by the RISC-V Foundation.
(Implementors, may, of course, maintain their own Linux kernel trees
containing code for any custom extensions that they wish.)
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
	19	Submit Checklist Addendum
	20	-------------------------
	21	We'll only accept patches for new modules or extensions if the
	22	specifications for those modules or extensions are listed as being
	23	"Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of
	24	course, maintain their own Linux kernel trees that contain code for
	25	any draft extensions that they wish.)
	26
	27	Additionally, the RISC-V specification allows implementors to create
	28	their own custom extensions. These custom extensions aren't required
	29	to go through any review or ratification process by the RISC-V
	30	Foundation. To avoid the maintenance complexity and potential
	31	performance impact of adding kernel code for implementor-specific
	32	RISC-V extensions, we'll only to accept patches for extensions that
	33	have been officially frozen or ratified by the RISC-V Foundation.
	34	(Implementors, may, of course, maintain their own Linux kernel trees
	35	containing code for any custom extensions that they wish.)