diff options
| author | Palmer Dabbelt <palmer@rivosinc.com> | 2022-12-06 18:08:13 -0800 |
|---|---|---|
| committer | Palmer Dabbelt <palmer@rivosinc.com> | 2022-12-13 09:38:21 -0800 |
| commit | 936100d4507f2e9f0be4621b0c698180d65e8264 (patch) | |
| tree | 40314c51af08a67812379b88bc4fda613820ca0d | |
| parent | 37f0ab1477994a0d0dc3c1e0de030fae07d37965 (diff) | |
| download | linux-936100d4507f2e9f0be4621b0c698180d65e8264.tar.gz | |
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>
| -rw-r--r-- | Documentation/riscv/patch-acceptance.rst | 12 |
1 files changed, 8 insertions, 4 deletions
diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst index 5da6f9b273d6c3..d9d628505cd847 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.) |