Hi Varadarajan, On Mon, 16 Feb 2026 at 21:24, Varadarajan Narayanan <[email protected]> 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 > > <[email protected]> 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
