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

Palmer Dabbelt palmer at rivosinc.com
Tue Dec 13 09:39:47 PST 2022


On Wed, 07 Dec 2022 07:41:36 PST (-0800), heiko at sntech.de wrote:
> 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.

Thanks, that's fixed and these are on for-next.

>
> 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.)
>>
>
>
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



More information about the linux-riscv mailing list