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

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

[Palmer Dabbelt]

I just stumbled on this when modifying the docs.

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.34.1


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

[PATCH 2/3] 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 implementors
towards the standards and to avoid

So let's just start taking code for vendor-defined extensions.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
This was discussed at Plumbers, but as with any policy change it's
important to make sure everyone has time to chime in.  I intend on
letting this sit on the lists for a bit to make sure everyone has a
chance to comment, but in practice we're already regularly violating
these policies so I'm going to just keep going with the status-quo in
the meantime.

I'm also still not quite sure how to write down the hardware
requirement: the intent is to make this more or less in line with other
kernel policies, with the added wrinkle that RISC-V is a bit more
distributed than other systems and thus has more core functionality that
is vendor-defined.  Hence the need to allow some code to go in earlier
than a requirement for publicly-available hardware would allow.
---
 Documentation/riscv/patch-acceptance.rst | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
index 5da6f9b273d6..8087718556da 100644
--- a/Documentation/riscv/patch-acceptance.rst
+++ b/Documentation/riscv/patch-acceptance.rst
@@ -30,6 +30,10 @@ 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.)
+have been officially frozen or ratified by the RISC-V Foundation, or
+for extensions that 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.34.1


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

[PATCH 3/3] 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.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
This also came up during the Plumbers BoF.  The other discussed options
were to wait for an ACPI/UEFI specification to be published or to just
not wait at all, but this middle ground matches how we handle the RISC-V
specifications and it seems like there was broad agreement on it.

As usual with policy stuff I'll wait a bit for others to have a chance
to chime in, but I think the wording on this one is at least easier to
reason about than some of the others.
---
 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 8087718556da..08cb92324eaf 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 make incompatible changes in the future.  For
+specifications from the RISC-V foundation this means "Frozen" or
+"Ratified", for the UEFI 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.34.1


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

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

[Conor Dooley]

On Tue, Sep 20, 2022 at 07:01:37AM -0700, Palmer Dabbelt wrote:
> I just stumbled on this when modifying the docs.
> 
> 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

s/implementor/implementer no? Or is this an American spelling?

> -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.34.1
> 
> 
> _______________________________________________
> 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 2/3] Documentation: RISC-V: Allow patches for non-standard behavior

[Conor Dooley]

On Tue, Sep 20, 2022 at 07:01:39AM -0700, Palmer Dabbelt wrote:
> The patch acceptance policy forbids accepting support for non-standard
> behavior.  This policy was written in order to both steer implementors
> towards the standards and to avoid

Commit message is cut off here.

> So let's just start taking code for vendor-defined extensions.

:)

> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
> This was discussed at Plumbers, but as with any policy change it's
> important to make sure everyone has time to chime in.  I intend on
> letting this sit on the lists for a bit to make sure everyone has a
> chance to comment, but in practice we're already regularly violating
> these policies so I'm going to just keep going with the status-quo in
> the meantime.
> 
> I'm also still not quite sure how to write down the hardware
> requirement: the intent is to make this more or less in line with other
> kernel policies, with the added wrinkle that RISC-V is a bit more
> distributed than other systems and thus has more core functionality that
> is vendor-defined.  Hence the need to allow some code to go in earlier
> than a requirement for publicly-available hardware would allow.
> ---
>  Documentation/riscv/patch-acceptance.rst | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
> index 5da6f9b273d6..8087718556da 100644
> --- a/Documentation/riscv/patch-acceptance.rst
> +++ b/Documentation/riscv/patch-acceptance.rst
> @@ -30,6 +30,10 @@ 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, or
> +for extensions that 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.)

As you know, I was there so I don't disagree with the sentiment of the
changes & as an employee of a vendor who wants to use a non-standard
extension I welcome the change.

Only comment I have is that the sentence has gotta kinda long. How about
a rephrasing/reworking to something like:
---8<---
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
either: 

- have been officially frozen or ratified by the RISC-V Foundation
- have been implemented in hardare that is publically available or has
  a timeline for availability that has been made public

Hardware that does not meet its published timelines may have support
removed. Implementers, may, of course, maintai their own Linux kernel
trees containing code for any custom extensions that they wish.
---8<---
I think breaking it up like that highlights the two distinct cases, but
maybe that's just me. The o spelling of implementer is in here too.
Again, am I missing some American English thing there?

I think the bit about the hardware is fair too. Gets the point across
and if someone's timelines slip all they have to do is publish the new
timelines...

Since my only comments were stylistic (modulo the potentially existing
spelling mistake) this looks good to me on an idealogical/policy level:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.



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

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

[Conor Dooley]

On Tue, Sep 20, 2022 at 07:01:41AM -0700, Palmer Dabbelt wrote:
> 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.
> 
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
> This also came up during the Plumbers BoF.  The other discussed options
> were to wait for an ACPI/UEFI specification to be published or to just
> not wait at all, but this middle ground matches how we handle the RISC-V
> specifications and it seems like there was broad agreement on it.
> 
> As usual with policy stuff I'll wait a bit for others to have a chance
> to chime in, but I think the wording on this one is at least easier to
> reason about than some of the others.
> ---
>  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 8087718556da..08cb92324eaf 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

> +unlikely to make incompatible changes in the future.  For

Nit, but the wording here is awkward since it sounds like the module or
extension is the "actor". How about:
s/make incompatible changes/be incompatibly changed/

> +specifications from the RISC-V foundation this means "Frozen" or
> +"Ratified", for the UEFI 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.)

Could we just drop the brackets from this sentence?

Either way, policy wise/idealogically this again looks good to me, so
with or without the wording changed:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

>  Additionally, the RISC-V specification allows implementors to create
>  their own custom extensions.  These custom extensions aren't required

Thanks,
Conor.


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

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

[Atish Patra]

On Tue, Sep 20, 2022 at 7:31 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> 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.
>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
> This also came up during the Plumbers BoF.  The other discussed options
> were to wait for an ACPI/UEFI specification to be published or to just
> not wait at all, but this middle ground matches how we handle the RISC-V
> specifications and it seems like there was broad agreement on it.
>
> As usual with policy stuff I'll wait a bit for others to have a chance
> to chime in, but I think the wording on this one is at least easier to
> reason about than some of the others.
> ---
>  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 8087718556da..08cb92324eaf 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 make incompatible changes in the future.  For
> +specifications from the RISC-V foundation this means "Frozen" or
> +"Ratified", for the UEFI specifications this means a published ECR.

It would be good to explicitly mention "UEFI forum specifications"
or
UEFI/ACPI specifications.

> +(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.34.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Other than that, LGTM

Reviewed-by: Atish Patra <atishp@rivosinc.com>

-- 
Regards,
Atish

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

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

[Palmer Dabbelt]

On Tue, 20 Sep 2022 09:56:59 PDT (-0700), Conor Dooley wrote:
> On Tue, Sep 20, 2022 at 07:01:37AM -0700, Palmer Dabbelt wrote:
>> I just stumbled on this when modifying the docs.
>>
>> 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
>
> s/implementor/implementer no? Or is this an American spelling?

I actually have no idea.  The "or" spelling seemed odd to me, but it was 
spell checking correctly.  The internet seems to be split on whether or 
not it's actually a word, which probably means it's uncommon enough it's 
worth moving over.  I'll just tack it on as a patch as there's enough 
feedback to have a v2.

>
>> -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.34.1
>>
>>
>> _______________________________________________
>> 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 2/3] Documentation: RISC-V: Allow patches for non-standard behavior

[Palmer Dabbelt]

On Tue, 20 Sep 2022 10:19:29 PDT (-0700), Conor Dooley wrote:
> On Tue, Sep 20, 2022 at 07:01:39AM -0700, Palmer Dabbelt wrote:
>> The patch acceptance policy forbids accepting support for non-standard
>> behavior.  This policy was written in order to both steer implementors
>> towards the standards and to avoid
>
> Commit message is cut off here.

Oops, I'll fix it in the v2.

>> So let's just start taking code for vendor-defined extensions.
>
> :)
>
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>> ---
>> This was discussed at Plumbers, but as with any policy change it's
>> important to make sure everyone has time to chime in.  I intend on
>> letting this sit on the lists for a bit to make sure everyone has a
>> chance to comment, but in practice we're already regularly violating
>> these policies so I'm going to just keep going with the status-quo in
>> the meantime.
>>
>> I'm also still not quite sure how to write down the hardware
>> requirement: the intent is to make this more or less in line with other
>> kernel policies, with the added wrinkle that RISC-V is a bit more
>> distributed than other systems and thus has more core functionality that
>> is vendor-defined.  Hence the need to allow some code to go in earlier
>> than a requirement for publicly-available hardware would allow.
>> ---
>>  Documentation/riscv/patch-acceptance.rst | 10 +++++++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/riscv/patch-acceptance.rst b/Documentation/riscv/patch-acceptance.rst
>> index 5da6f9b273d6..8087718556da 100644
>> --- a/Documentation/riscv/patch-acceptance.rst
>> +++ b/Documentation/riscv/patch-acceptance.rst
>> @@ -30,6 +30,10 @@ 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, or
>> +for extensions that 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.)
>
> As you know, I was there so I don't disagree with the sentiment of the
> changes & as an employee of a vendor who wants to use a non-standard
> extension I welcome the change.
>
> Only comment I have is that the sentence has gotta kinda long. How about
> a rephrasing/reworking to something like:
> ---8<---
> 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
> either:
>
> - have been officially frozen or ratified by the RISC-V Foundation
> - have been implemented in hardare that is publically available or has
>   a timeline for availability that has been made public
>
> Hardware that does not meet its published timelines may have support
> removed. Implementers, may, of course, maintai their own Linux kernel
> trees containing code for any custom extensions that they wish.
> ---8<---
> I think breaking it up like that highlights the two distinct cases, but
> maybe that's just me.

Seems reasonable, I'm just going to go with roughly that for the v2.

> The o spelling of implementer is in here too.
> Again, am I missing some American English thing there?
>
> I think the bit about the hardware is fair too. Gets the point across
> and if someone's timelines slip all they have to do is publish the new
> timelines...

Ya, that's the idea: we sort of just need to know this stuff is actually 
alive, if there's hardware that's easy but if not then at least getting 
an Ack that there's still some plans for it to show up helps.

> Since my only comments were stylistic (modulo the potentially existing
> spelling mistake) this looks good to me on an idealogical/policy level:
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

OK.

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

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

[Palmer Dabbelt]

On Tue, 20 Sep 2022 10:49:08 PDT (-0700), Conor Dooley wrote:
> On Tue, Sep 20, 2022 at 07:01:41AM -0700, Palmer Dabbelt wrote:
>> 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.
>>
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>> ---
>> This also came up during the Plumbers BoF.  The other discussed options
>> were to wait for an ACPI/UEFI specification to be published or to just
>> not wait at all, but this middle ground matches how we handle the RISC-V
>> specifications and it seems like there was broad agreement on it.
>>
>> As usual with policy stuff I'll wait a bit for others to have a chance
>> to chime in, but I think the wording on this one is at least easier to
>> reason about than some of the others.
>> ---
>>  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 8087718556da..08cb92324eaf 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
>
>> +unlikely to make incompatible changes in the future.  For
>
> Nit, but the wording here is awkward since it sounds like the module or
> extension is the "actor". How about:
> s/make incompatible changes/be incompatibly changed/

Makes sense, it's in the v2.

>> +specifications from the RISC-V foundation this means "Frozen" or
>> +"Ratified", for the UEFI 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.)
>
> Could we just drop the brackets from this sentence?

IMO we should keep it, there was some confusion about how kernel trees 
work when we were at Plumbers.

>
> Either way, policy wise/idealogically this again looks good to me, so
> with or without the wording changed:
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
>>  Additionally, the RISC-V specification allows implementors to create
>>  their own custom extensions.  These custom extensions aren't required
>
> Thanks,
> Conor.

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

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

[Palmer Dabbelt]

On Mon, 26 Sep 2022 10:34:07 PDT (-0700), atishp@atishpatra.org wrote:
> On Tue, Sep 20, 2022 at 7:31 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>>
>> 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.
>>
>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>> ---
>> This also came up during the Plumbers BoF.  The other discussed options
>> were to wait for an ACPI/UEFI specification to be published or to just
>> not wait at all, but this middle ground matches how we handle the RISC-V
>> specifications and it seems like there was broad agreement on it.
>>
>> As usual with policy stuff I'll wait a bit for others to have a chance
>> to chime in, but I think the wording on this one is at least easier to
>> reason about than some of the others.
>> ---
>>  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 8087718556da..08cb92324eaf 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 make incompatible changes in the future.  For
>> +specifications from the RISC-V foundation this means "Frozen" or
>> +"Ratified", for the UEFI specifications this means a published ECR.
>
> It would be good to explicitly mention "UEFI forum specifications"
> or
> UEFI/ACPI specifications.

Ya, "UEFI" is definately wrong.  I went with "UEFI forum 
specifications", I think that's likely the most accurate.

>
>> +(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.34.1
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> Other than that, LGTM
>
> Reviewed-by: Atish Patra <atishp@rivosinc.com>

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