[PATCH v6 2/5] drivers: sysreset: Add sysreset op that can take arguments

[Simon Glass]

Hi Varadarajan,

On Mon, 16 Feb 2026 at 21:24, Varadarajan Narayanan
<varadarajan.narayanan at oss.qualcomm.com> wrote:
>
> On Mon, Feb 16, 2026 at 10:19:48AM -0700, Simon Glass wrote:
> > Hi Varadarajan,
> >
> > On Sun, 15 Feb 2026 at 22:31, Varadarajan Narayanan
> > <varadarajan.narayanan at oss.qualcomm.com> wrote:
> > >
> > > On Fri, Feb 13, 2026 at 01:20:10PM -0700, Simon Glass wrote:
> > > [ . . . ]
> > >
> > > > > > > > I haven't been following this, but what sort of args are you planning to pass?
> > > > > > >
> > > > > > > As of now, an argument to indicate reboot to emergency download mode.
> > > > > >
> > > > > > So how about adding a struct in sysreset.h where you can include a
> > > > > > flag word and create a single flag for your case? We should be able to
> > > > > > handle reset without the cmdline being enabled.
> > > > > >
> > > > > > There are other cases where this would be useful, e.g. an EFI app
> > > > > > rebooting into setup boot.
> > > > >
> > > > > Previously, i.e. v5 [1] didn't have SYSRESET_CMD_RESET_ARGS config
> > > > > option. This was added to avoid bloat code size for platforms that will
> > > > > not need this. Please see [2]
> > > >
> > > > Sure, but you are adding a new method, so you could make it take a new
> > > > struct instead of the string list, still behind your Kconfig option.
> > >
> > > Sure.
> > >
> > > You want 'request_arg' function pointer to take a structure instead of
> > > 'char * const argv[]'. Is this understanding correct?
> > >
> > > If yes, this string list is what was given in the command line. And is
> > > passed to the implementation specific handler.
> > >
> > >         Command line -> do_reset -> sysreset_walk_arg -> *request_arg
> > >
> > > The implementation specific handler can interpret the argv[] as
> > > applicable to itself. Not sure how to convert/parse this to a struct
> > > that can be used by EFI app. Am I missing something. Please advice.
> >
> > Really I'm just trying to have it defined (in the uclass header) what
> > the behaviour actually is. An arbitrary string list seems too
> > open-ended, as well as being less efficient.
> >
> > So I am thinking you can add a struct, define and document the fields
> > in it and then other people can use the same approach when they hit
> > this problem. For example, with the existing request() method, we
> > created an 'enum sysreset_t' to specify the reset type, rather than
> > using a string arglist.
>
> As I understand, sysreset_t has a bunch of reset modes that is
> applicable to majority of the SoCs. However, this string approach is
> to accomodate situations where we don't know what the possibilities are.

Can you explain the situation you have here? What specific type of
reset are you wanting to do?

>
> > String arglist is good for the cmdline but not for programmative code.
>
> I'm not very familiar with EFI and EFI apps. Can't an EFI app use the
> efi_reset_system_boottime() API with reset type as
> EFI_RESET_PLATFORM_SPECIFIC? Presently, efi_reset_system_boottime()
> invokes do_reset() with argc and argv as 0 and NULL respectively.
>
> Instead, 'void *reset_data' can be cast to a struct that has int argc
> and char *argv[] in efi_reset_system_boottime() and pass those values to
> do_reset instead of 0 and NULL. Wouldn't this be usable for
> programmative code?

Yes EFI can do that. But here we are talking about a driver model API
for sysreset. What operation(s) do you want your driver to do, for
your soc, in addition to what operations are already there?

Regards,
Simon