* [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance @ 2022-09-20 14:01 Palmer Dabbelt 2022-09-20 14:01 ` [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior Palmer Dabbelt ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Palmer Dabbelt @ 2022-09-20 14:01 UTC (permalink / raw) To: linux-riscv; +Cc: 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior 2022-09-20 14:01 [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Palmer Dabbelt @ 2022-09-20 14:01 ` Palmer Dabbelt 2022-09-20 17:19 ` Conor Dooley 2022-09-20 14:01 ` [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards Palmer Dabbelt 2022-09-20 16:56 ` [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Conor Dooley 2 siblings, 1 reply; 11+ messages in thread From: Palmer Dabbelt @ 2022-09-20 14:01 UTC (permalink / raw) To: linux-riscv; +Cc: 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior 2022-09-20 14:01 ` [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior Palmer Dabbelt @ 2022-09-20 17:19 ` Conor Dooley 2022-10-13 4:56 ` Palmer Dabbelt 0 siblings, 1 reply; 11+ messages in thread From: Conor Dooley @ 2022-09-20 17:19 UTC (permalink / raw) To: Palmer Dabbelt; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior 2022-09-20 17:19 ` Conor Dooley @ 2022-10-13 4:56 ` Palmer Dabbelt 0 siblings, 0 replies; 11+ messages in thread From: Palmer Dabbelt @ 2022-10-13 4:56 UTC (permalink / raw) To: Conor Dooley; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards 2022-09-20 14:01 [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Palmer Dabbelt 2022-09-20 14:01 ` [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior Palmer Dabbelt @ 2022-09-20 14:01 ` Palmer Dabbelt 2022-09-20 17:49 ` Conor Dooley 2022-09-26 17:34 ` Atish Patra 2022-09-20 16:56 ` [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Conor Dooley 2 siblings, 2 replies; 11+ messages in thread From: Palmer Dabbelt @ 2022-09-20 14:01 UTC (permalink / raw) To: linux-riscv; +Cc: 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards 2022-09-20 14:01 ` [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards Palmer Dabbelt @ 2022-09-20 17:49 ` Conor Dooley 2022-10-13 4:56 ` Palmer Dabbelt 2022-09-26 17:34 ` Atish Patra 1 sibling, 1 reply; 11+ messages in thread From: Conor Dooley @ 2022-09-20 17:49 UTC (permalink / raw) To: Palmer Dabbelt; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards 2022-09-20 17:49 ` Conor Dooley @ 2022-10-13 4:56 ` Palmer Dabbelt 0 siblings, 0 replies; 11+ messages in thread From: Palmer Dabbelt @ 2022-10-13 4:56 UTC (permalink / raw) To: Conor Dooley; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards 2022-09-20 14:01 ` [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards Palmer Dabbelt 2022-09-20 17:49 ` Conor Dooley @ 2022-09-26 17:34 ` Atish Patra 2022-10-13 4:56 ` Palmer Dabbelt 1 sibling, 1 reply; 11+ messages in thread From: Atish Patra @ 2022-09-26 17:34 UTC (permalink / raw) To: Palmer Dabbelt; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards 2022-09-26 17:34 ` Atish Patra @ 2022-10-13 4:56 ` Palmer Dabbelt 0 siblings, 0 replies; 11+ messages in thread From: Palmer Dabbelt @ 2022-10-13 4:56 UTC (permalink / raw) To: atishp; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance 2022-09-20 14:01 [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Palmer Dabbelt 2022-09-20 14:01 ` [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior Palmer Dabbelt 2022-09-20 14:01 ` [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards Palmer Dabbelt @ 2022-09-20 16:56 ` Conor Dooley 2022-10-13 4:56 ` Palmer Dabbelt 2 siblings, 1 reply; 11+ messages in thread From: Conor Dooley @ 2022-09-20 16:56 UTC (permalink / raw) To: Palmer Dabbelt; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance 2022-09-20 16:56 ` [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Conor Dooley @ 2022-10-13 4:56 ` Palmer Dabbelt 0 siblings, 0 replies; 11+ messages in thread From: Palmer Dabbelt @ 2022-10-13 4:56 UTC (permalink / raw) To: Conor Dooley; +Cc: linux-riscv 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-10-13 4:56 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-20 14:01 [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Palmer Dabbelt 2022-09-20 14:01 ` [PATCH 2/3] Documentation: RISC-V: Allow patches for non-standard behavior Palmer Dabbelt 2022-09-20 17:19 ` Conor Dooley 2022-10-13 4:56 ` Palmer Dabbelt 2022-09-20 14:01 ` [PATCH 3/3] Documentation: RISC-V: Mention the UEFI Standards Palmer Dabbelt 2022-09-20 17:49 ` Conor Dooley 2022-10-13 4:56 ` Palmer Dabbelt 2022-09-26 17:34 ` Atish Patra 2022-10-13 4:56 ` Palmer Dabbelt 2022-09-20 16:56 ` [PATCH 1/3] Documentation: RISC-V: Fix a typo in patch-acceptance Conor Dooley 2022-10-13 4:56 ` Palmer Dabbelt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.