[PATCH v1 0/4] reset: add board reset type

[PATCH v1 0/4] reset: add board reset type

[dmukhin]

This series introduces convenience functionality for prototype boards
where reset is not fully working - for example, where only warm reset is
functional, but cold reset must still be enabled for the production
variant.

Patch 1 allows per-board default reset override.
Patch 2 adds `reset -c` support to explicitly trigger cold reset.
Patch 3 adds reset type printout on the console.
Patch 4 introduces a small fixup for the x86 reset driver.

Denis Mukhin (4):
  reset: allow per-board reset type
  reset: add explicit cold reset support
  reset: print reset type on diagnostic console
  reset: x86: use cpu_hlt() in pch_sysreset_power_off()

 drivers/sysreset/sysreset-uclass.c | 32 ++++++++++++++++++++++++++----
 drivers/sysreset/sysreset_x86.c    |  6 ++++--
 include/sysreset.h                 |  7 +++++++
 3 files changed, 39 insertions(+), 6 deletions(-)

-- 
2.54.0

[PATCH v1 1/4] reset: Allow per-board reset type

[dmukhin]

From: Denis Mukhin <dmukhin@ford.com> 

Some prototype boards may not have (temporarily) all required reset
types supported (e.g. only warm reset supported).

Add `board_sysreset_default()` to obtain board-specific default reset
type to enable `reset` command on such boards.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 drivers/sysreset/sysreset-uclass.c | 7 ++++++-
 include/sysreset.h                 | 7 +++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index f25e09e9cd06..dc569a6b8ade 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -150,9 +150,14 @@ void reset_cpu(void)
 }
 
 #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET)
+__weak enum sysreset_t board_sysreset_default(void)
+{
+	return SYSRESET_COLD;
+}
+
 int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
-	enum sysreset_t reset_type = SYSRESET_COLD;
+	enum sysreset_t reset_type = board_sysreset_default();
 
 	if (argc > 2)
 		return CMD_RET_USAGE;
diff --git a/include/sysreset.h b/include/sysreset.h
index d1cc9ebc542a..a9e743c13e8b 100644
--- a/include/sysreset.h
+++ b/include/sysreset.h
@@ -161,4 +161,11 @@ void reset_cpu(void);
  */
 int sysreset_register_wdt(struct udevice *dev);
 
+/**
+ * board_sysreset_default() - Get board-specific reset type.
+ *
+ * @return:	Board-specific reset type.
+ */
+enum sysreset_t board_sysreset_default(void);
+
 #endif
-- 
2.54.0

Re: [PATCH v1 1/4] reset: Allow per-board reset type

[Simon Glass]

Hi Denis,

On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:
> reset: Allow per-board reset type
>
> Some prototype boards may not have (temporarily) all required reset
> types supported (e.g. only warm reset supported).
>
> Add board_sysreset_default() to obtain board-specific default reset
> type to enable reset command on such boards.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> drivers/sysreset/sysreset-uclass.c | 7 ++++++-
>  include/sysreset.h                 | 7 +++++++
>  2 files changed, 13 insertions(+), 1 deletion(-)

> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> @@ -150,9 +150,14 @@ void reset_cpu(void)
>  }
>
>  #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET)
> +__weak enum sysreset_t board_sysreset_default(void)
> +{
> +     return SYSRESET_COLD;
> +}
> +

I'm not convinced a weak board hook is right here. Since the value is
a compile-time constant per board, a Kconfig choice
(SYSRESET_CMD_DEFAULT_COLD / _WARM) would be cleaner: no per-board C,
visible from defconfig, and no new ABI for the sake of prototypes.
What do you think?

The cover letter says cold reset must still be enabled for the
production variant. If the board gets proper cold-reset support before
shipping, the override really only wants to live in the prototype's
board code - a Kconfig option makes that lifecycle obvious.

We could perhaps go in a different direction and use a sysinfo driver
to specify the default, but that seems like overkill.

Regards,
Simon

Re: [PATCH v1 1/4] reset: Allow per-board reset type

[dmukhin]

Hi Simon,

Thanks for reviews!

On Mon, May 25, 2026 at 09:28:30AM -0600, Simon Glass wrote:
> Hi Denis,
> 
> On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:
> > reset: Allow per-board reset type
> >
> > Some prototype boards may not have (temporarily) all required reset
> > types supported (e.g. only warm reset supported).
> >
> > Add board_sysreset_default() to obtain board-specific default reset
> > type to enable reset command on such boards.
> >
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> >
> > drivers/sysreset/sysreset-uclass.c | 7 ++++++-
> >  include/sysreset.h                 | 7 +++++++
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> > diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> > @@ -150,9 +150,14 @@ void reset_cpu(void)
> >  }
> >
> >  #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET)
> > +__weak enum sysreset_t board_sysreset_default(void)
> > +{
> > +     return SYSRESET_COLD;
> > +}
> > +
> 
> I'm not convinced a weak board hook is right here. Since the value is
> a compile-time constant per board, a Kconfig choice
> (SYSRESET_CMD_DEFAULT_COLD / _WARM) would be cleaner: no per-board C,
> visible from defconfig, and no new ABI for the sake of prototypes.
> What do you think?

TBH, I did weak symbol only to minimize the diff: this way the change
is isolated to sysreset-uclass.c.

I agree, Kconfig is a cleaner way, will fix that in v2.

> 
> The cover letter says cold reset must still be enabled for the
> production variant. If the board gets proper cold-reset support before
> shipping, the override really only wants to live in the prototype's
> board code - a Kconfig option makes that lifecycle obvious.
> 
> We could perhaps go in a different direction and use a sysinfo driver
> to specify the default, but that seems like overkill.
> 
> Regards,
> Simon

Thanks,
Denis

[PATCH v1 2/4] reset: Add explicit cold reset support

[dmukhin]

From: Denis Mukhin <dmukhin@ford.com> 

Add `reset -c` to allow explicit cold reset.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 drivers/sysreset/sysreset-uclass.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index dc569a6b8ade..d893c74e9121 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -162,8 +162,11 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 	if (argc > 2)
 		return CMD_RET_USAGE;
 
-	if (argc == 2 && argv[1][0] == '-' && argv[1][1] == 'w') {
-		reset_type = SYSRESET_WARM;
+	if (argc == 2 && argv[1][0] == '-') {
+		if (argv[1][1] == 'w')
+			reset_type = SYSRESET_WARM;
+		else if (argv[1][1] == 'c')
+			reset_type = SYSRESET_COLD;
 	}
 
 	printf("resetting ...\n");
-- 
2.54.0

Re: [PATCH v1 2/4] reset: Add explicit cold reset support

[Simon Glass]

Hi Denis,

On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:
> reset: Add explicit cold reset support
>
> Add reset -c to allow explicit cold reset.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> drivers/sysreset/sysreset-uclass.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> @@ -162,8 +162,11 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>       if (argc > 2)
>               return CMD_RET_USAGE;

>
> -     if (argc == 2 && argv[1][0] == '-' && argv[1][1] == 'w') {
> -             reset_type = SYSRESET_WARM;
> +     if (argc == 2 && argv[1][0] == '-') {
> +             if (argv[1][1] == 'w')
> +                     reset_type = SYSRESET_WARM;
> +             else if (argv[1][1] == 'c')
> +                     reset_type = SYSRESET_COLD;
>       }

Since you are now parsing more than one sub-option, please return
CMD_RET_USAGE for unknown flags rather than falling through to the
board default. A switch reads more clearly:

    switch (argv[1][1]) {
    case 'w':
        reset_type = SYSRESET_WARM;
        break;
    case 'c':
        reset_type = SYSRESET_COLD;
        break;
    default:
        return CMD_RET_USAGE;
    }

> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> @@ -162,8 +162,11 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> +     if (argc == 2 && argv[1][0] == '-') {
> +             if (argv[1][1] == 'w')
> +                     reset_type = SYSRESET_WARM;
> +             else if (argv[1][1] == 'c')
> +                     reset_type = SYSRESET_COLD;
>       }

The commit message is very terse. Please mention the motivation - with
patch 1 the board default may now be warm, so users need an explicit
way to ask for cold. As written it reads as a duplicate of existing
behaviour.

We should also update doc/usage/cmd/reset.rst

Not sure if we have any tests for the reset command yet, though.

Regards,
Simon

[PATCH v1 3/4] reset: Print reset type on diagnostic console

[dmukhin]

From: Denis Mukhin <dmukhin@ford.com> 

Add a diagnostic console trace indicating the reset type.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 drivers/sysreset/sysreset-uclass.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index d893c74e9121..8af370e0fa8b 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -22,6 +22,22 @@
 #include <linux/err.h>
 #include <asm/global_data.h>
 
+static const char *get_reset_type_str(enum sysreset_t reset_type)
+{
+	switch (reset_type) {
+	case SYSRESET_WARM:
+		return "warm";
+	case SYSRESET_COLD:
+		return "cold";
+	case SYSRESET_POWER:
+		return "PMIC";
+	case SYSRESET_POWER_OFF:
+		return "power off";
+	default:
+		return "unknown";
+	}
+}
+
 int sysreset_request(struct udevice *dev, enum sysreset_t type)
 {
 	struct sysreset_ops *ops = sysreset_get_ops(dev);
@@ -169,7 +185,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 			reset_type = SYSRESET_COLD;
 	}
 
-	printf("resetting ...\n");
+	printf("resetting (%s)...\n", get_reset_type_str(reset_type));
 	mdelay(100);
 
 #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
-- 
2.54.0

Re: [PATCH v1 3/4] reset: Print reset type on diagnostic console

[Simon Glass]

Hi Denis,

On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:
> reset: Print reset type on diagnostic console
>
> Add a diagnostic console trace indicating the reset type.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> drivers/sysreset/sysreset-uclass.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)

> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> @@ -22,6 +22,22 @@
> +static const char *get_reset_type_str(enum sysreset_t reset_type)
> +{
> +     switch (reset_type) {
> +     case SYSRESET_WARM:
> +             return 'warm';
> +     case SYSRESET_COLD:
> +             return 'cold';
> +     case SYSRESET_POWER:
> +             return 'PMIC';
> +     case SYSRESET_POWER_OFF:
> +             return "power off";
> +     default:
> +             return 'unknown';
> +     }
> +}

PMIC is an odd label for SYSRESET_POWER - the enum doc describes it as
"remove and restore power", so 'power' reads more naturally and lines
up with the enum name. What do you think?

Regards,
Simon

[PATCH v1 4/4] reset: x86: Use cpu_hlt() in pch_sysreset_power_off()

[dmukhin]

From: Denis Mukhin <dmukhin@ford.com> 

Use cpu_hlt() instead of open-coded "hlt".
Also, use cpu_hlt() in reset path (including EFI) too.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
 drivers/sysreset/sysreset_x86.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index c2f28c65280f..c4e34cdc78af 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -10,6 +10,7 @@
 #include <pch.h>
 #include <sysreset.h>
 #include <acpi/acpi_s3.h>
+#include <asm/cpu.h>
 #include <asm/io.h>
 #include <asm/processor.h>
 #include <asm/sysreset.h>
@@ -65,7 +66,7 @@ int pch_sysreset_power_off(struct udevice *dev)
 	outl(reg32, pm.base + pm.pm1_cnt_ofs);
 
 	for (;;)
-		asm("hlt");
+		cpu_hlt();
 }
 
 static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
@@ -120,7 +121,8 @@ void __efi_runtime EFIAPI efi_reset_system(
 
 	/* TODO EFI_RESET_SHUTDOWN */
 
-	while (1) { }
+	for (;;)
+		cpu_hlt();
 }
 #endif
 
-- 
2.54.0

Re: [PATCH v1 4/4] reset: x86: Use cpu_hlt() in pch_sysreset_power_off()

[Simon Glass]

Hi Denis,

On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:
> reset: x86: Use cpu_hlt() in pch_sysreset_power_off()
>
> Use cpu_hlt() instead of open-coded 'hlt'.
> Also, use cpu_hlt() in reset path (including EFI) too.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> drivers/sysreset/sysreset_x86.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> @@ -10,6 +10,7 @@
>  #include <pch.h>
>  #include <sysreset.h>
>  #include <acpi/acpi_s3.h>
> +#include <asm/cpu.h>
>  #include <asm/io.h>
>  #include <asm/processor.h>
>  #include <asm/sysreset.h>

cpu_hlt() is defined in <asm/processor.h>, so do you need this new include?

> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> @@ -65,7 +66,7 @@ int pch_sysreset_power_off(struct udevice *dev)
>       outl(reg32, pm.base + pm.pm1_cnt_ofs);
>
>       for (;;)
> -             asm('hlt');
> +             cpu_hlt();
>  }

The commit message says "use cpu_hlt() in reset path (including EFI)
too", but x86_sysreset_request() is untouched - only the EFI path.
Please reword, e.g. "also replace the open-coded busy loop in
efi_reset_system()".

Regards,
Simon

Re: [v1,0/4] reset: add board reset type

[Simon Glass]

Hi Denis,

On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:

> Patch 1 allows per-board default reset override.
> Patch 2 adds reset -c support to explicitly trigger cold reset.
> Patch 3 adds reset type printout on the console.
> Patch 4 introduces a small fixup for the x86 reset driver.

Since you are adding new behaviour, I would expect a sandbox test to
go with it. The sysreset sandbox driver should make this
straightforward - what do you think?

Also, prefer board_sysreset_default() only as a last resort - could
this be a DT property on the sysreset device, or a uclass-platdata
field, or a syscon driver, so it doesn't need a board hook, or even in
extremis an event? Weak functions are awkward to discover and don't
compose well.

Regards,
Simon

Re: [v1,0/4] reset: add board reset type

[dmukhin]

On Mon, May 25, 2026 at 09:25:13AM -0600, Simon Glass wrote:
> Hi Denis,
> 
> On 2026-05-22T01:23:09, None <dmukhin@ford.com> wrote:
> 
> > Patch 1 allows per-board default reset override.
> > Patch 2 adds reset -c support to explicitly trigger cold reset.
> > Patch 3 adds reset type printout on the console.
> > Patch 4 introduces a small fixup for the x86 reset driver.
> 
> Since you are adding new behaviour, I would expect a sandbox test to
> go with it. The sysreset sandbox driver should make this
> straightforward - what do you think?

Will add tests, thanks!

> 
> Also, prefer board_sysreset_default() only as a last resort - could
> this be a DT property on the sysreset device, or a uclass-platdata
> field, or a syscon driver, so it doesn't need a board hook, or even in
> extremis an event? Weak functions are awkward to discover and don't
> compose well.

I think to cover our peculiar board, Kconfig option should be the cleanest
way to parameterize the build.

> 
> Regards,
> Simon