summaryrefslogtreecommitdiff
path: root/Documentation/riscv/patch-acceptance.rst
AgeCommit message (Collapse)AuthorFilesLines
2022-12-13Documentation: RISC-V: patch-acceptance: s/implementor/implementerPalmer Dabbelt1-2/+2
Implementor does appear to be a word, but it's not very common. Suggested-by: Conor Dooley <conor@kernel.org> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221207020815.16214-5-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-13Documentation: RISC-V: Mention the UEFI StandardsPalmer Dabbelt1-3/+5
The current patch acceptance policy requires that specifications are approved by the RISC-V foundation, but we rely on external specifications as well. This explicitly calls out the UEFI specifications that we're starting to depend on. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20221207020815.16214-4-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-13Documentation: RISC-V: Allow patches for non-standard behaviorPalmer Dabbelt1-4/+8
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@microchip.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Link: https://lore.kernel.org/all/alpine.DEB.2.21.999.2211181027590.4480@utopia.booyaka.com/ [Palmer: merge in Paul's suggestions] Link: https://lore.kernel.org/r/20221207020815.16214-3-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-12-13Documentation: RISC-V: Fix a typo in patch-acceptancePalmer Dabbelt1-1/+1
I just stumbled on this when modifying the docs. Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20221207020815.16214-2-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2020-01-05Documentation: riscv: add patch acceptance guidelinesPaul Walmsley1-0/+35
Formalize, in kernel documentation, the patch acceptance policy for arch/riscv. In summary, it states that as maintainers, we plan to only accept patches for new modules or extensions that have been frozen or ratified by the RISC-V Foundation. We've been following these guidelines for the past few months. In the meantime, we've received quite a bit of feedback that it would be helpful to have these guidelines formally documented. Based on a suggestion from Matthew Wilcox, we also add a link to this file to Documentation/process/index.rst, to make this document easier to find. The format of this document has also been changed to align to the format outlined in the maintainer entry profiles, in accordance with comments from Jon Corbet and Dan Williams. Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Krste Asanovic <krste@berkeley.edu> Cc: Andrew Waterman <waterman@eecs.berkeley.edu> Cc: Matthew Wilcox <willy@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net>