Commit 6e66e96e authored by Palmer Dabbelt's avatar Palmer Dabbelt

Merge patch series "Documentation: RISC-V: patch-acceptance changes"

Palmer Dabbelt <palmer@rivosinc.com> says:

We've had a patch acceptance policy that doesn't match reality, this
changes the policy and also makes some more minor cleanups as well.

* b4-shazam-merge:
  Documentation: RISC-V: patch-acceptance: s/implementor/implementer
  Documentation: RISC-V: Mention the UEFI Standards
  Documentation: RISC-V: Allow patches for non-standard behavior
  Documentation: RISC-V: Fix a typo in patch-acceptance

Link: https://lore.kernel.org/r/20221207020815.16214-1-palmer@rivosinc.comSigned-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
parents c528ef08 a39c6365
...@@ -20,16 +20,22 @@ Submit Checklist Addendum ...@@ -20,16 +20,22 @@ Submit Checklist Addendum
------------------------- -------------------------
We'll only accept patches for new modules or extensions if the We'll only accept patches for new modules or extensions if the
specifications for those modules or extensions are listed as being specifications for those modules or extensions are listed as being
"Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of unlikely to be incompatibly changed in the future. For
course, maintain their own Linux kernel trees that contain code for specifications from the RISC-V foundation this means "Frozen" or
any draft extensions that they wish.) "Ratified", for the UEFI forum specifications this means a published
ECR. (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 Additionally, the RISC-V specification allows implementers to create
their own custom extensions. These custom extensions aren't required their own custom extensions. These custom extensions aren't required
to go through any review or ratification process by the RISC-V to go through any review or ratification process by the RISC-V
Foundation. To avoid the maintenance complexity and potential Foundation. To avoid the maintenance complexity and potential
performance impact of adding kernel code for implementor-specific performance impact of adding kernel code for implementor-specific
RISC-V extensions, we'll only to accept patches for extensions that RISC-V extensions, we'll only consider patches for extensions that either:
have been officially frozen or ratified by the RISC-V Foundation.
(Implementors, may, of course, maintain their own Linux kernel trees - Have been officially frozen or ratified by the RISC-V Foundation, or
containing code for any custom extensions that they wish.) - Have been implemented in hardware that is widely available, per standard
Linux practice.
(Implementers, may, of course, maintain their own Linux kernel trees containing
code for any custom extensions that they wish.)
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment