On Thu, Oct 13, 2022 at 10:26 AM Palmer Dabbelt <palmer@xxxxxxxxxxxx> wrote: > > From: Palmer Dabbelt <palmer@xxxxxxxxxxxx> > > 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@xxxxxxxxxxxxx> > Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx> Looks good to me from a KVM RISC-V perspective. Reviewed-by: Anup Patel <anup@xxxxxxxxxxxxxx> Regards, Anup > --- > Documentation/riscv/patch-acceptance.rst | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst > index 5da6f9b273d6..0a6199233ede 100644 > --- a/Documentation/riscv/patch-acceptance.rst > +++ b/Documentation/riscv/patch-acceptance.rst > @@ -29,7 +29,12 @@ 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 accept 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 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.38.0 >
