summaryrefslogtreecommitdiff
path: root/Documentation/riscv
diff options
context:
space:
mode:
authorPalmer Dabbelt <palmer@rivosinc.com>2022-12-07 05:08:13 +0300
committerPalmer Dabbelt <palmer@rivosinc.com>2022-12-13 20:38:21 +0300
commit936100d4507f2e9f0be4621b0c698180d65e8264 (patch)
tree40314c51af08a67812379b88bc4fda613820ca0d /Documentation/riscv
parent37f0ab1477994a0d0dc3c1e0de030fae07d37965 (diff)
downloadlinux-936100d4507f2e9f0be4621b0c698180d65e8264.tar.xz
Documentation: RISC-V: Allow patches for non-standard behavior
The patch acceptance policy forbids accepting support for non-standard behavior. This policy was written in order to both steer implementers towards the standards and to avoid coupling the upstream kernel too tightly to vendor-specific features. Those were good goals, but in practice the policy just isn't working: every RISC-V system we have needs vendor-specific behavior in the kernel and we end up taking that support which violates the policy. That's confusing for contributors, which is the main reason we have a written policy in the first place. So let's just start taking code for vendor-defined behavior. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Link: https://lore.kernel.org/all/alpine.DEB.2.21.999.2211181027590.4480@utopia.booyaka.com/ [Palmer: merge in Paul's suggestions] Link: https://lore.kernel.org/r/20221207020815.16214-3-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Diffstat (limited to 'Documentation/riscv')
-rw-r--r--Documentation/riscv/patch-acceptance.rst12
1 files changed, 8 insertions, 4 deletions
diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
index 5da6f9b273d6..d9d628505cd8 100644
--- a/Documentation/riscv/patch-acceptance.rst
+++ b/Documentation/riscv/patch-acceptance.rst
@@ -29,7 +29,11 @@ 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 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.)
+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.
+
+(Implementors, may, of course, maintain their own Linux kernel trees containing
+code for any custom extensions that they wish.)