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

[Tom Rini]

On Tue, Feb 17, 2026 at 09:56:52AM +0530, Varadarajan Narayanan wrote:
> On Mon, Feb 16, 2026 at 09:29:06AM -0600, Tom Rini wrote:
> > On Mon, Feb 16, 2026 at 11:01:02AM +0530, Varadarajan Narayanan 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.
> >
> > Varada, do you think this suggestion is taking things in a useful
> > direction? It's unclear to me at this point if what Simon suggested is
> > going to provide something meaningfully more clear / useful or not.
> 
> At this point, for my case, it seems not needed. That is why trying to
> understand his perspective to get better clarity and arrive at a
> consensus.

OK, yes. I think we can set Simon's questions aside for now then as it
seems like he's trying to find a generic solution when we only have one
example, and that's not the right way. We need two or three "doesn't fit
the generic method" examples before we can see how to abstract things
correctly.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260217/e0621742/attachment.sig>