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

[Conor Dooley]

On Tue, Sep 20, 2022 at 07:01:39AM -0700, Palmer Dabbelt wrote:
> 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

Commit message is cut off here.

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

As you know, I was there so I don't disagree with the sentiment of the
changes & as an employee of a vendor who wants to use a non-standard
extension I welcome the change.

Only comment I have is that the sentence has gotta kinda long. How about
a rephrasing/reworking to something like:
---8<---
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
either: 

- have been officially frozen or ratified by the RISC-V Foundation
- have been implemented in hardare that is publically available or has
  a timeline for availability that has been made public

Hardware that does not meet its published timelines may have support
removed. Implementers, may, of course, maintai their own Linux kernel
trees containing code for any custom extensions that they wish.
---8<---
I think breaking it up like that highlights the two distinct cases, but
maybe that's just me. The o spelling of implementer is in here too.
Again, am I missing some American English thing there?

I think the bit about the hardware is fair too. Gets the point across
and if someone's timelines slip all they have to do is publish the new
timelines...

Since my only comments were stylistic (modulo the potentially existing
spelling mistake) this looks good to me on an idealogical/policy level:
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Thanks,
Conor.