mirror of https://lore.kernel.org/lkml/
 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

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

Thread overview: 15+ 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 ` [PATCH v7 1/1] RISC-V: Use SBI SRST extension when available Anup Patel
2021-06-22  4:46   ` Anup Patel
2021-07-06 20:27     ` Palmer Dabbelt
2021-07-07 15:49       ` Anup Patel
2021-07-10  5:01         ` Anup Patel
2021-07-11 18:59           ` Palmer Dabbelt
2021-07-29  4:30             ` Palmer Dabbelt
2021-07-29  4:44               ` Anup Patel
2021-07-29  5:18               ` Anup Patel
2021-07-29  6:10               ` Atish Patra
2021-11-09 15:19                 ` Heinrich Schuchardt
2021-11-12 22:49                   ` Atish Patra
2022-01-11  9:32                     ` Aurelien Jarno [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome