[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aP906fAZZfFXp-2D@aurel32.net>
Date: Mon, 27 Oct 2025 14:34:33 +0100
From: Aurelien Jarno <aurelien@...el32.net>
To: Yixun Lan <dlan@...too.org>
Cc: Emil Renner Berthing <emil.renner.berthing@...onical.com>,
Andreas Schwab <schwab@...e.de>, Yao Zi <ziyao@...root.org>,
Troy Mitchell <troy.mitchell@...ux.spacemit.com>,
linux-kernel@...r.kernel.org, Lee Jones <lee@...nel.org>,
Sebastian Reichel <sre@...nel.org>, Paul Walmsley <pjw@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v4 1/2] driver: reset: spacemit-p1: add driver for
poweroff/reboot
On 2025-10-27 18:31, Yixun Lan wrote:
> Hi
>
> On 03:17 Mon 27 Oct , Emil Renner Berthing wrote:
> > Quoting Yao Zi (2025-10-27 10:24:30)
> > > On Mon, Oct 27, 2025 at 10:03:44AM +0100, Andreas Schwab wrote:
> > > > On Okt 27 2025, Yao Zi wrote:
> > > > > On Mon, Oct 27, 2025 at 11:20:33AM +0800, Troy Mitchell wrote:
> > > > >> On Sun, Oct 26, 2025 at 11:41:14PM +0100, Aurelien Jarno wrote:
> > > > >> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > > > >> > index 8248895ca9038..61c16f3d5abc7 100644
> > > > >> > --- a/drivers/power/reset/Kconfig
> > > > >> > +++ b/drivers/power/reset/Kconfig
> > > > >> > @@ -283,6 +283,15 @@ config POWER_RESET_KEYSTONE
> > > > >> > help
> > > > >> > Reboot support for the KEYSTONE SoCs.
> > > > >> >
> > > > >> > +config POWER_RESET_SPACEMIT_P1
> > > > >> > + tristate "SpacemiT P1 poweroff and reset driver"
> > > > >> > + depends on ARCH_SPACEMIT || COMPILE_TEST
> > > > >> > + depends on MFD_SPACEMIT_P1
> > > > >> > + default m
> > > > >> default m if ARCH_SPACEMIT? Or default ARCH_SPACEMIT?
> > > > >> I believe that reboot and shutdown are actually essential functionalities,
> > > > >> so it might make more sense: default ARCH_SPACEMIT?
> > > > >
> > > > > I don't think there's anything preventing it to be built as module by
> > > > > default: even though it's "essential", it's unnecessary during kernel
> > > > > and userspace startup, thus I see no reason to build it in the image.
> > > >
> > > > Wouldn't it be needed in a reboot-on-panic situation?
> > >
> > > Oops, yeah, I missed this stuff. Seems systemd automatic boot assessment
> > > could switch to another boot option if one fails to boot. And if it's
> > > caused by a (very early) kernel panic, then reboot support does play a
> > > part here.
> >
> > But if systemd is running then you've at least got as far as the initramfs,
> > and have the module available. So I don't see the problem.
> >
> In rare case, if got kernel panic before load this module, then we
> should really fix it instead.. Besides, there is no restriction to prevent
> user to make this driver as built-in, right?
>
> So I think this isn't really a big problem either
A possible compromise here might be to use "default MFD_SPACEMIT_P1".
This would defer the decision to another level, but I think it makes
sense to have all parts of the MFD either built-in or as modules.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@...el32.net http://aurel32.net
Powered by blists - more mailing lists