All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: Atish Patra <atishp@atishpatra.org>, Palmer Dabbelt <palmer@dabbelt.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Anup Patel <Anup.Patel@wdc.com>, Anup Patel <anup@brainfault.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Atish Patra <Atish.Patra@wdc.com>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>,
	Philipp Tomsich <ptomsich@ventanamicro.com>,
	Greg Favor <gfavor@ventanamicro.com>,
	Kumar Sankaran <ksankaran@ventanamicro.com>,
	Mark Himelstein <markhimelstein@riscv.org>
Subject: Re: [PATCH v7 1/1] RISC-V: Use SBI SRST extension when available
Date: Tue, 11 Jan 2022 10:32:24 +0100	[thread overview]
Message-ID: <Yd1OqLCSI6h+A0Ry@aurel32.net> (raw)
In-Reply-To: <CAOnJCUKO6YzYsq4XqPHg8SwkbZ_GrE8iyUSmJGKOHkrdE0Bc+A@mail.gmail.com>

On 2021-11-12 17:49, Atish Patra wrote:
> On Tue, Nov 9, 2021 at 10:19 AM Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> wrote:
> >
> > On 7/29/21 08:10, Atish Patra wrote:
> > > On Wed, Jul 28, 2021 at 9:30 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > >>
> > >> On Sun, 11 Jul 2021 11:59:33 PDT (-0700), Palmer Dabbelt wrote:
> > >>> On Fri, 09 Jul 2021 22:01:02 PDT (-0700), Anup Patel wrote:
> > >>>>
> > >>>>
> > >>>> On 08/07/21, 9:22 AM, "Anup Patel" <anup@brainfault.org> wrote:
> > >>>>
> > >>>>      On Wed, Jul 7, 2021 at 1:57 AM Palmer Dabbelt <palmerdabbelt@google.com> wrote:
> > >>>>      >
> > >>>>      > On Mon, 21 Jun 2021 21:46:46 PDT (-0700), anup@brainfault.org wrote:
> > >>>>      > > Hi Palmer,
> > >>>>      > >
> > >>>>      > > On Wed, Jun 9, 2021 at 5:43 PM Anup Patel <anup.patel@wdc.com> wrote:
> > >>>>      > >>
> > >>>>      > >> The SBI SRST extension provides a standard way to poweroff and
> > >>>>      > >> reboot the system irrespective to whether Linux RISC-V S-mode
> > >>>>      > >> is running natively (HS-mode) or inside Guest/VM (VS-mode).
> > >>>>      > >>
> > >>>>      > >> The SBI SRST extension is available in the SBI v0.3 specification.
> > >>>>      > >> (Refer, https://github.com/riscv/riscv-sbi-doc/releases/tag/v0.3.0-rc1)
> > >>>>      > >
> > >>>>      > > Can you please consider this patch for Linux-5.14-rc1 ?
> > >>>>      > >
> > >>>>      > > The SBI v0.3 spec is already frozen and this patch has been
> > >>>>      > > floating on LKML for quite a few months now.
> > >>>>      >
> > >>>>      > I didn't realize that SBI-0.3 had been frozed.  That link is to a RC,
> > >>>>      > the cooresponding v0.3.0 tag isn't in that repo.  Can you give me a
> > >>>>      > pointer to the frozen spec?
> > >>>>
> > >>>>      Here's the link to SBI v0.3.0 tag:
> > >>>>      https://github.com/riscv/riscv-sbi-doc/releases/tag/v0.3.0
> > >>>>
> > >>>>      We treat RC tags as frozen in SBI spec because no functional
> > >>>>      changes are done in SBI spec after it is tagged as RC. We only
> > >>>>      do typo fixes and clarifications on SBI spec RC release.
> > >>>
> > >>> Treating the 0.3.0-rc1 as frozen as soon as it's released is a
> > >>> terrifying policy: some of the fixes I sent in after I saw rc1 released
> > >>> change the actual meaning of the text, even if they were meant to change
> > >>> them to what I thought the intended meaning was supposed to be.  That
> > >>> means the actual text of 0.3.0-rc1 and 0.3.0 conflict with each other.
> > >>> Given that frozen comes with a guarntee of backwards compatibility, does
> > >>> that mean that the behavior allowed by 0.3.0-rc1 is compliant with the
> > >>> SBI, even if it was likely just allowed by a wording mistake?
> > >>>
> > >>> If you're going to freeze things at rc1 then you really need to be quite
> > >>> explicit about that, as generally the point of RCs is to elicit
> > >>> review/testing.  Looks like I was the only person to have provided any
> > >>> review, so I guess I was the only one who assumed "We don't expect any
> > >>> significant functional changes. We will wait for any further feedback
> > >>> and release the official v0.3 in a month or so." actually meant "this is
> > >>> frozen".
> > >>>
> > >>>> Can you take this patch for Linux-5.14 ??
> > >>>
> > >>> No, sorry, it's way too late for that.  Please be specific about when
> > >>> you freeze specifications in the future, so we can all stay on the same
> > >>> page.
> > >>
> > >> I went and talked to Krste, and he says that there's a whole process for
> > >> freezing extensions that this hasn't gone through.  They don't have
> > >> anything written down that I can point to, but can you guys please just
> > >> get on the same page about this?  It seems like every time I talk to
> > >
> > > Absolutely. The freezing extensions process is documented right now[1]
> > > but that is only meant
> > > for ISA/hardware/platform specifications. There is no process defined
> > > for a SBI specification which is purely
> > > a software specification because SBI specification release
> > > processes(v0.1 and v0.2) predate these documented processes.
> > > The SBI specification is owned by the Platform HSC which falls under
> > > the purview of software HC.
> > > You can see a detailed chart of the RVI organization at [2]. All the
> > > aspects of SBI specification are discussed
> > > in platform meetings[3] and frozen only after public review[4] and
> > > approval from the platform working group
> > > and the software HC. The official SBI specification(v0.3) will also be
> > > available along with all other RISC-V specifications
> > > once they figure out how to structure non-ISA specifications.
> > >
> > > I have cc'd Kumar (chair of the Platform HSC) and Philip (chair of the
> > > software HC) in case they want to add anything.
> > > I was not aware of the fact that Krste/Andrew are not aware of the
> > > progress of the SBI specification.
> > > I will raise this topic during the next meeting and make sure they are
> > > in the loop as well.
> > >
> > >> someone from the RISC-V foundation I get a conflicting description of
> > >> what's going on, and I'm entirely out of patience when it comes to
> > >> getting blamed for all the chaos over there.
> > >>
> > > I agree the RVI process has not been very clear in the past. However,
> > > that has changed a lot in recent times thanks to Mark and
> > > other working group chairs. I don't think anybody is blaming you for
> > > the delay in ratification of the RVI specifications.
> > > There is a clear path for all the specifications to be ratified e.g.
> > > the AIA and H extensions are planned to be frozen by the end of this
> > > year.
> > > Let me know if you want to see the timeline of each specification and
> > > I can point you to the correct sheet.
> > >
> > > [1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.ga0a994c3c8_0_6
> > > [2] https://docs.google.com/presentation/d/1eEVuu6lRZd9iiDnZQSZME7Q7svtTG3pGIKHPmZ79B8E/edit#slide=id.ga275a504df_0_9
> > > [3] https://github.com/riscv/riscv-platform-specs/wiki
> > > [4] https://lists.riscv.org/g/tech-unixplatformspec/message/1042
> >
> > https://github.com/riscv-non-isa/riscv-sbi-doc/releases/tag/v0.3.1-rc1
> > has:
> >
> > "This tag the release candidate of version 0.3.1 of the RISC-V SBI
> > specification. It doesn't have any significant changes other than typos.
> > A new release is created to adapt the ratification process for non-ISA
> > specifications defined by RVI recently."
> >
> > Has this patch to wait until release 0.3.1 of the SBI specification is
> > ratified?
> 
> Not ratified, Frozen (officially as per newly defined RVI process)
> 
> > What is the timeline?
> >

According to this mail, the "SBI specification is considered as frozen
now as per the RISC-V International policies":
http://lists.infradead.org/pipermail/opensbi/2022-January/002357.html

Therefore can we get this patch queued for 5.17-rc1?

Thanks,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

WARNING: multiple messages have this Message-ID (diff)
From: Aurelien Jarno <aurelien@aurel32.net>
To: Atish Patra <atishp@atishpatra.org>, Palmer Dabbelt <palmer@dabbelt.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Anup Patel <Anup.Patel@wdc.com>, Anup Patel <anup@brainfault.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Atish Patra <Atish.Patra@wdc.com>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>,
	Philipp Tomsich <ptomsich@ventanamicro.com>,
	Greg Favor <gfavor@ventanamicro.com>,
	Kumar Sankaran <ksankaran@ventanamicro.com>,
	Mark Himelstein <markhimelstein@riscv.org>
Subject: Re: [PATCH v7 1/1] RISC-V: Use SBI SRST extension when available
Date: Tue, 11 Jan 2022 10:32:24 +0100	[thread overview]
Message-ID: <Yd1OqLCSI6h+A0Ry@aurel32.net> (raw)
In-Reply-To: <CAOnJCUKO6YzYsq4XqPHg8SwkbZ_GrE8iyUSmJGKOHkrdE0Bc+A@mail.gmail.com>

On 2021-11-12 17:49, Atish Patra wrote:
> On Tue, Nov 9, 2021 at 10:19 AM Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> wrote:
> >
> > On 7/29/21 08:10, Atish Patra wrote:
> > > On Wed, Jul 28, 2021 at 9:30 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > >>
> > >> On Sun, 11 Jul 2021 11:59:33 PDT (-0700), Palmer Dabbelt wrote:
> > >>> On Fri, 09 Jul 2021 22:01:02 PDT (-0700), Anup Patel wrote:
> > >>>>
> > >>>>
> > >>>> On 08/07/21, 9:22 AM, "Anup Patel" <anup@brainfault.org> wrote:
> > >>>>
> > >>>>      On Wed, Jul 7, 2021 at 1:57 AM Palmer Dabbelt <palmerdabbelt@google.com> wrote:
> > >>>>      >
> > >>>>      > On Mon, 21 Jun 2021 21:46:46 PDT (-0700), anup@brainfault.org wrote:
> > >>>>      > > Hi Palmer,
> > >>>>      > >
> > >>>>      > > On Wed, Jun 9, 2021 at 5:43 PM Anup Patel <anup.patel@wdc.com> wrote:
> > >>>>      > >>
> > >>>>      > >> The SBI SRST extension provides a standard way to poweroff and
> > >>>>      > >> reboot the system irrespective to whether Linux RISC-V S-mode
> > >>>>      > >> is running natively (HS-mode) or inside Guest/VM (VS-mode).
> > >>>>      > >>
> > >>>>      > >> The SBI SRST extension is available in the SBI v0.3 specification.
> > >>>>      > >> (Refer, https://github.com/riscv/riscv-sbi-doc/releases/tag/v0.3.0-rc1)
> > >>>>      > >
> > >>>>      > > Can you please consider this patch for Linux-5.14-rc1 ?
> > >>>>      > >
> > >>>>      > > The SBI v0.3 spec is already frozen and this patch has been
> > >>>>      > > floating on LKML for quite a few months now.
> > >>>>      >
> > >>>>      > I didn't realize that SBI-0.3 had been frozed.  That link is to a RC,
> > >>>>      > the cooresponding v0.3.0 tag isn't in that repo.  Can you give me a
> > >>>>      > pointer to the frozen spec?
> > >>>>
> > >>>>      Here's the link to SBI v0.3.0 tag:
> > >>>>      https://github.com/riscv/riscv-sbi-doc/releases/tag/v0.3.0
> > >>>>
> > >>>>      We treat RC tags as frozen in SBI spec because no functional
> > >>>>      changes are done in SBI spec after it is tagged as RC. We only
> > >>>>      do typo fixes and clarifications on SBI spec RC release.
> > >>>
> > >>> Treating the 0.3.0-rc1 as frozen as soon as it's released is a
> > >>> terrifying policy: some of the fixes I sent in after I saw rc1 released
> > >>> change the actual meaning of the text, even if they were meant to change
> > >>> them to what I thought the intended meaning was supposed to be.  That
> > >>> means the actual text of 0.3.0-rc1 and 0.3.0 conflict with each other.
> > >>> Given that frozen comes with a guarntee of backwards compatibility, does
> > >>> that mean that the behavior allowed by 0.3.0-rc1 is compliant with the
> > >>> SBI, even if it was likely just allowed by a wording mistake?
> > >>>
> > >>> If you're going to freeze things at rc1 then you really need to be quite
> > >>> explicit about that, as generally the point of RCs is to elicit
> > >>> review/testing.  Looks like I was the only person to have provided any
> > >>> review, so I guess I was the only one who assumed "We don't expect any
> > >>> significant functional changes. We will wait for any further feedback
> > >>> and release the official v0.3 in a month or so." actually meant "this is
> > >>> frozen".
> > >>>
> > >>>> Can you take this patch for Linux-5.14 ??
> > >>>
> > >>> No, sorry, it's way too late for that.  Please be specific about when
> > >>> you freeze specifications in the future, so we can all stay on the same
> > >>> page.
> > >>
> > >> I went and talked to Krste, and he says that there's a whole process for
> > >> freezing extensions that this hasn't gone through.  They don't have
> > >> anything written down that I can point to, but can you guys please just
> > >> get on the same page about this?  It seems like every time I talk to
> > >
> > > Absolutely. The freezing extensions process is documented right now[1]
> > > but that is only meant
> > > for ISA/hardware/platform specifications. There is no process defined
> > > for a SBI specification which is purely
> > > a software specification because SBI specification release
> > > processes(v0.1 and v0.2) predate these documented processes.
> > > The SBI specification is owned by the Platform HSC which falls under
> > > the purview of software HC.
> > > You can see a detailed chart of the RVI organization at [2]. All the
> > > aspects of SBI specification are discussed
> > > in platform meetings[3] and frozen only after public review[4] and
> > > approval from the platform working group
> > > and the software HC. The official SBI specification(v0.3) will also be
> > > available along with all other RISC-V specifications
> > > once they figure out how to structure non-ISA specifications.
> > >
> > > I have cc'd Kumar (chair of the Platform HSC) and Philip (chair of the
> > > software HC) in case they want to add anything.
> > > I was not aware of the fact that Krste/Andrew are not aware of the
> > > progress of the SBI specification.
> > > I will raise this topic during the next meeting and make sure they are
> > > in the loop as well.
> > >
> > >> someone from the RISC-V foundation I get a conflicting description of
> > >> what's going on, and I'm entirely out of patience when it comes to
> > >> getting blamed for all the chaos over there.
> > >>
> > > I agree the RVI process has not been very clear in the past. However,
> > > that has changed a lot in recent times thanks to Mark and
> > > other working group chairs. I don't think anybody is blaming you for
> > > the delay in ratification of the RVI specifications.
> > > There is a clear path for all the specifications to be ratified e.g.
> > > the AIA and H extensions are planned to be frozen by the end of this
> > > year.
> > > Let me know if you want to see the timeline of each specification and
> > > I can point you to the correct sheet.
> > >
> > > [1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.ga0a994c3c8_0_6
> > > [2] https://docs.google.com/presentation/d/1eEVuu6lRZd9iiDnZQSZME7Q7svtTG3pGIKHPmZ79B8E/edit#slide=id.ga275a504df_0_9
> > > [3] https://github.com/riscv/riscv-platform-specs/wiki
> > > [4] https://lists.riscv.org/g/tech-unixplatformspec/message/1042
> >
> > https://github.com/riscv-non-isa/riscv-sbi-doc/releases/tag/v0.3.1-rc1
> > has:
> >
> > "This tag the release candidate of version 0.3.1 of the RISC-V SBI
> > specification. It doesn't have any significant changes other than typos.
> > A new release is created to adapt the ratification process for non-ISA
> > specifications defined by RVI recently."
> >
> > Has this patch to wait until release 0.3.1 of the SBI specification is
> > ratified?
> 
> Not ratified, Frozen (officially as per newly defined RVI process)
> 
> > What is the timeline?
> >

According to this mail, the "SBI specification is considered as frozen
now as per the RISC-V International policies":
http://lists.infradead.org/pipermail/opensbi/2022-January/002357.html

Therefore can we get this patch queued for 5.17-rc1?

Thanks,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

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

  reply	other threads:[~2022-01-11  9:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 12:13 [PATCH v7 0/1] SBI SRST extension support Anup Patel
2021-06-09 12:13 ` Anup Patel
2021-06-09 12:13 ` [PATCH v7 1/1] RISC-V: Use SBI SRST extension when available Anup Patel
2021-06-09 12:13   ` Anup Patel
2021-06-22  4:46   ` Anup Patel
2021-06-22  4:46     ` Anup Patel
2021-07-06 20:27     ` Palmer Dabbelt
2021-07-06 20:27       ` Palmer Dabbelt
2021-07-07 15:49       ` Anup Patel
2021-07-07 15:49         ` Anup Patel
2021-07-10  5:01         ` Anup Patel
2021-07-10  5:01           ` Anup Patel
2021-07-11 18:59           ` Palmer Dabbelt
2021-07-11 18:59             ` Palmer Dabbelt
2021-07-29  4:30             ` Palmer Dabbelt
2021-07-29  4:30               ` Palmer Dabbelt
2021-07-29  4:44               ` Anup Patel
2021-07-29  4:44                 ` Anup Patel
2021-07-29  5:18               ` Anup Patel
2021-07-29  5:18                 ` Anup Patel
2021-07-29  6:10               ` Atish Patra
2021-07-29  6:10                 ` Atish Patra
2021-11-09 15:19                 ` Heinrich Schuchardt
2021-11-09 15:19                   ` Heinrich Schuchardt
2021-11-12 22:49                   ` Atish Patra
2021-11-12 22:49                     ` Atish Patra
2022-01-11  9:32                     ` Aurelien Jarno [this message]
2022-01-11  9:32                       ` Aurelien Jarno
2022-01-11 18:40                       ` Palmer Dabbelt
2022-01-11 18:40                         ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yd1OqLCSI6h+A0Ry@aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=Alistair.Francis@wdc.com \
    --cc=Anup.Patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=atishp@atishpatra.org \
    --cc=gfavor@ventanamicro.com \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=ksankaran@ventanamicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=markhimelstein@riscv.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=ptomsich@ventanamicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.