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

[Heiko Stübner]

Am Mittwoch, 7. Dezember 2022, 03:08:13 CET schrieb Palmer Dabbelt:
> 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 at microchip.com>
> Reviewed-by: Anup Patel <anup at brainfault.org>
> Signed-off-by: Paul Walmsley <paul.walmsley at sifive.com>
> Link: https://lore.kernel.org/all/alpine.DEB.2.21.999.2211181027590.4480@utopia.booyaka.com/
> [Palmer: merge in Paul's suggestions]
> Signed-off-by: Palmer Dabbelt <palmer at rivosinc.com>
> ---
>  Documentation/riscv/patch-acceptance.rst | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
> index 5da6f9b273d6..16b90a31d267 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 either widely available, per

I guess the "either" should go, as there is no "or" part.

Other than that
Reviewed-by: Heiko Stuebner <heiko.stuebner at vrull.eu>

> +  standard Linux practice.
> +
> +(Implementors, may, of course, maintain their own Linux kernel trees containing
> +code for any custom extensions that they wish.)
>