Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver

[Shivendra Pratap]

On 01-04-2026 20:26, Arnd Bergmann wrote:
> On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
> > On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
> > > > > +#include <linux/err.h>
> > > > > +#include <linux/of.h>
> > > > > +#include <linux/psci.h>
> > > > > +#include <linux/reboot.h>
> > > > > +#include <linux/reboot-mode.h>
> > > > > +#include <linux/types.h>
> > > > > +
> > > > > +/*
> > > > > + * Predefined reboot-modes are defined as per the values
> > > > > + * of enum reboot_mode defined in the kernel: reboot.c.
> > > > > + */
> > > > > +static struct mode_info psci_resets[] = {
> > > > > +	{ .mode = "warm", .magic = REBOOT_WARM},
> > > > > +	{ .mode = "soft", .magic = REBOOT_SOFT},
> > > > > +	{ .mode = "cold", .magic = REBOOT_COLD},
> >
> > These strings match the command userspace issue right ? I think that we
> > should make them match the corresponding PSCI reset types, the list above
> > maps command to reboot_mode values and those can belong to any reboot
> > mode driver to be honest they don't make much sense in a PSCI reboot
> > mode driver only.
> >
> > It is a question for everyone here: would it make sense to make these
> > predefined resets a set of strings, eg:
> >
> > psci-system-reset
> > psci-system-reset2-arch-warm-reset
> >
> > and then vendor resets:
> >
> > psci-system-reset2-vendor-reset
> >
> > at least we know what a string maps to ?
> >
> > We can export a function from the PSCI driver to detect whether PSCI
> > SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
> > instance that we can call from this driver to detect its presence.
>
> Sorry I've been out of the loop for this series for a while, but
> can someone refresh me on why we got back to mixing in
> the 'enum reboot_mode' from legacy i386 and arm32 into the new
> interface?
>
> I don't mind having whichever strings are defined for PSCI present
> in the user interface, but this seems like a mistake to me.
> If at all possible, lets define your own magic constants that
> are not tied to "enum reboot_mode" or the legacy reboot= command
> line argument.

sure. will remove usage of "enum reboot_mode".

thanks,
Shivendra