[PATCH v4 0/7] reset: add board reset type

[PATCH v4 0/7] 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.
Patch 5 introduces a small fixup for the x86 EFI reset driver.
Patch 6 updates documentation for reset command.
Patch 7 updates reset command tests.

Link to v3: https://lore.kernel.org/u-boot/20260529034839.2075806-1-dmukhin@ford.com

Denis Mukhin (7):
  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()
  reset: x86: Use cpu_hlt() in efi_reset_system()
  docs: reset: document cold reset option
  tests: reset: add cold/warm reset types

 cmd/boot.c                         |  3 +-
 doc/usage/cmd/reset.rst            | 11 +++++---
 drivers/sysreset/Kconfig           | 27 ++++++++++++++++++
 drivers/sysreset/sysreset-uclass.c | 44 +++++++++++++++++++++++++++---
 drivers/sysreset/sysreset_x86.c    |  5 ++--
 test/py/tests/test_reset.py        |  8 +++---
 6 files changed, 83 insertions(+), 15 deletions(-)

-- 
2.54.0

[PATCH v4 1/7] reset: Allow per-board reset type

[dmukhin]

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

Add a Kconfig choice to select the board-specific default reset type
used by the 'reset' command, allowing it to work on such boards.

Rely on 'poweroff' command if SYSRESET_POWER_OFF reset type is needed.

Keep cold reset as the default.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes since v3:
- updated comment for SYSRESET_CMD_RESET_DEFAULT_COLD in Kconfig description
- added a note in commit message on SYSRESET_POWER_OFF
- ensured no unreachable code
---
 drivers/sysreset/Kconfig           | 27 +++++++++++++++++++++++++++
 drivers/sysreset/sysreset-uclass.c | 13 ++++++++++++-
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 90f740f51d42..83bfbc5a30f7 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -57,6 +57,33 @@ config SYSRESET_CMD_RESET_ARGS
 	  additional arguments for implementing arch/board specific
 	  functionality.
 
+if SYSRESET_CMD_RESET
+choice
+	prompt "Default reset type for reset command"
+	default SYSRESET_CMD_RESET_DEFAULT_COLD
+	help
+	  Select the default reset type used by the reset command when no
+	  explicit reset type is requested.
+
+config SYSRESET_CMD_RESET_DEFAULT_WARM
+	bool "Warm reset"
+	help
+	  Reset CPU while keeping GPIOs active.
+
+config SYSRESET_CMD_RESET_DEFAULT_COLD
+	bool "Cold reset"
+	help
+	  Full cold reset of the machine, including CPU, GPIOs, PMIC and
+	  other logic in the machine.
+
+config SYSRESET_CMD_RESET_DEFAULT_POWER
+	bool "Power reset"
+	help
+	  Reset PMIC by removing and restoring power.
+
+endchoice
+endif
+
 if CMD_POWEROFF
 
 config SYSRESET_CMD_POWEROFF
diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index f25e09e9cd06..5c6dd7cc1c55 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -150,9 +150,20 @@ void reset_cpu(void)
 }
 
 #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET)
+static enum sysreset_t sysreset_get_default_type(void)
+{
+	if (IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_DEFAULT_WARM))
+		return SYSRESET_WARM;
+
+	if (IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_DEFAULT_POWER))
+		return SYSRESET_POWER;
+
+	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 = sysreset_get_default_type();
 
 	if (argc > 2)
 		return CMD_RET_USAGE;
-- 
2.54.0

[PATCH v4 2/7] reset: Add explicit cold reset support

[dmukhin]

Some prototype boards default to a non-cold reset type, e.g. warm reset.

Add 'reset -c' so users can explicitly request a cold reset when needed.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- preserved existing behavior for 'reset -edl' handling
- corrected commit message formatting
---
 cmd/boot.c                         |  3 ++-
 drivers/sysreset/sysreset-uclass.c | 13 +++++++++++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/cmd/boot.c b/cmd/boot.c
index 29cdf4a9a81a..5cac6cf3fed0 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -59,13 +59,14 @@ U_BOOT_CMD(
 U_BOOT_CMD(
 	reset, 2, 0,	do_reset,
 	"Perform RESET of the CPU",
-	"- cold boot without level specifier\n"
+	"- reset using the configured default type\n"
 #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
 // All options handled by sysreset drivers via their sysreset_ops.request_arg callback
 #ifdef CONFIG_SYSRESET_QCOM_PSCI
 	"reset -edl - Boot to Emergency DownLoad mode\n"
 #endif
 #endif
+	"reset -c - cold reset if implemented\n"
 	"reset -w - warm reset if implemented"
 );
 
diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index 5c6dd7cc1c55..1ba698b37285 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -168,8 +168,17 @@ 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] == '-' && strlen(argv[1]) == 2) {
+		switch (argv[1][1]) {
+		case 'c':
+			reset_type = SYSRESET_COLD;
+			break;
+		case 'w':
+			reset_type = SYSRESET_WARM;
+			break;
+		default:
+			return CMD_RET_USAGE;
+		}
 	}
 
 	printf("resetting ...\n");
-- 
2.54.0

[PATCH v4 3/7] reset: Print reset type on diagnostic console

[dmukhin]

Add a diagnostic console trace indicating the reset type.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- moved get_reset_type_str() next to do_reset()
---
 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 1ba698b37285..2b7717857ce6 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
 	return SYSRESET_COLD;
 }
 
+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 "power";
+	case SYSRESET_POWER_OFF:
+		return "power off";
+	default:
+		return "unknown";
+	}
+}
+
 int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
 	enum sysreset_t reset_type = sysreset_get_default_type();
@@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 		}
 	}
 
-	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

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

[dmukhin]

Use cpu_hlt() instead of open-coded "hlt" in pch_sysreset_power_off().

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- split EFI-part to a separate patch
---
 drivers/sysreset/sysreset_x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index c2f28c65280f..05a3ff9c8363 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -65,7 +65,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)
-- 
2.54.0

[PATCH v4 5/7] reset: x86: Use cpu_hlt() in efi_reset_system()

[dmukhin]

Use cpu_hlt() in busy loop in efi_reset_system() similarly to
pch_sysreset_power_off().

Note, this is safe for __efi_runtime-annotated efi_reset_system(),
because cpu_hlt() expands to a bare "hlt".

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- new patch
---
 drivers/sysreset/sysreset_x86.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index 05a3ff9c8363..afb77d9c5c21 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -120,7 +120,8 @@ void __efi_runtime EFIAPI efi_reset_system(
 
 	/* TODO EFI_RESET_SHUTDOWN */
 
-	while (1) { }
+	for (;;)
+		cpu_hlt();
 }
 #endif
 
-- 
2.54.0

[PATCH v4 6/7] docs: reset: document cold reset option

[dmukhin]

Update the reset command documentation to cover 'reset -c' and explain
that the default reset type can be overridden through the relevant
Kconfig choice.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- corrected description for reset command
---
 doc/usage/cmd/reset.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/usage/cmd/reset.rst b/doc/usage/cmd/reset.rst
index 79bc8b9deca5..660527d0b8f9 100644
--- a/doc/usage/cmd/reset.rst
+++ b/doc/usage/cmd/reset.rst
@@ -11,15 +11,18 @@ Synopsis
 
 ::
 
-    reset
-    reset -w
+    reset [-c|-w]
     reset -edl
 
 Description
 -----------
 
-Perform reset of the CPU. By default does COLD reset, which resets CPU,
-DDR and peripherals, on some boards also resets external PMIC.
+Perform reset of the CPU. By default does COLD reset unless overridden via
+Kconfig CONFIG_SYSRESET_CMD_RESET_DEFAULT_{COLD,WARM,POWER}.
+
+-c
+    Do COLD reset: reset CPU and peripheral/DDR; on some boards also resets
+    external PMIC.
 
 -w
     Do WARM reset: reset CPU but keep peripheral/DDR/PMIC active.
-- 
2.54.0

[PATCH v4 7/7] tests: reset: add cold/warm reset types

[dmukhin]

Extend reset tests to cover both -c/-w 'reset' command flags.
Make sure sandbox reset tests are passing.

Signed-off-by: Denis Mukhin <dmukhin@ford.com>
---
Changes since v3:
- switch to ' strings in the pytest
---
 test/py/tests/test_reset.py | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/test/py/tests/test_reset.py b/test/py/tests/test_reset.py
index af079a706647..7a12fe5f73c3 100644
--- a/test/py/tests/test_reset.py
+++ b/test/py/tests/test_reset.py
@@ -52,12 +52,12 @@ def test_reset(ubman):
     test_000_version.test_version(ubman)
 
 @pytest.mark.buildconfigspec('hush_parser')
-def test_reset_w(ubman):
-    """Test the reset -w command in non-JTAG bootmode.
-    It does WARM reset, which resets CPU but keep DDR/peripherals active.
+@pytest.mark.parametrize('reset_type', ['c', 'w'])
+def test_reset_type(ubman, reset_type):
+    """Test the reset {-c|-w} command in non-JTAG bootmode.
     """
     setup_reset_env(ubman)
-    ubman.run_command('reset -w', wait_for_reboot=True)
+    ubman.run_command('reset -' + reset_type, wait_for_reboot=True)
 
     # Checks the u-boot command prompt's functionality after reset
     test_000_version.test_version(ubman)
-- 
2.54.0

Re: [PATCH v4 2/7] reset: Add explicit cold reset support

[Simon Glass]

On 2026-06-03T07:07:36, None <dmukhin@ford.com> wrote:
> reset: Add explicit cold reset support
>
> Some prototype boards default to a non-cold reset type, e.g. warm reset.
>
> Add 'reset -c' so users can explicitly request a cold reset when needed.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> cmd/boot.c                         |  3 ++-
>  drivers/sysreset/sysreset-uclass.c | 13 +++++++++++--
>  2 files changed, 13 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Simon Glass]

On 2026-06-03T07:07:36, 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(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

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

[Simon Glass]

On 2026-06-03T07:07:36, None <dmukhin@ford.com> wrote:
> reset: x86: Use cpu_hlt() in pch_sysreset_power_off()
>
> Use cpu_hlt() instead of open-coded 'hlt' in pch_sysreset_power_off().
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> drivers/sysreset/sysreset_x86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v4 5/7] reset: x86: Use cpu_hlt() in efi_reset_system()

[Simon Glass]

On 2026-06-03T07:07:36, None <dmukhin@ford.com> wrote:
> reset: x86: Use cpu_hlt() in efi_reset_system()
>
> Use cpu_hlt() in busy loop in efi_reset_system() similarly to
> pch_sysreset_power_off().
>
> Note, this is safe for __efi_runtime-annotated efi_reset_system(),
> because cpu_hlt() expands to a bare 'hlt'.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> drivers/sysreset/sysreset_x86.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v4 6/7] docs: reset: document cold reset option

[Simon Glass]

On 2026-06-03T07:07:36, None <dmukhin@ford.com> wrote:
> docs: reset: document cold reset option
>
> Update the reset command documentation to cover 'reset -c' and explain
> that the default reset type can be overridden through the relevant
> Kconfig choice.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> doc/usage/cmd/reset.rst | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v4 7/7] tests: reset: add cold/warm reset types

[Simon Glass]

On 2026-06-03T07:07:36, None <dmukhin@ford.com> wrote:
> tests: reset: add cold/warm reset types
>
> Extend reset tests to cover both -c/-w 'reset' command flags.
> Make sure sandbox reset tests are passing.
>
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>
> test/py/tests/test_reset.py | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v4 2/7] reset: Add explicit cold reset support

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Wed, Jun 03, 2026 at 12:07:38AM -0700, dmukhin@ford.com wrote:

> Some prototype boards default to a non-cold reset type, e.g. warm reset.
> 
> Add 'reset -c' so users can explicitly request a cold reset when needed.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - preserved existing behavior for 'reset -edl' handling
> - corrected commit message formatting

This, and the subsequent test add growth in SPL on platforms that aren't
using it, and then one of them is now too large to link. Looking harder
at the code, we need to start out with some sort of re-factoring to move
do_reset / do_poweroff out of drivers/sysreset/sysreset-uclass.c and in
to something under cmd/ (and not conflict with the non-DM implementation
of those functions).
https://docs.u-boot-project.org/en/latest/develop/ci_testing.html is a
pointer on running CI which I forget if I'd given you for something else
or not yet, but would also show the current series failing on the
rockchip world build job.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 2/7] reset: Add explicit cold reset support

[dmukhin]

On Tue, Jun 16, 2026 at 03:44:50PM -0600, Tom Rini wrote:
> On Wed, Jun 03, 2026 at 12:07:38AM -0700, dmukhin@ford.com wrote:
> 
> > Some prototype boards default to a non-cold reset type, e.g. warm reset.
> > 
> > Add 'reset -c' so users can explicitly request a cold reset when needed.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v3:
> > - preserved existing behavior for 'reset -edl' handling
> > - corrected commit message formatting
> 
> This, and the subsequent test add growth in SPL on platforms that aren't
> using it, and then one of them is now too large to link. Looking harder
> at the code, we need to start out with some sort of re-factoring to move
> do_reset / do_poweroff out of drivers/sysreset/sysreset-uclass.c and in
> to something under cmd/ (and not conflict with the non-DM implementation
> of those functions).
> https://docs.u-boot-project.org/en/latest/develop/ci_testing.html is a
> pointer on running CI which I forget if I'd given you for something else
> or not yet, but would also show the current series failing on the
> rockchip world build job.

Thanks, will double check CI; I haven't tried CI yet.

> 
> -- 
> Tom

Re: [PATCH v4 2/7] reset: Add explicit cold reset support

[Quentin Schulz]

Hi Denis,

On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> Some prototype boards default to a non-cold reset type, e.g. warm reset.
> 
> Add 'reset -c' so users can explicitly request a cold reset when needed.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - preserved existing behavior for 'reset -edl' handling
> - corrected commit message formatting
> ---
>   cmd/boot.c                         |  3 ++-
>   drivers/sysreset/sysreset-uclass.c | 13 +++++++++++--
>   2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/cmd/boot.c b/cmd/boot.c
> index 29cdf4a9a81a..5cac6cf3fed0 100644
> --- a/cmd/boot.c
> +++ b/cmd/boot.c
> @@ -59,13 +59,14 @@ U_BOOT_CMD(
>   U_BOOT_CMD(
>   	reset, 2, 0,	do_reset,
>   	"Perform RESET of the CPU",
> -	"- cold boot without level specifier\n"
> +	"- reset using the configured default type\n"

NACK. It performs a cold boot when the level (-w) is not specified so we 
need to keep this as is.

>   #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
>   // All options handled by sysreset drivers via their sysreset_ops.request_arg callback
>   #ifdef CONFIG_SYSRESET_QCOM_PSCI
>   	"reset -edl - Boot to Emergency DownLoad mode\n"
>   #endif
>   #endif
> +	"reset -c - cold reset if implemented\n"

But... why? `reset` already does that why do we need yet another option 
for something we already do when no argument is passed?

>   	"reset -w - warm reset if implemented"
>   );
>   
> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> index 5c6dd7cc1c55..1ba698b37285 100644
> --- a/drivers/sysreset/sysreset-uclass.c
> +++ b/drivers/sysreset/sysreset-uclass.c
> @@ -168,8 +168,17 @@ 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] == '-' && strlen(argv[1]) == 2) {
> +		switch (argv[1][1]) {
> +		case 'c':
> +			reset_type = SYSRESET_COLD;
> +			break;
> +		case 'w':
> +			reset_type = SYSRESET_WARM;
> +			break;
> +		default:
> +			return CMD_RET_USAGE;

NACK. We support passing arguments to sysreset drivers whenever -w is 
not passed, so this will break them. See the sysreset_walk_arg below.

Cheers,
Quentin

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Quentin Schulz]

Hi Denis,

On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> Add a diagnostic console trace indicating the reset type.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - moved get_reset_type_str() next to do_reset()
> ---
>   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 1ba698b37285..2b7717857ce6 100644
> --- a/drivers/sysreset/sysreset-uclass.c
> +++ b/drivers/sysreset/sysreset-uclass.c
> @@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
>   	return SYSRESET_COLD;
>   }
>   
> +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 "power";
> +	case SYSRESET_POWER_OFF:
> +		return "power off";
> +	default:
> +		return "unknown";
> +	}
> +}
> +
>   int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>   {
>   	enum sysreset_t reset_type = sysreset_get_default_type();
> @@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>   		}
>   	}
>   
> -	printf("resetting ...\n");
> +	printf("resetting (%s)...\n", get_reset_type_str(reset_type));

NACK, this is potentially misleading as sysreset drivers can end up 
performing something different (see sysreset_walk_arg() just below).

Cheers,
Quentin

Re: [PATCH v4 6/7] docs: reset: document cold reset option

[Quentin Schulz]

On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> Update the reset command documentation to cover 'reset -c' and explain
> that the default reset type can be overridden through the relevant
> Kconfig choice.
> 
> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> ---
> Changes since v3:
> - corrected description for reset command
> ---
>   doc/usage/cmd/reset.rst | 11 +++++++----
>   1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/usage/cmd/reset.rst b/doc/usage/cmd/reset.rst
> index 79bc8b9deca5..660527d0b8f9 100644
> --- a/doc/usage/cmd/reset.rst
> +++ b/doc/usage/cmd/reset.rst
> @@ -11,15 +11,18 @@ Synopsis
>   
>   ::
>   
> -    reset
> -    reset -w
> +    reset [-c|-w]
>       reset -edl
>   
>   Description
>   -----------
>   
> -Perform reset of the CPU. By default does COLD reset, which resets CPU,
> -DDR and peripherals, on some boards also resets external PMIC.
> +Perform reset of the CPU. By default does COLD reset unless overridden via
> +Kconfig CONFIG_SYSRESET_CMD_RESET_DEFAULT_{COLD,WARM,POWER}.
> +
> +-c
> +    Do COLD reset: reset CPU and peripheral/DDR; on some boards also resets
> +    external PMIC.
>   

I really don't like this. I'm afraid we'll end up with very different 
meanings by architecture, vendor or even board. I'm not sure I have 
anything to suggest though (and maybe we've already reached this issue), 
so this is not a NACK but phew, I fear for the future.

Cheers,
Quentin

Re: [PATCH v4 2/7] reset: Add explicit cold reset support

[Simon Glass]

Hi Quentin,

On Fri, 26 Jun 2026 at 16:00, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Denis,
>
> On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> > Some prototype boards default to a non-cold reset type, e.g. warm reset.
> >
> > Add 'reset -c' so users can explicitly request a cold reset when needed.
> >
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v3:
> > - preserved existing behavior for 'reset -edl' handling
> > - corrected commit message formatting
> > ---
> >   cmd/boot.c                         |  3 ++-
> >   drivers/sysreset/sysreset-uclass.c | 13 +++++++++++--
> >   2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/cmd/boot.c b/cmd/boot.c
> > index 29cdf4a9a81a..5cac6cf3fed0 100644
> > --- a/cmd/boot.c
> > +++ b/cmd/boot.c
> > @@ -59,13 +59,14 @@ U_BOOT_CMD(
> >   U_BOOT_CMD(
> >       reset, 2, 0,    do_reset,
> >       "Perform RESET of the CPU",
> > -     "- cold boot without level specifier\n"
> > +     "- reset using the configured default type\n"
>
> NACK. It performs a cold boot when the level (-w) is not specified so we
> need to keep this as is.
>
> >   #if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
> >   // All options handled by sysreset drivers via their sysreset_ops.request_arg callback
> >   #ifdef CONFIG_SYSRESET_QCOM_PSCI
> >       "reset -edl - Boot to Emergency DownLoad mode\n"
> >   #endif
> >   #endif
> > +     "reset -c - cold reset if implemented\n"
>
> But... why? `reset` already does that why do we need yet another option
> for something we already do when no argument is passed?
>
> >       "reset -w - warm reset if implemented"
> >   );
> >
> > diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> > index 5c6dd7cc1c55..1ba698b37285 100644
> > --- a/drivers/sysreset/sysreset-uclass.c
> > +++ b/drivers/sysreset/sysreset-uclass.c
> > @@ -168,8 +168,17 @@ 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] == '-' && strlen(argv[1]) == 2) {
> > +             switch (argv[1][1]) {
> > +             case 'c':
> > +                     reset_type = SYSRESET_COLD;
> > +                     break;
> > +             case 'w':
> > +                     reset_type = SYSRESET_WARM;
> > +                     break;
> > +             default:
> > +                     return CMD_RET_USAGE;
>
> NACK. We support passing arguments to sysreset drivers whenever -w is
> not passed, so this will break them. See the sysreset_walk_arg below.

Yes, I wasn't too keen on that [1]...it seems to be causing problems
now. So I suggest removing that method. The only user is Qualcomm - we
can define a new sysreset_t value instead (such as
SYSRESET_TO_DOWNLOAD). Passing argc/argv to a uclass method is really
not a great idea - arg parsing should be done in cmd/

Regards,
Simon

[1] https://lore.kernel.org/u-boot/20260217143957.GZ2747538@bill-the-cat/

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Simon Glass]

Hi Quentin,

On Fri, 26 Jun 2026 at 16:01, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Denis,
>
> On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> > Add a diagnostic console trace indicating the reset type.
> >
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v3:
> > - moved get_reset_type_str() next to do_reset()
> > ---
> >   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 1ba698b37285..2b7717857ce6 100644
> > --- a/drivers/sysreset/sysreset-uclass.c
> > +++ b/drivers/sysreset/sysreset-uclass.c
> > @@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
> >       return SYSRESET_COLD;
> >   }
> >
> > +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 "power";
> > +     case SYSRESET_POWER_OFF:
> > +             return "power off";
> > +     default:
> > +             return "unknown";
> > +     }
> > +}
> > +
> >   int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >   {
> >       enum sysreset_t reset_type = sysreset_get_default_type();
> > @@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >               }
> >       }
> >
> > -     printf("resetting ...\n");
> > +     printf("resetting (%s)...\n", get_reset_type_str(reset_type));
>
> NACK, this is potentially misleading as sysreset drivers can end up
> performing something different (see sysreset_walk_arg() just below).

That's always been the case, but it was silent - do you suggest that
it prints a new reset message for each type? Bear in mind that when
one succeeds it is unlikely that the serial console will be updated
before the reset happens. In the majority of cases the requested reset
succeeds.

I quite like showing which reset is being attempted.

Regards,
Simon

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Quentin Schulz]

Hi Simon,

On 6/27/26 10:30 AM, Simon Glass wrote:
> Hi Quentin,
> 
> On Fri, 26 Jun 2026 at 16:01, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>
>> Hi Denis,
>>
>> On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
>>> Add a diagnostic console trace indicating the reset type.
>>>
>>> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>>> ---
>>> Changes since v3:
>>> - moved get_reset_type_str() next to do_reset()
>>> ---
>>>    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 1ba698b37285..2b7717857ce6 100644
>>> --- a/drivers/sysreset/sysreset-uclass.c
>>> +++ b/drivers/sysreset/sysreset-uclass.c
>>> @@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
>>>        return SYSRESET_COLD;
>>>    }
>>>
>>> +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 "power";
>>> +     case SYSRESET_POWER_OFF:
>>> +             return "power off";
>>> +     default:
>>> +             return "unknown";
>>> +     }
>>> +}
>>> +
>>>    int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>>>    {
>>>        enum sysreset_t reset_type = sysreset_get_default_type();
>>> @@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>>>                }
>>>        }
>>>
>>> -     printf("resetting ...\n");
>>> +     printf("resetting (%s)...\n", get_reset_type_str(reset_type));
>>
>> NACK, this is potentially misleading as sysreset drivers can end up
>> performing something different (see sysreset_walk_arg() just below).
> 
> That's always been the case, but it was silent - do you suggest that

We only said we are resetting, not which kind.

> it prints a new reset message for each type? Bear in mind that when
> one succeeds it is unlikely that the serial console will be updated
> before the reset happens. In the majority of cases the requested reset
> succeeds.
> 

Indeed.

> I quite like showing which reset is being attempted.

I don't think it's worth the potential confusion. After all, we may very 
well NOT do the requested kind of reset. Wording will be important if we 
really want to do this. We need to be clear something else may be done 
in the end.

We could print before attempting each sysreset type which kind we're 
trying... I think it's actually a good idea, because it isn't 
necessarily clear that even if you request a warm reset, you may still 
get a cold reset (or even a power-off) if no driver supports doing a 
warm reset. At the same time, we don't have a delay between printing and 
attempting a reset, so indeed like you said it may never get printed.

So, first line in the while-loop in sysreset_walk would say "attempting 
sysreset <type>" and after the for-loop we check on ret != -EINPROGRESS 
and then print "no driver could do sysreset <type>, trying more 
aggressive reset" or something like that. Before return, we check on 
-EINPROGRESS and tell the user we failed to do any kind of reset. We 
probably should have some of those messages rather debug messages 
though, I fear it may be a bit verbose.

Cheers,
Quentin

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Simon Glass]

Hi Quentin,

On Thu, 23 Jul 2026 at 10:43, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Simon,
>
> On 6/27/26 10:30 AM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Fri, 26 Jun 2026 at 16:01, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >>
> >> Hi Denis,
> >>
> >> On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> >>> Add a diagnostic console trace indicating the reset type.
> >>>
> >>> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> >>> ---
> >>> Changes since v3:
> >>> - moved get_reset_type_str() next to do_reset()
> >>> ---
> >>>    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 1ba698b37285..2b7717857ce6 100644
> >>> --- a/drivers/sysreset/sysreset-uclass.c
> >>> +++ b/drivers/sysreset/sysreset-uclass.c
> >>> @@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
> >>>        return SYSRESET_COLD;
> >>>    }
> >>>
> >>> +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 "power";
> >>> +     case SYSRESET_POWER_OFF:
> >>> +             return "power off";
> >>> +     default:
> >>> +             return "unknown";
> >>> +     }
> >>> +}
> >>> +
> >>>    int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >>>    {
> >>>        enum sysreset_t reset_type = sysreset_get_default_type();
> >>> @@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >>>                }
> >>>        }
> >>>
> >>> -     printf("resetting ...\n");
> >>> +     printf("resetting (%s)...\n", get_reset_type_str(reset_type));
> >>
> >> NACK, this is potentially misleading as sysreset drivers can end up
> >> performing something different (see sysreset_walk_arg() just below).
> >
> > That's always been the case, but it was silent - do you suggest that
>
> We only said we are resetting, not which kind.
>
> > it prints a new reset message for each type? Bear in mind that when
> > one succeeds it is unlikely that the serial console will be updated
> > before the reset happens. In the majority of cases the requested reset
> > succeeds.
> >
>
> Indeed.
>
> > I quite like showing which reset is being attempted.
>
> I don't think it's worth the potential confusion. After all, we may very
> well NOT do the requested kind of reset. Wording will be important if we
> really want to do this. We need to be clear something else may be done
> in the end.
>
> We could print before attempting each sysreset type which kind we're
> trying... I think it's actually a good idea, because it isn't
> necessarily clear that even if you request a warm reset, you may still
> get a cold reset (or even a power-off) if no driver supports doing a
> warm reset. At the same time, we don't have a delay between printing and
> attempting a reset, so indeed like you said it may never get printed.
>
> So, first line in the while-loop in sysreset_walk would say "attempting
> sysreset <type>" and after the for-loop we check on ret != -EINPROGRESS
> and then print "no driver could do sysreset <type>, trying more
> aggressive reset" or something like that. Before return, we check on
> -EINPROGRESS and tell the user we failed to do any kind of reset. We
> probably should have some of those messages rather debug messages
> though, I fear it may be a bit verbose.

The odd thing is that the last thing you would likely see (with this
approach) is the reset type before the one that actually succeeded. It
could be a bit confusing. But I suppose that would be OK, since we are
resetting and people should be aware that this can result in lost
serial output.

Another approach (perhaps a follow-up to this series) could be to have
the driver indicate (e.g. with plat data) which reset types it
supports, so we don't bother trying unsupported ones.

Regards,
Simon

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Quentin Schulz]

On 7/28/26 1:38 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Thu, 23 Jul 2026 at 10:43, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>
>> Hi Simon,
>>
>> On 6/27/26 10:30 AM, Simon Glass wrote:
>>> Hi Quentin,
>>>
>>> On Fri, 26 Jun 2026 at 16:01, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>>
>>>> Hi Denis,
>>>>
>>>> On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
>>>>> Add a diagnostic console trace indicating the reset type.
>>>>>
>>>>> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
>>>>> ---
>>>>> Changes since v3:
>>>>> - moved get_reset_type_str() next to do_reset()
>>>>> ---
>>>>>     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 1ba698b37285..2b7717857ce6 100644
>>>>> --- a/drivers/sysreset/sysreset-uclass.c
>>>>> +++ b/drivers/sysreset/sysreset-uclass.c
>>>>> @@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
>>>>>         return SYSRESET_COLD;
>>>>>     }
>>>>>
>>>>> +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 "power";
>>>>> +     case SYSRESET_POWER_OFF:
>>>>> +             return "power off";
>>>>> +     default:
>>>>> +             return "unknown";
>>>>> +     }
>>>>> +}
>>>>> +
>>>>>     int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>>>>>     {
>>>>>         enum sysreset_t reset_type = sysreset_get_default_type();
>>>>> @@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>>>>>                 }
>>>>>         }
>>>>>
>>>>> -     printf("resetting ...\n");
>>>>> +     printf("resetting (%s)...\n", get_reset_type_str(reset_type));
>>>>
>>>> NACK, this is potentially misleading as sysreset drivers can end up
>>>> performing something different (see sysreset_walk_arg() just below).
>>>
>>> That's always been the case, but it was silent - do you suggest that
>>
>> We only said we are resetting, not which kind.
>>
>>> it prints a new reset message for each type? Bear in mind that when
>>> one succeeds it is unlikely that the serial console will be updated
>>> before the reset happens. In the majority of cases the requested reset
>>> succeeds.
>>>
>>
>> Indeed.
>>
>>> I quite like showing which reset is being attempted.
>>
>> I don't think it's worth the potential confusion. After all, we may very
>> well NOT do the requested kind of reset. Wording will be important if we
>> really want to do this. We need to be clear something else may be done
>> in the end.
>>
>> We could print before attempting each sysreset type which kind we're
>> trying... I think it's actually a good idea, because it isn't
>> necessarily clear that even if you request a warm reset, you may still
>> get a cold reset (or even a power-off) if no driver supports doing a
>> warm reset. At the same time, we don't have a delay between printing and
>> attempting a reset, so indeed like you said it may never get printed.
>>
>> So, first line in the while-loop in sysreset_walk would say "attempting
>> sysreset <type>" and after the for-loop we check on ret != -EINPROGRESS
>> and then print "no driver could do sysreset <type>, trying more
>> aggressive reset" or something like that. Before return, we check on
>> -EINPROGRESS and tell the user we failed to do any kind of reset. We
>> probably should have some of those messages rather debug messages
>> though, I fear it may be a bit verbose.
> 
> The odd thing is that the last thing you would likely see (with this
> approach) is the reset type before the one that actually succeeded. It
> could be a bit confusing. But I suppose that would be OK, since we are
> resetting and people should be aware that this can result in lost
> serial output.
> 

True, that's also misleading. We could flush() also and then hopefully 
the message really will be printed.

> Another approach (perhaps a follow-up to this series) could be to have
> the driver indicate (e.g. with plat data) which reset types it
> supports, so we don't bother trying unsupported ones.
> 

We're iterating over all sysreset drivers in increasing power reset 
levels until we find one that works and do that reset, so filtering for 
supported levels by drivers... I'm not sure what that would help with 
here? What am I missing?

Cheers,
Quentin

Re: [PATCH v4 3/7] reset: Print reset type on diagnostic console

[Simon Glass]

Hi Quentin,

On Tue, 28 Jul 2026 at 05:43, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
>
>
> On 7/28/26 1:38 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Thu, 23 Jul 2026 at 10:43, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 6/27/26 10:30 AM, Simon Glass wrote:
> >>> Hi Quentin,
> >>>
> >>> On Fri, 26 Jun 2026 at 16:01, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >>>>
> >>>> Hi Denis,
> >>>>
> >>>> On 6/3/26 9:07 AM, dmukhin@ford.com wrote:
> >>>>> Add a diagnostic console trace indicating the reset type.
> >>>>>
> >>>>> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> >>>>> ---
> >>>>> Changes since v3:
> >>>>> - moved get_reset_type_str() next to do_reset()
> >>>>> ---
> >>>>>     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 1ba698b37285..2b7717857ce6 100644
> >>>>> --- a/drivers/sysreset/sysreset-uclass.c
> >>>>> +++ b/drivers/sysreset/sysreset-uclass.c
> >>>>> @@ -161,6 +161,22 @@ static enum sysreset_t sysreset_get_default_type(void)
> >>>>>         return SYSRESET_COLD;
> >>>>>     }
> >>>>>
> >>>>> +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 "power";
> >>>>> +     case SYSRESET_POWER_OFF:
> >>>>> +             return "power off";
> >>>>> +     default:
> >>>>> +             return "unknown";
> >>>>> +     }
> >>>>> +}
> >>>>> +
> >>>>>     int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >>>>>     {
> >>>>>         enum sysreset_t reset_type = sysreset_get_default_type();
> >>>>> @@ -181,7 +197,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >>>>>                 }
> >>>>>         }
> >>>>>
> >>>>> -     printf("resetting ...\n");
> >>>>> +     printf("resetting (%s)...\n", get_reset_type_str(reset_type));
> >>>>
> >>>> NACK, this is potentially misleading as sysreset drivers can end up
> >>>> performing something different (see sysreset_walk_arg() just below).
> >>>
> >>> That's always been the case, but it was silent - do you suggest that
> >>
> >> We only said we are resetting, not which kind.
> >>
> >>> it prints a new reset message for each type? Bear in mind that when
> >>> one succeeds it is unlikely that the serial console will be updated
> >>> before the reset happens. In the majority of cases the requested reset
> >>> succeeds.
> >>>
> >>
> >> Indeed.
> >>
> >>> I quite like showing which reset is being attempted.
> >>
> >> I don't think it's worth the potential confusion. After all, we may very
> >> well NOT do the requested kind of reset. Wording will be important if we
> >> really want to do this. We need to be clear something else may be done
> >> in the end.
> >>
> >> We could print before attempting each sysreset type which kind we're
> >> trying... I think it's actually a good idea, because it isn't
> >> necessarily clear that even if you request a warm reset, you may still
> >> get a cold reset (or even a power-off) if no driver supports doing a
> >> warm reset. At the same time, we don't have a delay between printing and
> >> attempting a reset, so indeed like you said it may never get printed.
> >>
> >> So, first line in the while-loop in sysreset_walk would say "attempting
> >> sysreset <type>" and after the for-loop we check on ret != -EINPROGRESS
> >> and then print "no driver could do sysreset <type>, trying more
> >> aggressive reset" or something like that. Before return, we check on
> >> -EINPROGRESS and tell the user we failed to do any kind of reset. We
> >> probably should have some of those messages rather debug messages
> >> though, I fear it may be a bit verbose.
> >
> > The odd thing is that the last thing you would likely see (with this
> > approach) is the reset type before the one that actually succeeded. It
> > could be a bit confusing. But I suppose that would be OK, since we are
> > resetting and people should be aware that this can result in lost
> > serial output.
> >
>
> True, that's also misleading. We could flush() also and then hopefully
> the message really will be printed.

Yes, perhaps as a Kconfig option though, since some platforms reset
due to a fatal error, etc. Also it couldbe a follow-up, not blocking
this series.

>
> > Another approach (perhaps a follow-up to this series) could be to have
> > the driver indicate (e.g. with plat data) which reset types it
> > supports, so we don't bother trying unsupported ones.
> >
>
> We're iterating over all sysreset drivers in increasing power reset
> levels until we find one that works and do that reset, so filtering for
> supported levels by drivers... I'm not sure what that would help with
> here? What am I missing?

Hmm yes if the driver returns -ENOSYS then we know that type is not
supported, so it doesn't add much.

Regards,
Simon

Re: [PATCH v4 2/7] reset: Add explicit cold reset support

[Denis Mukhin via U-Boot]

On Tue, Jun 16, 2026 at 03:44:50PM -0600, Tom Rini wrote:
> On Wed, Jun 03, 2026 at 12:07:38AM -0700, dmukhin@ford.com wrote:
> 
> > Some prototype boards default to a non-cold reset type, e.g. warm reset.
> > 
> > Add 'reset -c' so users can explicitly request a cold reset when needed.
> > 
> > Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > ---
> > Changes since v3:
> > - preserved existing behavior for 'reset -edl' handling
> > - corrected commit message formatting
> 
> This, and the subsequent test add growth in SPL on platforms that aren't
> using it, and then one of them is now too large to link. Looking harder
> at the code, we need to start out with some sort of re-factoring to move
> do_reset / do_poweroff out of drivers/sysreset/sysreset-uclass.c and in
> to something under cmd/ (and not conflict with the non-DM implementation
> of those functions).

I am (slowly) working on the v5 going this direction:
   https://github.com/dmkhn/u-boot/commits/u/x86-reset-v5/

> https://docs.u-boot-project.org/en/latest/develop/ci_testing.html is a
> pointer on running CI which I forget if I'd given you for something else
> or not yet, but would also show the current series failing on the
> rockchip world build job.
> 
> -- 
> Tom