[PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior

[Palmer Dabbelt]

The patch acceptance policy forbids accepting support for non-standard
behavior.  This policy was written in order to both steer implementors
towards the standards and to avoid

So let's just start taking code for vendor-defined extensions.

Signed-off-by: Palmer Dabbelt <palmer at rivosinc.com>
---
This was discussed at Plumbers, but as with any policy change it's
important to make sure everyone has time to chime in.  I intend on
letting this sit on the lists for a bit to make sure everyone has a
chance to comment, but in practice we're already regularly violating
these policies so I'm going to just keep going with the status-quo in
the meantime.

I'm also still not quite sure how to write down the hardware
requirement: the intent is to make this more or less in line with other
kernel policies, with the added wrinkle that RISC-V is a bit more
distributed than other systems and thus has more core functionality that
is vendor-defined.  Hence the need to allow some code to go in earlier
than a requirement for publicly-available hardware would allow.
---
 Documentation/riscv/patch-acceptance.rst | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
index 5da6f9b273d6..8087718556da 100644
--- a/Documentation/riscv/patch-acceptance.rst
+++ b/Documentation/riscv/patch-acceptance.rst
@@ -30,6 +30,10 @@ 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.)
+have been officially frozen or ratified by the RISC-V Foundation, or
+for extensions that have been implemented in hardware that is either
+widely available or for which a timeline for availability has been
+made public.  Hardware that does not meet its published timelines may
+have support removed.  (Implementors, may, of course, maintain their
+own Linux kernel trees containing code for any custom extensions that
+they wish.)
-- 
2.34.1