Re: [PATCH 8/8] doc: usage: reset: document device-tree-driven reset modes

Hi Balaji,

On 2026-08-11T05:18:35, Balaji Selvanathan
<[email protected]> wrote:
> doc: usage: reset: document device-tree-driven reset modes
>
> Document the "reset -<mode>" and "reset -l" forms and explain that named
> reset modes are declared in the device tree (a "reboot-mode" subnode of the
> psci node) rather than hardcoded per SoC. Describe the 1-to-3 cell
> mode-<name> encoding and note that U-Boot's 32-bit PSCI cookie means a
> 3-cell mode with a non-zero cookie_hi is rejected rather than truncated.
>
> Signed-off-by: Balaji Selvanathan <[email protected]>
>
> doc/usage/cmd/reset.rst | 42 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)


> diff --git a/doc/usage/cmd/reset.rst b/doc/usage/cmd/reset.rst
> @@ -22,6 +24,46 @@ DDR and peripherals, on some boards also resets external PMIC.
> +Each ``mode-<name>`` property carries 1 to 3 cells describing a PSCI
> +``SYSTEM_RESET2`` vendor reset: ``<reset_type[, cookie_hi[, cookie_lo]]>``.
> +``reset_type`` must have bit 31 set (the vendor-reset bit). With two cells the
> +second is the cookie; with three cells the second is the high half and the
> +third the low half of a 64-bit cookie.

'must have bit 31 set' overstates what U-Boot does -
psci_system_reset2() in arch/arm/cpu/armv8/fwcall.c ORs
PSCI_RESET2_TYPE_VENDOR in unconditionally, and reboot-mode-psci does
not check or reject a reset_type with bit 31 clear. Either soften this
to something like 'is the SYSTEM_RESET2 reset_type from the PSCI spec,
with bit 31 (vendor-reset) set for the current users', or add a check
in the PSCI driver so the doc matches the code.

> diff --git a/doc/usage/cmd/reset.rst b/doc/usage/cmd/reset.rst
> @@ -22,6 +24,46 @@ DDR and peripherals, on some boards also resets external PMIC.
> +-<mode>
> +    Reset into a named mode registered with the reboot-mode framework, for
> +    example ``reset -edl`` to enter Qualcomm EDL/download mode. The modes are
> +    described in the device tree, not hardcoded per SoC (see below); an
> +    unknown mode prints the list of available modes.

Since this patch changes the command's exit behaviour (unknown mode
returns CMD_RET_USAGE, 'reset -l' can return CMD_RET_FAILURE), please
also update the 'Return value' section - it still claims '$? is always
set to 0 (true)', which is no longer true once this series lands.

Regards,
Simon