From: Aurelien Jarno <aurelien@aurel32.net>
To: Samuel Holland <samuel.holland@sifive.com>
Cc: Troy Mitchell <troy.mitchell@linux.dev>,
Vivian Wang <wangruikang@iscas.ac.cn>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] riscv: disable local interrupts and stop other CPUs before restart
Date: Thu, 23 Apr 2026 22:49:20 +0200 [thread overview]
Message-ID: <aeqF0EiP4b2Ycj2G@aurel32.net> (raw)
In-Reply-To: <c1f466f8-4e76-43a2-a7a2-126415fd1f56@sifive.com>
Hi,
On 2026-03-16 08:19, Samuel Holland wrote:
> Hi Troy,
>
> On 2026-03-16 2:23 AM, Troy Mitchell wrote:
> >> I think the reason we ended up with the "unsafe" implementations of the
> >> reboot/shutdown functions is that on the backend it is usually SBI SRST
> >> calls, which can protect itself from other CPUs and interrupts. Since on
> >> K1 we're going to be poking I2C directly, we run into the problem
> >> described above. So all of these should disable interrupts and stop
> >> other CPUs before calling the handlers, and can't assume the handlers
> >> are all SBI SRST.
> > Yes, we cannot assume that all platforms rely on this.
>
> Why isn't K1 using the SBI SRST extension? Resetting the platform from S-mode
> directly causes problems if you ever want to run another supervisor domain (for
> example a TEE or EFI runtime services), which may need to clean up before a
> system reset.
>
> As you mention, other platforms use the standard SBI SRST interface, event if
> they need to poke a PMIC to perform a system reset. Is there something
> preventing K1 from following this path?
I went this path and submitted a patchset to OpenSBI mailing list doing
that:
https://lore.kernel.org/opensbi/20260419150857.2705843-1-aurelien@aurel32.net/T/#t
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-04-23 20:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 2:51 [PATCH RFC] riscv: disable local interrupts and stop other CPUs before restart Troy Mitchell
2026-03-11 6:47 ` Aurelien Jarno
2026-03-11 9:49 ` Troy Mitchell
2026-03-11 9:54 ` Troy Mitchell
2026-03-12 3:05 ` Vivian Wang
2026-03-16 7:23 ` Troy Mitchell
2026-03-16 13:19 ` Samuel Holland
2026-03-17 2:45 ` Troy Mitchell
2026-03-17 4:07 ` Samuel Holland
2026-03-17 7:42 ` Troy Mitchell
2026-04-23 20:49 ` Aurelien Jarno [this message]
2026-04-25 17:42 ` Anand Moon
2026-04-26 12:20 ` Aurelien Jarno
2026-04-27 3:47 ` Anand Moon
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=aeqF0EiP4b2Ycj2G@aurel32.net \
--to=aurelien@aurel32.net \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=samuel.holland@sifive.com \
--cc=troy.mitchell@linux.dev \
--cc=wangruikang@iscas.ac.cn \
/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