[PATCH v7 1/1] RISC-V: Use SBI SRST extension when available
Palmer Dabbelt
palmer at dabbelt.com
Tue Jan 11 10:40:40 PST 2022
On Tue, 11 Jan 2022 01:32:24 PST (-0800), aurelien at aurel32.net wrote:
> On 2021-11-12 17:49, Atish Patra wrote:
>> On Tue, Nov 9, 2021 at 10:19 AM Heinrich Schuchardt
>> <heinrich.schuchardt at canonical.com> wrote:
>> >
>> > On 7/29/21 08:10, Atish Patra wrote:
>> > > On Wed, Jul 28, 2021 at 9:30 PM Palmer Dabbelt <palmer at 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 at brainfault.org> wrote:
>> > >>>>
>> > >>>> On Wed, Jul 7, 2021 at 1:57 AM Palmer Dabbelt <palmerdabbelt at google.com> wrote:
>> > >>>> >
>> > >>>> > On Mon, 21 Jun 2021 21:46:46 PDT (-0700), anup at brainfault.org wrote:
>> > >>>> > > Hi Palmer,
>> > >>>> > >
>> > >>>> > > On Wed, Jun 9, 2021 at 5:43 PM Anup Patel <anup.patel at 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. Atish had actually pointed this out last night, but I wasn't at
the computer. This in on for-next.
More information about the linux-riscv
mailing list