[PATCH v3 0/4] Documentation: RISC-V: patch-acceptance changes

[PATCH v3 0/4] Documentation: RISC-V: patch-acceptance changes

[Palmer Dabbelt]

This has a small textual change since the v2, but any change to the text
is pretty important so I'm sending out a v3 rather than just silently
squashing it in.  Folks seemed generally OK with it, so unless there's
any other feedback I'll target this for the merge window.

Changes since v2 <https://lore.kernel.org/all/20221013045619.18906-1-palmer@rivosinc.com/>:
* Remove the published timeline wording, to match the standard Linux
  policies.

Changes since v1 <https://lore.kernel.org/all/Yyn9FJ4iuzJTfO1T@spud/t/#mcc9b5e547a2ca2b25d7f78a4d2572f39ddc5593e>:
* Various minor wording changes.
* "UEFI forum specifications" instead of just "UEFI specifications".
* New patch 4 with implementor -> implementer
* Atish and Conor's Reviewed-by.



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 1/4] Documentation: RISC-V: Fix a typo in patch-acceptance

[Palmer Dabbelt]

I just stumbled on this when modifying the docs.

Reviewed-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/riscv/patch-acceptance.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
index dfe0ac5624fb..5da6f9b273d6 100644
--- a/Documentation/riscv/patch-acceptance.rst
+++ b/Documentation/riscv/patch-acceptance.rst
@@ -29,7 +29,7 @@ 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 to accept patches for extensions that
+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.)
-- 
2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[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@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]
Signed-off-by: Palmer Dabbelt <palmer@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
+  standard Linux practice.
+
+(Implementors, may, of course, maintain their own Linux kernel trees containing
+code for any custom extensions that they wish.)
-- 
2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 3/4] Documentation: RISC-V: Mention the UEFI Standards

[Palmer Dabbelt]

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>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/riscv/patch-acceptance.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
index 16b90a31d267..02e6a48809ef 100644
--- a/Documentation/riscv/patch-acceptance.rst
+++ b/Documentation/riscv/patch-acceptance.rst
@@ -20,9 +20,11 @@ Submit Checklist Addendum
 -------------------------
 We'll only accept patches for new modules or extensions if the
 specifications for those modules or extensions are listed as being
-"Frozen" or "Ratified" by the RISC-V Foundation.  (Developers may, of
-course, maintain their own Linux kernel trees that contain code for
-any draft extensions that they wish.)
+unlikely to be incompatibly changed in the future.  For
+specifications from the RISC-V foundation this means "Frozen" or
+"Ratified", for the UEFI forum specifications this means a published
+ECR.  (Developers may, of course, maintain their own Linux kernel trees
+that contain code for any draft extensions that they wish.)
 
 Additionally, the RISC-V specification allows implementors to create
 their own custom extensions.  These custom extensions aren't required
-- 
2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 4/4] Documentation: RISC-V: patch-acceptance: s/implementor/implementer

[Palmer Dabbelt]

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>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 Documentation/riscv/patch-acceptance.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
index 02e6a48809ef..adadbbbf5bf5 100644
--- a/Documentation/riscv/patch-acceptance.rst
+++ b/Documentation/riscv/patch-acceptance.rst
@@ -26,7 +26,7 @@ specifications from the RISC-V foundation this means "Frozen" or
 ECR.  (Developers may, of course, maintain their own Linux kernel trees
 that contain code for any draft extensions that they wish.)
 
-Additionally, the RISC-V specification allows implementors to create
+Additionally, the RISC-V specification allows implementers to create
 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
@@ -37,5 +37,5 @@ RISC-V extensions, we'll only consider patches for extensions that either:
 - Have been implemented in hardware that is either widely available, per
   standard Linux practice.
 
-(Implementors, may, of course, maintain their own Linux kernel trees containing
+(Implementers, may, of course, maintain their own Linux kernel trees containing
 code for any custom extensions that they wish.)
-- 
2.38.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [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@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]
> Signed-off-by: Palmer Dabbelt <palmer@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@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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/4] Documentation: RISC-V: Fix a typo in patch-acceptance

[Heiko Stübner]

Am Mittwoch, 7. Dezember 2022, 03:08:12 CET schrieb Palmer Dabbelt:
> I just stumbled on this when modifying the docs.
> 
> Reviewed-by: Anup Patel <anup@brainfault.org>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

Reviewed-by: Heiko Stuebner <heiko.stuebner@vrull.eu>



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 3/4] Documentation: RISC-V: Mention the UEFI Standards

[Heiko Stübner]

Am Mittwoch, 7. Dezember 2022, 03:08:14 CET schrieb Palmer Dabbelt:
> 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>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
>  Documentation/riscv/patch-acceptance.rst | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
> index 16b90a31d267..02e6a48809ef 100644
> --- a/Documentation/riscv/patch-acceptance.rst
> +++ b/Documentation/riscv/patch-acceptance.rst
> @@ -20,9 +20,11 @@ Submit Checklist Addendum
>  -------------------------
>  We'll only accept patches for new modules or extensions if the
>  specifications for those modules or extensions are listed as being
> -"Frozen" or "Ratified" by the RISC-V Foundation.  (Developers may, of
> -course, maintain their own Linux kernel trees that contain code for
> -any draft extensions that they wish.)
> +unlikely to be incompatibly changed in the future.  For
> +specifications from the RISC-V foundation this means "Frozen" or
> +"Ratified", for the UEFI forum specifications this means a published
> +ECR.  (Developers may, of course, maintain their own Linux kernel trees
> +that contain code for any draft extensions that they wish.)

Reviewed-by: Heiko Stuebner <heiko.stuebner@vrull.eu>



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 4/4] Documentation: RISC-V: patch-acceptance: s/implementor/implementer

[Heiko Stübner]

Am Mittwoch, 7. Dezember 2022, 03:08:15 CET schrieb Palmer Dabbelt:
> 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>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

Reviewed-by: Heiko Stuebner <heiko.stuebner@vrull.eu>



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 0/4] Documentation: RISC-V: patch-acceptance changes

[Palmer Dabbelt]

On Tue, 6 Dec 2022 18:08:11 -0800, Palmer Dabbelt wrote:
> This has a small textual change since the v2, but any change to the text
> is pretty important so I'm sending out a v3 rather than just silently
> squashing it in.  Folks seemed generally OK with it, so unless there's
> any other feedback I'll target this for the merge window.
> 
> Changes since v2 <https://lore.kernel.org/all/20221013045619.18906-1-palmer@rivosinc.com/>:
> * Remove the published timeline wording, to match the standard Linux
>   policies.
> 
> [...]

Applied, thanks!

[1/4] Documentation: RISC-V: Fix a typo in patch-acceptance
      https://git.kernel.org/palmer/c/37f0ab147799
[2/4] Documentation: RISC-V: Allow patches for non-standard behavior
      https://git.kernel.org/palmer/c/936100d4507f
[3/4] Documentation: RISC-V: Mention the UEFI Standards
      https://git.kernel.org/palmer/c/68eabc72023f
[4/4] Documentation: RISC-V: patch-acceptance: s/implementor/implementer
      https://git.kernel.org/palmer/c/a39c636506cb

Best regards,
-- 
Palmer Dabbelt <palmer@rivosinc.com>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Palmer Dabbelt]

On Wed, 07 Dec 2022 07:41:36 PST (-0800), heiko@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@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]
>> Signed-off-by: Palmer Dabbelt <palmer@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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 0/4] Documentation: RISC-V: patch-acceptance changes

[patchwork-bot+linux-riscv]

Hello:

This series was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <palmer@rivosinc.com>:

On Tue,  6 Dec 2022 18:08:11 -0800 you wrote:
> This has a small textual change since the v2, but any change to the text
> is pretty important so I'm sending out a v3 rather than just silently
> squashing it in.  Folks seemed generally OK with it, so unless there's
> any other feedback I'll target this for the merge window.
> 
> Changes since v2 <https://lore.kernel.org/all/20221013045619.18906-1-palmer@rivosinc.com/>:
> * Remove the published timeline wording, to match the standard Linux
>   policies.
> 
> [...]

Here is the summary with links:
  - [v3,1/4] Documentation: RISC-V: Fix a typo in patch-acceptance
    https://git.kernel.org/riscv/c/37f0ab147799
  - [v3,2/4] Documentation: RISC-V: Allow patches for non-standard behavior
    (no matching commit)
  - [v3,3/4] Documentation: RISC-V: Mention the UEFI Standards
    https://git.kernel.org/riscv/c/68eabc72023f
  - [v3,4/4] Documentation: RISC-V: patch-acceptance: s/implementor/implementer
    https://git.kernel.org/riscv/c/a39c636506cb

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv