[PATCH v6 0/5] Implement reset to EDL for qcs9100

[PATCH v6 0/5] Implement reset to EDL for qcs9100

[Varadarajan Narayanan]

Using the 'reboot edl' command in Linux, the platform can reboot to the
Emergency Download mode. Implement the same for U-Boot.

v6: * Add r-b Sumit
    * Wrap the new code inside CONFIG_SYSRESET_CMD_RESET_ARGS
    * Size change details
------------------------
qcom_qcs9100
------------------------
Building 2 commits for 1 boards (1 thread, 16 jobs per thread)
01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
07: qcom_defconfig: enable psci based sysreset
    2    0    0 /2              qcom_qcs9100
Completed: 2 total built, 2 newly), duration 0:00:25, rate 0.08
/tmp/qcom_qcs9100/tot/boards.cfg is up to date. Nothing to do.
Summary of 2 commits for 1 boards (1 thread, 16 jobs per thread)
01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
07: qcom_defconfig: enable psci based sysreset
   aarch64: (for 1/1 boards) all +145.0 data -40.0 rodata +89.0 text +96.0
            qcom_qcs9100   : all +145 data -40 rodata +89 text +96
               u-boot: add: 9/0, grow: 4/0 bytes: 656/0 (656)
                 function                                   old     new   delta
                 sysreset_walk_arg                            -     124    +124
                 _u_boot_list_2_driver_2_qcom_psci_sysreset       -     120    +120
                 qcom_psci_sysreset_request_arg               -      84     +84
                 smc_call                                     -      68     +68
                 do_reset                                   100     160     +60
                 psci_system_reset2                           -      44     +44
                 psci_features                                -      44     +44
                 sysreset_request_arg                         -      32     +32
                 qcom_psci_sysreset_ops                       -      32     +32
                 psci_bind                                  188     212     +24
                 qcom_pshold_ops                             24      32      +8
                 qcom_psci_sysreset_get_status                -       8      +8
                 psci_sysreset_ops                           24      32      +8
(no errors to report)

------------------------
qemu_arm
------------------------
Building 2 commits for 1 boards (1 thread, 16 jobs per thread)
01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
07: qcom_defconfig: enable psci based sysreset
    2    0    0 /2              qemu_arm
Completed: 2 total built, 2 newly), duration 0:00:19, rate 0.11
/tmp/qemu_arm/tot/boards.cfg is up to date. Nothing to do.
Summary of 2 commits for 1 boards (1 thread, 16 jobs per thread)
01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
07: qcom_defconfig: enable psci based sysreset
(no errors to report)

------------------------
qemu_arm64
------------------------
Building 2 commits for 1 boards (1 thread, 16 jobs per thread)
01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
07: qcom_defconfig: enable psci based sysreset
    2    0    0 /2              qemu_arm64
Completed: 2 total built, 2 newly), duration 0:00:18, rate 0.11
/tmp/qemu_arm64/tot/boards.cfg is up to date. Nothing to do.
Summary of 2 commits for 1 boards (1 thread, 16 jobs per thread)
01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
07: qcom_defconfig: enable psci based sysreset
   aarch64: (for 1/1 boards) all +8.0 data +8.0
            qemu_arm64     : all +8 data +8
               u-boot: add: 0/0, grow: 1/0 bytes: 8/0 (8)
                 function                                   old     new   delta
                 psci_sysreset_ops                           24      32      +8
(no errors to report)

v5: * Update author and signed-off-by email id from quicinc.com to oss.qualcomm.com
    * Add r-b tags
    * Enable CONFIG_SYSRESET_QCOM_PSCI in qcom_defconfig instead of qcs9100_defconfig

v4: * Update documentation about '-edl' option
    * Add API to check for support of PSCI functions
    * Check if RESET2 is supported before issuing the command
    * Fix compiler warnings

v3: * Introduce a sysreset op that will pass down the 'reset' command
      arguments to registered handlers
    * Handle 'reset to edl' alone in qcom-psci driver

v2: * Rebased to recent sources
    * Dropped the first patch as it is not applicable anymore
    * Bind the new driver from psci driver

Varadarajan Narayanan (5):
  arm: psci: Add API to check for support of specific PSCI function
  drivers: sysreset: Add sysreset op that can take arguments
  sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs
  cmd: boot: Add '-edl' option to reset command documentation
  qcom_defconfig: enable psci based sysreset

 arch/arm/cpu/armv8/fwcall.c           | 15 +++++++++
 arch/arm/include/asm/system.h         |  1 +
 cmd/boot.c                            |  3 ++
 configs/qcom_defconfig                |  2 ++
 doc/usage/cmd/reset.rst               |  2 ++
 drivers/firmware/psci.c               |  4 +++
 drivers/sysreset/Kconfig              | 14 +++++++++
 drivers/sysreset/Makefile             |  1 +
 drivers/sysreset/sysreset-uclass.c    | 37 ++++++++++++++++++++++
 drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
 include/sysreset.h                    | 18 +++++++++++
 11 files changed, 142 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_qcom-psci.c

--
2.34.1

[PATCH v6 1/5] arm: psci: Add API to check for support of specific PSCI function

[Varadarajan Narayanan]

Add an API to check if a specific PSCI function is supported or not.
This is based on the psci_features() function present in Linux kernel
(drivers/firmware/psci/psci.c).

Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 arch/arm/cpu/armv8/fwcall.c   | 15 +++++++++++++++
 arch/arm/include/asm/system.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
index 87de09979b1..f834d770dd6 100644
--- a/arch/arm/cpu/armv8/fwcall.c
+++ b/arch/arm/cpu/armv8/fwcall.c
@@ -129,3 +129,18 @@ void __noreturn psci_system_off(void)
 	while (1)
 		;
 }
+
+int psci_features(u32 psci_func_id)
+{
+	struct pt_regs regs;
+
+	regs.regs[0] = ARM_PSCI_1_0_FN_PSCI_FEATURES;
+	regs.regs[1] = psci_func_id;
+
+	if (use_smc_for_psci)
+		smc_call(&regs);
+	else
+		hvc_call(&regs);
+
+	return regs.regs[0];
+}
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 4c1b81483c9..0b788bcf0e5 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -336,6 +336,7 @@ void smc_call(struct pt_regs *args);
 void __noreturn psci_system_reset(void);
 void __noreturn psci_system_reset2(u32 reset_level, u32 cookie);
 void __noreturn psci_system_off(void);
+int psci_features(u32 psci_func_id);
 
 #ifdef CONFIG_ARMV8_PSCI
 extern char __secure_start[];
-- 
2.34.1

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

[Varadarajan Narayanan]

Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
to receive arguments given to the 'reset' command. Process the
request_arg() op before the usual request() op.

Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v6: Wrap this functionality inside CONFIG_SYSRESET_CMD_RESET_ARGS
---
 drivers/sysreset/Kconfig           |  8 +++++++
 drivers/sysreset/sysreset-uclass.c | 37 ++++++++++++++++++++++++++++++
 include/sysreset.h                 | 18 +++++++++++++++
 3 files changed, 63 insertions(+)

diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 0181f6cd581..6fb0ca81dc6 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -49,6 +49,14 @@ config SYSRESET_CMD_RESET
 	help
 	  Enable sysreset implementation of the reset command.
 
+config SYSRESET_CMD_RESET_ARGS
+	bool "Enable reset command to take arguments"
+	help
+	  Pass on the arguments received by the 'reset' command to the
+	  sysreset driver(s). The sysreset driver(s) may make use of the
+	  additional arguments for implementing arch/board specific
+	  functionality.
+
 if CMD_POWEROFF
 
 config SYSRESET_CMD_POWEROFF
diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index 536ac727142..f25e09e9cd0 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -32,6 +32,18 @@ int sysreset_request(struct udevice *dev, enum sysreset_t type)
 	return ops->request(dev, type);
 }
 
+#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
+int sysreset_request_arg(struct udevice *dev, int argc, char * const argv[])
+{
+	struct sysreset_ops *ops = sysreset_get_ops(dev);
+
+	if (!ops->request_arg)
+		return -ENOSYS;
+
+	return ops->request_arg(dev, argc, argv);
+}
+#endif /* CONFIG_SYSRESET_CMD_RESET_ARGS */
+
 int sysreset_get_status(struct udevice *dev, char *buf, int size)
 {
 	struct sysreset_ops *ops = sysreset_get_ops(dev);
@@ -71,6 +83,26 @@ int sysreset_walk(enum sysreset_t type)
 	return ret;
 }
 
+#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
+int sysreset_walk_arg(int argc, char * const argv[])
+{
+	struct udevice *dev;
+	int ret = -ENOSYS;
+
+	while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
+		for (uclass_first_device(UCLASS_SYSRESET, &dev);
+		     dev;
+		     uclass_next_device(&dev)) {
+			ret = sysreset_request_arg(dev, argc, argv);
+			if (ret == -EINPROGRESS || ret == -EPROTONOSUPPORT)
+				break;
+		}
+	}
+
+	return ret;
+}
+#endif /* CONFIG_SYSRESET_CMD_RESET_ARGS */
+
 int sysreset_get_last_walk(void)
 {
 	struct udevice *dev;
@@ -132,6 +164,11 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 	printf("resetting ...\n");
 	mdelay(100);
 
+#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
+	if (argc > 1 && sysreset_walk_arg(argc, argv) == -EINPROGRESS)
+		return 0;
+#endif
+
 	sysreset_walk_halt(reset_type);
 
 	return 0;
diff --git a/include/sysreset.h b/include/sysreset.h
index ff20abdeed3..d1cc9ebc542 100644
--- a/include/sysreset.h
+++ b/include/sysreset.h
@@ -43,6 +43,24 @@ struct sysreset_ops {
 	 * (in which case this method will not actually return)
 	 */
 	int (*request)(struct udevice *dev, enum sysreset_t type);
+
+	/**
+	 * @request_arg: Reset handler implementations that might need to process
+	 *		 arguments given to the 'reset' command.
+	 *
+	 * Note that this function may return before the reset takes effect.
+	 *
+	 * @dev:	Device to be used for system reset
+	 * @argc:	No. of items in @argv
+	 * @argv:	Arguments given to 'reset' command
+	 * Return:
+	 * -EINPROGRESS		if the reset has started and will complete soon
+	 * -EPROTONOSUPPORT	if not supported by this device
+	 * 0			if the reset has already happened
+	 * (in which case this method will not actually return)
+	 */
+	int (*request_arg)(struct udevice *dev, int argc, char * const argv[]);
+
 	/**
 	 * @get_status:	get printable reset status information
 	 *
-- 
2.34.1

[PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Varadarajan Narayanan]

Implement request_arg() sysreset_op for QCOM SoCs that use
PSCI to reset to EDL (Emergency Download) mode.

Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v4: * Check if ARM_PSCI_1_1_FN64_SYSTEM_RESET2 is supported before
      issuing it

v3: * Move argument handling to a separate function and pass the
      arguments to the actual handler to process
    * Drop Qcom specific SYSRESET_EDL from the common enum

v2: * Update commit message
    * Elaborate Kconfig help text
    * Use '-edl' instead of 'edl' for consistency with other arguments of reset
      command
    * Remove 'weak' for qcom_psci_sysreset_get_status() and make it static
    * Mention 'SYSRESET_EDL' is Qcom specific in the enum's comments
---
 drivers/firmware/psci.c               |  4 +++
 drivers/sysreset/Kconfig              |  6 ++++
 drivers/sysreset/Makefile             |  1 +
 drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
 4 files changed, 56 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_qcom-psci.c

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 2e3223e1c32..b6838a244d2 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -186,6 +186,10 @@ static int psci_bind(struct udevice *dev)
 					 NULL);
 		if (ret)
 			pr_debug("PSCI System Reset was not bound.\n");
+		if (IS_ENABLED(CONFIG_SYSRESET_QCOM_PSCI) &&
+		    device_bind_driver(dev, "qcom_psci-sysreset",
+				       "qcom_psci-sysreset", NULL))
+			pr_debug("QCOM PSCI System Reset was not bound.\n");
 	}
 
 	/* From PSCI v1.0 onward we can discover services through ARM_SMCCC_FEATURE */
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 6fb0ca81dc6..905ad2a7769 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -301,6 +301,12 @@ config SYSRESET_RAA215300
 	help
 	  Add support for the system reboot via the Renesas RAA215300 PMIC.
 
+config SYSRESET_QCOM_PSCI
+	bool "Support reset to EDL for Qualcomm SoCs via PSCI"
+	help
+	  Add support for the reset to EDL (Emergency Download) on Qualcomm
+	  SoCs via PSCI.
+
 config SYSRESET_QCOM_PSHOLD
 	bool "Support sysreset for Qualcomm SoCs via PSHOLD"
 	help
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index f5c78b25896..8bb1eabd48e 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -30,5 +30,6 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
 obj-$(CONFIG_$(PHASE_)SYSRESET_AT91) += sysreset_at91.o
 obj-$(CONFIG_$(PHASE_)SYSRESET_X86) += sysreset_x86.o
 obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
+obj-$(CONFIG_SYSRESET_QCOM_PSCI) += sysreset_qcom-psci.o
 obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
 obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
diff --git a/drivers/sysreset/sysreset_qcom-psci.c b/drivers/sysreset/sysreset_qcom-psci.c
new file mode 100644
index 00000000000..3627bbf5c82
--- /dev/null
+++ b/drivers/sysreset/sysreset_qcom-psci.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017 Masahiro Yamada <yamada.masahiro@socionext.com>
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <dm.h>
+#include <sysreset.h>
+#include <asm/system.h>
+#include <linux/errno.h>
+#include <linux/psci.h>
+#include <asm/psci.h>
+
+static int qcom_psci_sysreset_get_status(struct udevice *dev, char *buf, int size)
+{
+	return -EOPNOTSUPP;
+}
+
+static int qcom_psci_sysreset_request_arg(struct udevice *dev, int argc,
+					  char * const argv[])
+{
+	if (!strncasecmp(argv[1], "-edl", 4)) {
+		/* Supported in qcs9100, qcs8300, sc7280, qcs615 */
+		if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) ==
+							ARM_PSCI_RET_SUCCESS) {
+			psci_system_reset2(0, 1);
+			return -EINPROGRESS;
+		}
+		printf("PSCI SYSTEM_RESET2 not supported\n");
+	}
+
+	return -EPROTONOSUPPORT;
+}
+
+static struct sysreset_ops qcom_psci_sysreset_ops = {
+	.request_arg = qcom_psci_sysreset_request_arg,
+	.get_status = qcom_psci_sysreset_get_status,
+};
+
+U_BOOT_DRIVER(qcom_psci_sysreset) = {
+	.name = "qcom_psci-sysreset",
+	.id = UCLASS_SYSRESET,
+	.ops = &qcom_psci_sysreset_ops,
+	.flags = DM_FLAG_PRE_RELOC,
+};
-- 
2.34.1

[PATCH v6 4/5] cmd: boot: Add '-edl' option to reset command documentation

[Varadarajan Narayanan]

Add help text about '-edl' option to reset command definition and
related documentation.

Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 cmd/boot.c              | 3 +++
 doc/usage/cmd/reset.rst | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/cmd/boot.c b/cmd/boot.c
index 23496cafdf5..d80f9d8c05d 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -60,6 +60,9 @@ U_BOOT_CMD(
 	reset, 2, 0,	do_reset,
 	"Perform RESET of the CPU",
 	"- cold boot without level specifier\n"
+#ifdef CONFIG_SYSRESET_QCOM_PSCI
+	"reset -edl - Boot to Emergency DownLoad mode\n"
+#endif
 	"reset -w - warm reset if implemented"
 );
 
diff --git a/doc/usage/cmd/reset.rst b/doc/usage/cmd/reset.rst
index 126db21cdb8..366b17eea16 100644
--- a/doc/usage/cmd/reset.rst
+++ b/doc/usage/cmd/reset.rst
@@ -22,6 +22,8 @@ DDR and peripherals, on some boards also resets external PMIC.
 -w
     Do warm WARM, reset CPU but keep peripheral/DDR/PMIC active.
 
+-edl
+    Boot to Emergency DownLoad mode on supported Qualcomm platforms.
 
 Return value
 ------------
-- 
2.34.1

[PATCH v6 5/5] qcom_defconfig: enable psci based sysreset

[Varadarajan Narayanan]

Enable CONFIG_SYSRESET_QCOM_PSCI to allow U-Boot to reset to Emergency
Download mode.

Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v6: Enabled CONFIG_SYSRESET_CMD_RESET_ARGS

v5: Moved from qcs9100_defconfig to qcom_defconfig
---
 configs/qcom_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index fe5880de1fd..64b3f7c4328 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -130,7 +130,9 @@ CONFIG_QCOM_RPMH=y
 CONFIG_SPMI_MSM=y
 CONFIG_SYSINFO=y
 CONFIG_SYSINFO_SMBIOS=y
+CONFIG_SYSRESET_CMD_RESET_ARGS=y
 CONFIG_SYSRESET_QCOM_PSHOLD=y
+CONFIG_SYSRESET_QCOM_PSCI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-- 
2.34.1

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

[Tom Rini]

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

On Wed, Jan 21, 2026 at 12:09:17PM +0530, Varadarajan Narayanan wrote:

> Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
> to receive arguments given to the 'reset' command. Process the
> request_arg() op before the usual request() op.
> 
> Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

Thanks for doing this.

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

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

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

[Simon Glass]

Hi,

On Wed, 21 Jan 2026 at 19:39, Varadarajan Narayanan
<varadarajan.narayanan@oss.qualcomm.com> wrote:
>
> Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
> to receive arguments given to the 'reset' command. Process the
> request_arg() op before the usual request() op.
>
> Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
> v6: Wrap this functionality inside CONFIG_SYSRESET_CMD_RESET_ARGS
> ---
>  drivers/sysreset/Kconfig           |  8 +++++++
>  drivers/sysreset/sysreset-uclass.c | 37 ++++++++++++++++++++++++++++++
>  include/sysreset.h                 | 18 +++++++++++++++
>  3 files changed, 63 insertions(+)
>
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index 0181f6cd581..6fb0ca81dc6 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -49,6 +49,14 @@ config SYSRESET_CMD_RESET
>         help
>           Enable sysreset implementation of the reset command.
>
> +config SYSRESET_CMD_RESET_ARGS
> +       bool "Enable reset command to take arguments"
> +       help
> +         Pass on the arguments received by the 'reset' command to the
> +         sysreset driver(s). The sysreset driver(s) may make use of the
> +         additional arguments for implementing arch/board specific
> +         functionality.
> +

I haven't been following this, but what sort of args are you planning to pass?

Regards,
Simon


>  if CMD_POWEROFF
>
>  config SYSRESET_CMD_POWEROFF
> diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
> index 536ac727142..f25e09e9cd0 100644
> --- a/drivers/sysreset/sysreset-uclass.c
> +++ b/drivers/sysreset/sysreset-uclass.c
> @@ -32,6 +32,18 @@ int sysreset_request(struct udevice *dev, enum sysreset_t type)
>         return ops->request(dev, type);
>  }
>
> +#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
> +int sysreset_request_arg(struct udevice *dev, int argc, char * const argv[])
> +{
> +       struct sysreset_ops *ops = sysreset_get_ops(dev);
> +
> +       if (!ops->request_arg)
> +               return -ENOSYS;
> +
> +       return ops->request_arg(dev, argc, argv);
> +}
> +#endif /* CONFIG_SYSRESET_CMD_RESET_ARGS */
> +
>  int sysreset_get_status(struct udevice *dev, char *buf, int size)
>  {
>         struct sysreset_ops *ops = sysreset_get_ops(dev);
> @@ -71,6 +83,26 @@ int sysreset_walk(enum sysreset_t type)
>         return ret;
>  }
>
> +#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
> +int sysreset_walk_arg(int argc, char * const argv[])
> +{
> +       struct udevice *dev;
> +       int ret = -ENOSYS;
> +
> +       while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
> +               for (uclass_first_device(UCLASS_SYSRESET, &dev);
> +                    dev;
> +                    uclass_next_device(&dev)) {
> +                       ret = sysreset_request_arg(dev, argc, argv);
> +                       if (ret == -EINPROGRESS || ret == -EPROTONOSUPPORT)
> +                               break;
> +               }
> +       }
> +
> +       return ret;
> +}
> +#endif /* CONFIG_SYSRESET_CMD_RESET_ARGS */
> +
>  int sysreset_get_last_walk(void)
>  {
>         struct udevice *dev;
> @@ -132,6 +164,11 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>         printf("resetting ...\n");
>         mdelay(100);
>
> +#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET_ARGS)
> +       if (argc > 1 && sysreset_walk_arg(argc, argv) == -EINPROGRESS)
> +               return 0;
> +#endif
> +
>         sysreset_walk_halt(reset_type);
>
>         return 0;
> diff --git a/include/sysreset.h b/include/sysreset.h
> index ff20abdeed3..d1cc9ebc542 100644
> --- a/include/sysreset.h
> +++ b/include/sysreset.h
> @@ -43,6 +43,24 @@ struct sysreset_ops {
>          * (in which case this method will not actually return)
>          */
>         int (*request)(struct udevice *dev, enum sysreset_t type);
> +
> +       /**
> +        * @request_arg: Reset handler implementations that might need to process
> +        *               arguments given to the 'reset' command.
> +        *
> +        * Note that this function may return before the reset takes effect.
> +        *
> +        * @dev:        Device to be used for system reset
> +        * @argc:       No. of items in @argv
> +        * @argv:       Arguments given to 'reset' command
> +        * Return:
> +        * -EINPROGRESS         if the reset has started and will complete soon
> +        * -EPROTONOSUPPORT     if not supported by this device
> +        * 0                    if the reset has already happened
> +        * (in which case this method will not actually return)
> +        */
> +       int (*request_arg)(struct udevice *dev, int argc, char * const argv[]);
> +
>         /**
>          * @get_status: get printable reset status information
>          *
> --
> 2.34.1
>

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

[Varadarajan Narayanan]

On Mon, Jan 26, 2026 at 06:15:34PM +1300, Simon Glass wrote:
> Hi,
>
> On Wed, 21 Jan 2026 at 19:39, Varadarajan Narayanan
> <varadarajan.narayanan@oss.qualcomm.com> wrote:
> >
> > Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
> > to receive arguments given to the 'reset' command. Process the
> > request_arg() op before the usual request() op.
> >
> > Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> > Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > ---
> > v6: Wrap this functionality inside CONFIG_SYSRESET_CMD_RESET_ARGS
> > ---
> >  drivers/sysreset/Kconfig           |  8 +++++++
> >  drivers/sysreset/sysreset-uclass.c | 37 ++++++++++++++++++++++++++++++
> >  include/sysreset.h                 | 18 +++++++++++++++
> >  3 files changed, 63 insertions(+)
> >
> > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > index 0181f6cd581..6fb0ca81dc6 100644
> > --- a/drivers/sysreset/Kconfig
> > +++ b/drivers/sysreset/Kconfig
> > @@ -49,6 +49,14 @@ config SYSRESET_CMD_RESET
> >         help
> >           Enable sysreset implementation of the reset command.
> >
> > +config SYSRESET_CMD_RESET_ARGS
> > +       bool "Enable reset command to take arguments"
> > +       help
> > +         Pass on the arguments received by the 'reset' command to the
> > +         sysreset driver(s). The sysreset driver(s) may make use of the
> > +         additional arguments for implementing arch/board specific
> > +         functionality.
> > +
>
> 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.

-Varada

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

[Simon Glass]

Hi Varadarajan,

On Tue, 27 Jan 2026 at 17:18, Varadarajan Narayanan
<varadarajan.narayanan@oss.qualcomm.com> wrote:
>
> On Mon, Jan 26, 2026 at 06:15:34PM +1300, Simon Glass wrote:
> > Hi,
> >
> > On Wed, 21 Jan 2026 at 19:39, Varadarajan Narayanan
> > <varadarajan.narayanan@oss.qualcomm.com> wrote:
> > >
> > > Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
> > > to receive arguments given to the 'reset' command. Process the
> > > request_arg() op before the usual request() op.
> > >
> > > Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> > > Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > > ---
> > > v6: Wrap this functionality inside CONFIG_SYSRESET_CMD_RESET_ARGS
> > > ---
> > >  drivers/sysreset/Kconfig           |  8 +++++++
> > >  drivers/sysreset/sysreset-uclass.c | 37 ++++++++++++++++++++++++++++++
> > >  include/sysreset.h                 | 18 +++++++++++++++
> > >  3 files changed, 63 insertions(+)
> > >
> > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > > index 0181f6cd581..6fb0ca81dc6 100644
> > > --- a/drivers/sysreset/Kconfig
> > > +++ b/drivers/sysreset/Kconfig
> > > @@ -49,6 +49,14 @@ config SYSRESET_CMD_RESET
> > >         help
> > >           Enable sysreset implementation of the reset command.
> > >
> > > +config SYSRESET_CMD_RESET_ARGS
> > > +       bool "Enable reset command to take arguments"
> > > +       help
> > > +         Pass on the arguments received by the 'reset' command to the
> > > +         sysreset driver(s). The sysreset driver(s) may make use of the
> > > +         additional arguments for implementing arch/board specific
> > > +         functionality.
> > > +
> >
> > 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.

Regards,
Simon

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

[Varadarajan Narayanan]

On Wed, Feb 04, 2026 at 01:23:05PM +1300, Simon Glass wrote:
> Hi Varadarajan,
>
> On Tue, 27 Jan 2026 at 17:18, Varadarajan Narayanan
> <varadarajan.narayanan@oss.qualcomm.com> wrote:
> >
> > On Mon, Jan 26, 2026 at 06:15:34PM +1300, Simon Glass wrote:
> > > Hi,
> > >
> > > On Wed, 21 Jan 2026 at 19:39, Varadarajan Narayanan
> > > <varadarajan.narayanan@oss.qualcomm.com> wrote:
> > > >
> > > > Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
> > > > to receive arguments given to the 'reset' command. Process the
> > > > request_arg() op before the usual request() op.
> > > >
> > > > Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> > > > Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > > > ---
> > > > v6: Wrap this functionality inside CONFIG_SYSRESET_CMD_RESET_ARGS
> > > > ---
> > > >  drivers/sysreset/Kconfig           |  8 +++++++
> > > >  drivers/sysreset/sysreset-uclass.c | 37 ++++++++++++++++++++++++++++++
> > > >  include/sysreset.h                 | 18 +++++++++++++++
> > > >  3 files changed, 63 insertions(+)
> > > >
> > > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > > > index 0181f6cd581..6fb0ca81dc6 100644
> > > > --- a/drivers/sysreset/Kconfig
> > > > +++ b/drivers/sysreset/Kconfig
> > > > @@ -49,6 +49,14 @@ config SYSRESET_CMD_RESET
> > > >         help
> > > >           Enable sysreset implementation of the reset command.
> > > >
> > > > +config SYSRESET_CMD_RESET_ARGS
> > > > +       bool "Enable reset command to take arguments"
> > > > +       help
> > > > +         Pass on the arguments received by the 'reset' command to the
> > > > +         sysreset driver(s). The sysreset driver(s) may make use of the
> > > > +         additional arguments for implementing arch/board specific
> > > > +         functionality.
> > > > +
> > >
> > > 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]

Thanks
Varada

1 - https://lore.kernel.org/u-boot/20260113103840.1948029-3-varadarajan.narayanan@oss.qualcomm.com/
2 - https://lore.kernel.org/u-boot/20260119170701.GD3416603@bill-the-cat/

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

[Simon Glass]

Hi Varadarajan,

On Fri, 13 Feb 2026 at 02:42, Varadarajan Narayanan
<varadarajan.narayanan@oss.qualcomm.com> wrote:
>
> On Wed, Feb 04, 2026 at 01:23:05PM +1300, Simon Glass wrote:
> > Hi Varadarajan,
> >
> > On Tue, 27 Jan 2026 at 17:18, Varadarajan Narayanan
> > <varadarajan.narayanan@oss.qualcomm.com> wrote:
> > >
> > > On Mon, Jan 26, 2026 at 06:15:34PM +1300, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Wed, 21 Jan 2026 at 19:39, Varadarajan Narayanan
> > > > <varadarajan.narayanan@oss.qualcomm.com> wrote:
> > > > >
> > > > > Add a 'request_arg' op to struct sysreset_ops to enable sysreset drivers
> > > > > to receive arguments given to the 'reset' command. Process the
> > > > > request_arg() op before the usual request() op.
> > > > >
> > > > > Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> > > > > Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > > > > ---
> > > > > v6: Wrap this functionality inside CONFIG_SYSRESET_CMD_RESET_ARGS
> > > > > ---
> > > > >  drivers/sysreset/Kconfig           |  8 +++++++
> > > > >  drivers/sysreset/sysreset-uclass.c | 37 ++++++++++++++++++++++++++++++
> > > > >  include/sysreset.h                 | 18 +++++++++++++++
> > > > >  3 files changed, 63 insertions(+)
> > > > >
> > > > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > > > > index 0181f6cd581..6fb0ca81dc6 100644
> > > > > --- a/drivers/sysreset/Kconfig
> > > > > +++ b/drivers/sysreset/Kconfig
> > > > > @@ -49,6 +49,14 @@ config SYSRESET_CMD_RESET
> > > > >         help
> > > > >           Enable sysreset implementation of the reset command.
> > > > >
> > > > > +config SYSRESET_CMD_RESET_ARGS
> > > > > +       bool "Enable reset command to take arguments"
> > > > > +       help
> > > > > +         Pass on the arguments received by the 'reset' command to the
> > > > > +         sysreset driver(s). The sysreset driver(s) may make use of the
> > > > > +         additional arguments for implementing arch/board specific
> > > > > +         functionality.
> > > > > +
> > > >
> > > > 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.

Regards,
Simon


>
> Thanks
> Varada
>
> 1 - https://lore.kernel.org/u-boot/20260113103840.1948029-3-varadarajan.narayanan@oss.qualcomm.com/
> 2 - https://lore.kernel.org/u-boot/20260119170701.GD3416603@bill-the-cat/

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

[Varadarajan Narayanan]

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.

Thanks
Varada

> > 1 - https://lore.kernel.org/u-boot/20260113103840.1948029-3-varadarajan.narayanan@oss.qualcomm.com/
> > 2 - https://lore.kernel.org/u-boot/20260119170701.GD3416603@bill-the-cat/

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

[Tom Rini]

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

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.
Thanks.

-- 
Tom

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

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

[Simon Glass]

Hi Varadarajan,

On Sun, 15 Feb 2026 at 22:31, Varadarajan Narayanan
<varadarajan.narayanan@oss.qualcomm.com> 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. String arglist is good for the cmdline but not
for programmative code.

Regards,
Simon

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

[Varadarajan Narayanan]

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
> <varadarajan.narayanan@oss.qualcomm.com> 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.

> 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?

Thanks
-Varada

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

[Varadarajan Narayanan]

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.

Thanks
Varada

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

[Simon Glass]

Hi Varadarajan,

On Mon, 16 Feb 2026 at 21:24, Varadarajan Narayanan
<varadarajan.narayanan@oss.qualcomm.com> 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
> > <varadarajan.narayanan@oss.qualcomm.com> 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

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

[Tom Rini]

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

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

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

Re: [PATCH v6 0/5] Implement reset to EDL for qcs9100

[Casey Connolly]

On Wed, 21 Jan 2026 12:09:15 +0530, Varadarajan Narayanan wrote:
> Implement reset to EDL for qcs9100
> 
> Using the 'reboot edl' command in Linux, the platform can reboot to the
> Emergency Download mode. Implement the same for U-Boot.
> 
> v6: * Add r-b Sumit
>     * Wrap the new code inside CONFIG_SYSRESET_CMD_RESET_ARGS
>     * Size change details
> ------------------------
> qcom_qcs9100
> ------------------------
> Building 2 commits for 1 boards (1 thread, 16 jobs per thread)
> 01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
> 07: qcom_defconfig: enable psci based sysreset
>     2    0    0 /2              qcom_qcs9100
> Completed: 2 total built, 2 newly), duration 0:00:25, rate 0.08
> /tmp/qcom_qcs9100/tot/boards.cfg is up to date. Nothing to do.
> Summary of 2 commits for 1 boards (1 thread, 16 jobs per thread)
> 01: Merge tag 'u-boot-imx-master-20260117' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx
> 07: qcom_defconfig: enable psci based sysreset
>    aarch64: (for 1/1 boards) all +145.0 data -40.0 rodata +89.0 text +96.0
>             qcom_qcs9100   : all +145 data -40 rodata +89 text +96
>                u-boot: add: 9/0, grow: 4/0 bytes: 656/0 (656)
>                  function                                   old     new   delta
>                  sysreset_walk_arg                            -     124    +124
>                  _u_boot_list_2_driver_2_qcom_psci_sysreset       -     120    +120
>                  qcom_psci_sysreset_request_arg               -      84     +84
>                  smc_call                                     -      68     +68
>                  do_reset                                   100     160     +60
>                  psci_system_reset2                           -      44     +44
>                  psci_features                                -      44     +44
>                  sysreset_request_arg                         -      32     +32
>                  qcom_psci_sysreset_ops                       -      32     +32
>                  psci_bind                                  188     212     +24
>                  qcom_pshold_ops                             24      32      +8
>                  qcom_psci_sysreset_get_status                -       8      +8
>                  psci_sysreset_ops                           24      32      +8
> (no errors to report)
> 
> [...]

Applied, thanks!

First and last time I use b4 review, the commit shas are wrong but you can find the patches in https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/casey/qcom-main-13Apr2026?ref_type=heads

Apologies


[1/5] arm: psci: Add API to check for support of specific PSCI function
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/a612b3e91439
[2/5] drivers: sysreset: Add sysreset op that can take arguments
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/c74ea771aa53
[3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/9562f10216a6
[4/5] cmd: boot: Add '-edl' option to reset command documentation
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/9db72d4b767f
[5/5] qcom_defconfig: enable psci based sysreset
      https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/929d794c99bd

Best regards,
-- 
// Casey (she/they)

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Quentin Schulz]

Hi Varadarajan, Casey,

On 1/21/26 7:39 AM, Varadarajan Narayanan wrote:
> Implement request_arg() sysreset_op for QCOM SoCs that use
> PSCI to reset to EDL (Emergency Download) mode.
> 
> Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
> v4: * Check if ARM_PSCI_1_1_FN64_SYSTEM_RESET2 is supported before
>        issuing it
> 
> v3: * Move argument handling to a separate function and pass the
>        arguments to the actual handler to process
>      * Drop Qcom specific SYSRESET_EDL from the common enum
> 
> v2: * Update commit message
>      * Elaborate Kconfig help text
>      * Use '-edl' instead of 'edl' for consistency with other arguments of reset
>        command
>      * Remove 'weak' for qcom_psci_sysreset_get_status() and make it static
>      * Mention 'SYSRESET_EDL' is Qcom specific in the enum's comments
> ---
>   drivers/firmware/psci.c               |  4 +++
>   drivers/sysreset/Kconfig              |  6 ++++
>   drivers/sysreset/Makefile             |  1 +
>   drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
>   4 files changed, 56 insertions(+)
>   create mode 100644 drivers/sysreset/sysreset_qcom-psci.c
> 
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index 2e3223e1c32..b6838a244d2 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -186,6 +186,10 @@ static int psci_bind(struct udevice *dev)
>   					 NULL);
>   		if (ret)
>   			pr_debug("PSCI System Reset was not bound.\n");
> +		if (IS_ENABLED(CONFIG_SYSRESET_QCOM_PSCI) &&
> +		    device_bind_driver(dev, "qcom_psci-sysreset",
> +				       "qcom_psci-sysreset", NULL))
> +			pr_debug("QCOM PSCI System Reset was not bound.\n");
>   	}
>   
>   	/* From PSCI v1.0 onward we can discover services through ARM_SMCCC_FEATURE */
> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> index 6fb0ca81dc6..905ad2a7769 100644
> --- a/drivers/sysreset/Kconfig
> +++ b/drivers/sysreset/Kconfig
> @@ -301,6 +301,12 @@ config SYSRESET_RAA215300
>   	help
>   	  Add support for the system reboot via the Renesas RAA215300 PMIC.
>   
> +config SYSRESET_QCOM_PSCI
> +	bool "Support reset to EDL for Qualcomm SoCs via PSCI"
> +	help
> +	  Add support for the reset to EDL (Emergency Download) on Qualcomm
> +	  SoCs via PSCI.
> +
>   config SYSRESET_QCOM_PSHOLD
>   	bool "Support sysreset for Qualcomm SoCs via PSHOLD"
>   	help
> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> index f5c78b25896..8bb1eabd48e 100644
> --- a/drivers/sysreset/Makefile
> +++ b/drivers/sysreset/Makefile
> @@ -30,5 +30,6 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
>   obj-$(CONFIG_$(PHASE_)SYSRESET_AT91) += sysreset_at91.o
>   obj-$(CONFIG_$(PHASE_)SYSRESET_X86) += sysreset_x86.o
>   obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
> +obj-$(CONFIG_SYSRESET_QCOM_PSCI) += sysreset_qcom-psci.o
>   obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
>   obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
> diff --git a/drivers/sysreset/sysreset_qcom-psci.c b/drivers/sysreset/sysreset_qcom-psci.c
> new file mode 100644
> index 00000000000..3627bbf5c82
> --- /dev/null
> +++ b/drivers/sysreset/sysreset_qcom-psci.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Masahiro Yamada <yamada.masahiro@socionext.com>
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <dm.h>
> +#include <sysreset.h>
> +#include <asm/system.h>
> +#include <linux/errno.h>
> +#include <linux/psci.h>
> +#include <asm/psci.h>
> +
> +static int qcom_psci_sysreset_get_status(struct udevice *dev, char *buf, int size)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
> +static int qcom_psci_sysreset_request_arg(struct udevice *dev, int argc,
> +					  char * const argv[])
> +{
> +	if (!strncasecmp(argv[1], "-edl", 4)) {
> +		/* Supported in qcs9100, qcs8300, sc7280, qcs615 */
> +		if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) ==
> +							ARM_PSCI_RET_SUCCESS) {
> +			psci_system_reset2(0, 1);
> +			return -EINPROGRESS;
> +		}
> +		printf("PSCI SYSTEM_RESET2 not supported\n");
> +	}
> +
> +	return -EPROTONOSUPPORT;

I think this is a logic bug.

For reference, what calls this function:

   int sysreset_walk_arg(int argc, char * const argv[])
   {
           struct udevice *dev;
           int ret = -ENOSYS;

           while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
                   for (uclass_first_device(UCLASS_SYSRESET, &dev);
                        dev;
                        uclass_next_device(&dev)) {
                           ret = sysreset_request_arg(dev, argc, argv);
                           if (ret == -EINPROGRESS || ret == 
-EPROTONOSUPPORT)
                                   break;
                   }
           }

           return ret;
   }

The issue is that the first sysreset device implementing the request_arg 
callback will consume the args and return EPROTONOSUPPORT which will 
stop the loop.

Think about multiple sysreset devices, and let's say we have a new 
'-dummy' argument to the reset CLI command, then it'll depend on the 
registration order of the sysreset driver whether the dummy argument 
will be handled by the qcom driver which will return -
EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.

I think we should have a fourth possible return code which is "I don't 
know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel 
for interrupts that aren't for the device this IRQ handler was triggered 
for. Or maybe we should really be using -EPROTONOSUPPORT for that 
meaning and not exit the loop if that's the return code?

Or maybe I misread or misunderstood the code?

Cheers,
Quentin

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Quentin Schulz]

Hi all,

Gentle ping. It'd be nice if we can fix this new API before we have a 
release made with it?

On 5/26/26 3:32 PM, Quentin Schulz wrote:
> Hi Varadarajan, Casey,
> 
> On 1/21/26 7:39 AM, Varadarajan Narayanan wrote:
>> Implement request_arg() sysreset_op for QCOM SoCs that use
>> PSCI to reset to EDL (Emergency Download) mode.
>>
>> Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
>> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>> Signed-off-by: Varadarajan Narayanan 
>> <varadarajan.narayanan@oss.qualcomm.com>
>> ---
>> v4: * Check if ARM_PSCI_1_1_FN64_SYSTEM_RESET2 is supported before
>>        issuing it
>>
>> v3: * Move argument handling to a separate function and pass the
>>        arguments to the actual handler to process
>>      * Drop Qcom specific SYSRESET_EDL from the common enum
>>
>> v2: * Update commit message
>>      * Elaborate Kconfig help text
>>      * Use '-edl' instead of 'edl' for consistency with other 
>> arguments of reset
>>        command
>>      * Remove 'weak' for qcom_psci_sysreset_get_status() and make it 
>> static
>>      * Mention 'SYSRESET_EDL' is Qcom specific in the enum's comments
>> ---
>>   drivers/firmware/psci.c               |  4 +++
>>   drivers/sysreset/Kconfig              |  6 ++++
>>   drivers/sysreset/Makefile             |  1 +
>>   drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
>>   4 files changed, 56 insertions(+)
>>   create mode 100644 drivers/sysreset/sysreset_qcom-psci.c
>>
>> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
>> index 2e3223e1c32..b6838a244d2 100644
>> --- a/drivers/firmware/psci.c
>> +++ b/drivers/firmware/psci.c
>> @@ -186,6 +186,10 @@ static int psci_bind(struct udevice *dev)
>>                        NULL);
>>           if (ret)
>>               pr_debug("PSCI System Reset was not bound.\n");
>> +        if (IS_ENABLED(CONFIG_SYSRESET_QCOM_PSCI) &&
>> +            device_bind_driver(dev, "qcom_psci-sysreset",
>> +                       "qcom_psci-sysreset", NULL))
>> +            pr_debug("QCOM PSCI System Reset was not bound.\n");
>>       }
>>       /* From PSCI v1.0 onward we can discover services through 
>> ARM_SMCCC_FEATURE */
>> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
>> index 6fb0ca81dc6..905ad2a7769 100644
>> --- a/drivers/sysreset/Kconfig
>> +++ b/drivers/sysreset/Kconfig
>> @@ -301,6 +301,12 @@ config SYSRESET_RAA215300
>>       help
>>         Add support for the system reboot via the Renesas RAA215300 PMIC.
>> +config SYSRESET_QCOM_PSCI
>> +    bool "Support reset to EDL for Qualcomm SoCs via PSCI"
>> +    help
>> +      Add support for the reset to EDL (Emergency Download) on Qualcomm
>> +      SoCs via PSCI.
>> +
>>   config SYSRESET_QCOM_PSHOLD
>>       bool "Support sysreset for Qualcomm SoCs via PSHOLD"
>>       help
>> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
>> index f5c78b25896..8bb1eabd48e 100644
>> --- a/drivers/sysreset/Makefile
>> +++ b/drivers/sysreset/Makefile
>> @@ -30,5 +30,6 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
>>   obj-$(CONFIG_$(PHASE_)SYSRESET_AT91) += sysreset_at91.o
>>   obj-$(CONFIG_$(PHASE_)SYSRESET_X86) += sysreset_x86.o
>>   obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
>> +obj-$(CONFIG_SYSRESET_QCOM_PSCI) += sysreset_qcom-psci.o
>>   obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
>>   obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
>> diff --git a/drivers/sysreset/sysreset_qcom-psci.c b/drivers/sysreset/ 
>> sysreset_qcom-psci.c
>> new file mode 100644
>> index 00000000000..3627bbf5c82
>> --- /dev/null
>> +++ b/drivers/sysreset/sysreset_qcom-psci.c
>> @@ -0,0 +1,45 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2017 Masahiro Yamada <yamada.masahiro@socionext.com>
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#include <dm.h>
>> +#include <sysreset.h>
>> +#include <asm/system.h>
>> +#include <linux/errno.h>
>> +#include <linux/psci.h>
>> +#include <asm/psci.h>
>> +
>> +static int qcom_psci_sysreset_get_status(struct udevice *dev, char 
>> *buf, int size)
>> +{
>> +    return -EOPNOTSUPP;
>> +}
>> +
>> +static int qcom_psci_sysreset_request_arg(struct udevice *dev, int argc,
>> +                      char * const argv[])
>> +{
>> +    if (!strncasecmp(argv[1], "-edl", 4)) {
>> +        /* Supported in qcs9100, qcs8300, sc7280, qcs615 */
>> +        if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) ==
>> +                            ARM_PSCI_RET_SUCCESS) {
>> +            psci_system_reset2(0, 1);
>> +            return -EINPROGRESS;
>> +        }
>> +        printf("PSCI SYSTEM_RESET2 not supported\n");
>> +    }
>> +
>> +    return -EPROTONOSUPPORT;
> 
> I think this is a logic bug.
> 
> For reference, what calls this function:
> 
>    int sysreset_walk_arg(int argc, char * const argv[])
>    {
>            struct udevice *dev;
>            int ret = -ENOSYS;
> 
>            while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
>                    for (uclass_first_device(UCLASS_SYSRESET, &dev);
>                         dev;
>                         uclass_next_device(&dev)) {
>                            ret = sysreset_request_arg(dev, argc, argv);
>                            if (ret == -EINPROGRESS || ret == - 
> EPROTONOSUPPORT)
>                                    break;
>                    }
>            }
> 
>            return ret;
>    }
> 
> The issue is that the first sysreset device implementing the request_arg 
> callback will consume the args and return EPROTONOSUPPORT which will 
> stop the loop.
> 
> Think about multiple sysreset devices, and let's say we have a new '- 
> dummy' argument to the reset CLI command, then it'll depend on the 
> registration order of the sysreset driver whether the dummy argument 
> will be handled by the qcom driver which will return -
> EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.
> 
> I think we should have a fourth possible return code which is "I don't 
> know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel 
> for interrupts that aren't for the device this IRQ handler was triggered 
> for. Or maybe we should really be using -EPROTONOSUPPORT for that 
> meaning and not exit the loop if that's the return code?
> 
> Or maybe I misread or misunderstood the code?
> 
> Cheers,
> Quentin

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Tom Rini]

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

On Mon, Jun 08, 2026 at 04:53:23PM +0200, Quentin Schulz wrote:
> Hi all,
> 
> Gentle ping. It'd be nice if we can fix this new API before we have a
> release made with it?
> 
> On 5/26/26 3:32 PM, Quentin Schulz wrote:
> > Hi Varadarajan, Casey,
> > 
> > On 1/21/26 7:39 AM, Varadarajan Narayanan wrote:
> > > Implement request_arg() sysreset_op for QCOM SoCs that use
> > > PSCI to reset to EDL (Emergency Download) mode.
> > > 
> > > Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> > > Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > Signed-off-by: Varadarajan Narayanan
> > > <varadarajan.narayanan@oss.qualcomm.com>
> > > ---
> > > v4: * Check if ARM_PSCI_1_1_FN64_SYSTEM_RESET2 is supported before
> > >        issuing it
> > > 
> > > v3: * Move argument handling to a separate function and pass the
> > >        arguments to the actual handler to process
> > >      * Drop Qcom specific SYSRESET_EDL from the common enum
> > > 
> > > v2: * Update commit message
> > >      * Elaborate Kconfig help text
> > >      * Use '-edl' instead of 'edl' for consistency with other
> > > arguments of reset
> > >        command
> > >      * Remove 'weak' for qcom_psci_sysreset_get_status() and make it
> > > static
> > >      * Mention 'SYSRESET_EDL' is Qcom specific in the enum's comments
> > > ---
> > >   drivers/firmware/psci.c               |  4 +++
> > >   drivers/sysreset/Kconfig              |  6 ++++
> > >   drivers/sysreset/Makefile             |  1 +
> > >   drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
> > >   4 files changed, 56 insertions(+)
> > >   create mode 100644 drivers/sysreset/sysreset_qcom-psci.c
> > > 
> > > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> > > index 2e3223e1c32..b6838a244d2 100644
> > > --- a/drivers/firmware/psci.c
> > > +++ b/drivers/firmware/psci.c
> > > @@ -186,6 +186,10 @@ static int psci_bind(struct udevice *dev)
> > >                        NULL);
> > >           if (ret)
> > >               pr_debug("PSCI System Reset was not bound.\n");
> > > +        if (IS_ENABLED(CONFIG_SYSRESET_QCOM_PSCI) &&
> > > +            device_bind_driver(dev, "qcom_psci-sysreset",
> > > +                       "qcom_psci-sysreset", NULL))
> > > +            pr_debug("QCOM PSCI System Reset was not bound.\n");
> > >       }
> > >       /* From PSCI v1.0 onward we can discover services through
> > > ARM_SMCCC_FEATURE */
> > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > > index 6fb0ca81dc6..905ad2a7769 100644
> > > --- a/drivers/sysreset/Kconfig
> > > +++ b/drivers/sysreset/Kconfig
> > > @@ -301,6 +301,12 @@ config SYSRESET_RAA215300
> > >       help
> > >         Add support for the system reboot via the Renesas RAA215300 PMIC.
> > > +config SYSRESET_QCOM_PSCI
> > > +    bool "Support reset to EDL for Qualcomm SoCs via PSCI"
> > > +    help
> > > +      Add support for the reset to EDL (Emergency Download) on Qualcomm
> > > +      SoCs via PSCI.
> > > +
> > >   config SYSRESET_QCOM_PSHOLD
> > >       bool "Support sysreset for Qualcomm SoCs via PSHOLD"
> > >       help
> > > diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> > > index f5c78b25896..8bb1eabd48e 100644
> > > --- a/drivers/sysreset/Makefile
> > > +++ b/drivers/sysreset/Makefile
> > > @@ -30,5 +30,6 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
> > >   obj-$(CONFIG_$(PHASE_)SYSRESET_AT91) += sysreset_at91.o
> > >   obj-$(CONFIG_$(PHASE_)SYSRESET_X86) += sysreset_x86.o
> > >   obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
> > > +obj-$(CONFIG_SYSRESET_QCOM_PSCI) += sysreset_qcom-psci.o
> > >   obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
> > >   obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
> > > diff --git a/drivers/sysreset/sysreset_qcom-psci.c
> > > b/drivers/sysreset/ sysreset_qcom-psci.c
> > > new file mode 100644
> > > index 00000000000..3627bbf5c82
> > > --- /dev/null
> > > +++ b/drivers/sysreset/sysreset_qcom-psci.c
> > > @@ -0,0 +1,45 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2017 Masahiro Yamada <yamada.masahiro@socionext.com>
> > > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > > + */
> > > +
> > > +#include <dm.h>
> > > +#include <sysreset.h>
> > > +#include <asm/system.h>
> > > +#include <linux/errno.h>
> > > +#include <linux/psci.h>
> > > +#include <asm/psci.h>
> > > +
> > > +static int qcom_psci_sysreset_get_status(struct udevice *dev, char
> > > *buf, int size)
> > > +{
> > > +    return -EOPNOTSUPP;
> > > +}
> > > +
> > > +static int qcom_psci_sysreset_request_arg(struct udevice *dev, int argc,
> > > +                      char * const argv[])
> > > +{
> > > +    if (!strncasecmp(argv[1], "-edl", 4)) {
> > > +        /* Supported in qcs9100, qcs8300, sc7280, qcs615 */
> > > +        if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) ==
> > > +                            ARM_PSCI_RET_SUCCESS) {
> > > +            psci_system_reset2(0, 1);
> > > +            return -EINPROGRESS;
> > > +        }
> > > +        printf("PSCI SYSTEM_RESET2 not supported\n");
> > > +    }
> > > +
> > > +    return -EPROTONOSUPPORT;
> > 
> > I think this is a logic bug.
> > 
> > For reference, what calls this function:
> > 
> >    int sysreset_walk_arg(int argc, char * const argv[])
> >    {
> >            struct udevice *dev;
> >            int ret = -ENOSYS;
> > 
> >            while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
> >                    for (uclass_first_device(UCLASS_SYSRESET, &dev);
> >                         dev;
> >                         uclass_next_device(&dev)) {
> >                            ret = sysreset_request_arg(dev, argc, argv);
> >                            if (ret == -EINPROGRESS || ret == -
> > EPROTONOSUPPORT)
> >                                    break;
> >                    }
> >            }
> > 
> >            return ret;
> >    }
> > 
> > The issue is that the first sysreset device implementing the request_arg
> > callback will consume the args and return EPROTONOSUPPORT which will
> > stop the loop.
> > 
> > Think about multiple sysreset devices, and let's say we have a new '-
> > dummy' argument to the reset CLI command, then it'll depend on the
> > registration order of the sysreset driver whether the dummy argument
> > will be handled by the qcom driver which will return -
> > EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.
> > 
> > I think we should have a fourth possible return code which is "I don't
> > know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel
> > for interrupts that aren't for the device this IRQ handler was triggered
> > for. Or maybe we should really be using -EPROTONOSUPPORT for that
> > meaning and not exit the loop if that's the return code?
> > 
> > Or maybe I misread or misunderstood the code?

Following up here.

-- 
Tom

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

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Quentin Schulz]

On 6/23/26 6:50 PM, Tom Rini wrote:
> On Mon, Jun 08, 2026 at 04:53:23PM +0200, Quentin Schulz wrote:
>> Hi all,
>>
>> Gentle ping. It'd be nice if we can fix this new API before we have a
>> release made with it?
>>
>> On 5/26/26 3:32 PM, Quentin Schulz wrote:
>>> Hi Varadarajan, Casey,
>>>
>>> On 1/21/26 7:39 AM, Varadarajan Narayanan wrote:
>>>> Implement request_arg() sysreset_op for QCOM SoCs that use
>>>> PSCI to reset to EDL (Emergency Download) mode.
>>>>
>>>> Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
>>>> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>> Signed-off-by: Varadarajan Narayanan
>>>> <varadarajan.narayanan@oss.qualcomm.com>
>>>> ---
>>>> v4: * Check if ARM_PSCI_1_1_FN64_SYSTEM_RESET2 is supported before
>>>>         issuing it
>>>>
>>>> v3: * Move argument handling to a separate function and pass the
>>>>         arguments to the actual handler to process
>>>>       * Drop Qcom specific SYSRESET_EDL from the common enum
>>>>
>>>> v2: * Update commit message
>>>>       * Elaborate Kconfig help text
>>>>       * Use '-edl' instead of 'edl' for consistency with other
>>>> arguments of reset
>>>>         command
>>>>       * Remove 'weak' for qcom_psci_sysreset_get_status() and make it
>>>> static
>>>>       * Mention 'SYSRESET_EDL' is Qcom specific in the enum's comments
>>>> ---
>>>>    drivers/firmware/psci.c               |  4 +++
>>>>    drivers/sysreset/Kconfig              |  6 ++++
>>>>    drivers/sysreset/Makefile             |  1 +
>>>>    drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
>>>>    4 files changed, 56 insertions(+)
>>>>    create mode 100644 drivers/sysreset/sysreset_qcom-psci.c
>>>>
>>>> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
>>>> index 2e3223e1c32..b6838a244d2 100644
>>>> --- a/drivers/firmware/psci.c
>>>> +++ b/drivers/firmware/psci.c
>>>> @@ -186,6 +186,10 @@ static int psci_bind(struct udevice *dev)
>>>>                         NULL);
>>>>            if (ret)
>>>>                pr_debug("PSCI System Reset was not bound.\n");
>>>> +        if (IS_ENABLED(CONFIG_SYSRESET_QCOM_PSCI) &&
>>>> +            device_bind_driver(dev, "qcom_psci-sysreset",
>>>> +                       "qcom_psci-sysreset", NULL))
>>>> +            pr_debug("QCOM PSCI System Reset was not bound.\n");
>>>>        }
>>>>        /* From PSCI v1.0 onward we can discover services through
>>>> ARM_SMCCC_FEATURE */
>>>> diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
>>>> index 6fb0ca81dc6..905ad2a7769 100644
>>>> --- a/drivers/sysreset/Kconfig
>>>> +++ b/drivers/sysreset/Kconfig
>>>> @@ -301,6 +301,12 @@ config SYSRESET_RAA215300
>>>>        help
>>>>          Add support for the system reboot via the Renesas RAA215300 PMIC.
>>>> +config SYSRESET_QCOM_PSCI
>>>> +    bool "Support reset to EDL for Qualcomm SoCs via PSCI"
>>>> +    help
>>>> +      Add support for the reset to EDL (Emergency Download) on Qualcomm
>>>> +      SoCs via PSCI.
>>>> +
>>>>    config SYSRESET_QCOM_PSHOLD
>>>>        bool "Support sysreset for Qualcomm SoCs via PSHOLD"
>>>>        help
>>>> diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
>>>> index f5c78b25896..8bb1eabd48e 100644
>>>> --- a/drivers/sysreset/Makefile
>>>> +++ b/drivers/sysreset/Makefile
>>>> @@ -30,5 +30,6 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
>>>>    obj-$(CONFIG_$(PHASE_)SYSRESET_AT91) += sysreset_at91.o
>>>>    obj-$(CONFIG_$(PHASE_)SYSRESET_X86) += sysreset_x86.o
>>>>    obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
>>>> +obj-$(CONFIG_SYSRESET_QCOM_PSCI) += sysreset_qcom-psci.o
>>>>    obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
>>>>    obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
>>>> diff --git a/drivers/sysreset/sysreset_qcom-psci.c
>>>> b/drivers/sysreset/ sysreset_qcom-psci.c
>>>> new file mode 100644
>>>> index 00000000000..3627bbf5c82
>>>> --- /dev/null
>>>> +++ b/drivers/sysreset/sysreset_qcom-psci.c
>>>> @@ -0,0 +1,45 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Copyright (C) 2017 Masahiro Yamada <yamada.masahiro@socionext.com>
>>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>>>> + */
>>>> +
>>>> +#include <dm.h>
>>>> +#include <sysreset.h>
>>>> +#include <asm/system.h>
>>>> +#include <linux/errno.h>
>>>> +#include <linux/psci.h>
>>>> +#include <asm/psci.h>
>>>> +
>>>> +static int qcom_psci_sysreset_get_status(struct udevice *dev, char
>>>> *buf, int size)
>>>> +{
>>>> +    return -EOPNOTSUPP;
>>>> +}
>>>> +
>>>> +static int qcom_psci_sysreset_request_arg(struct udevice *dev, int argc,
>>>> +                      char * const argv[])
>>>> +{
>>>> +    if (!strncasecmp(argv[1], "-edl", 4)) {
>>>> +        /* Supported in qcs9100, qcs8300, sc7280, qcs615 */
>>>> +        if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) ==
>>>> +                            ARM_PSCI_RET_SUCCESS) {
>>>> +            psci_system_reset2(0, 1);
>>>> +            return -EINPROGRESS;
>>>> +        }
>>>> +        printf("PSCI SYSTEM_RESET2 not supported\n");
>>>> +    }
>>>> +
>>>> +    return -EPROTONOSUPPORT;
>>>
>>> I think this is a logic bug.
>>>
>>> For reference, what calls this function:
>>>
>>>     int sysreset_walk_arg(int argc, char * const argv[])
>>>     {
>>>             struct udevice *dev;
>>>             int ret = -ENOSYS;
>>>
>>>             while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
>>>                     for (uclass_first_device(UCLASS_SYSRESET, &dev);
>>>                          dev;
>>>                          uclass_next_device(&dev)) {
>>>                             ret = sysreset_request_arg(dev, argc, argv);
>>>                             if (ret == -EINPROGRESS || ret == -
>>> EPROTONOSUPPORT)
>>>                                     break;
>>>                     }
>>>             }
>>>
>>>             return ret;
>>>     }
>>>
>>> The issue is that the first sysreset device implementing the request_arg
>>> callback will consume the args and return EPROTONOSUPPORT which will
>>> stop the loop.
>>>
>>> Think about multiple sysreset devices, and let's say we have a new '-
>>> dummy' argument to the reset CLI command, then it'll depend on the
>>> registration order of the sysreset driver whether the dummy argument
>>> will be handled by the qcom driver which will return -
>>> EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.
>>>
>>> I think we should have a fourth possible return code which is "I don't
>>> know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel
>>> for interrupts that aren't for the device this IRQ handler was triggered
>>> for. Or maybe we should really be using -EPROTONOSUPPORT for that
>>> meaning and not exit the loop if that's the return code?
>>>
>>> Or maybe I misread or misunderstood the code?
> 
> Following up here.
> 

Do we end up reverting just before the release then?

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Tom Rini]

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

On Thu, Jul 02, 2026 at 07:43:06PM +0200, Quentin Schulz wrote:
> On 6/23/26 6:50 PM, Tom Rini wrote:
> > On Mon, Jun 08, 2026 at 04:53:23PM +0200, Quentin Schulz wrote:
> > > Hi all,
> > > 
> > > Gentle ping. It'd be nice if we can fix this new API before we have a
> > > release made with it?
> > > 
> > > On 5/26/26 3:32 PM, Quentin Schulz wrote:
> > > > Hi Varadarajan, Casey,
> > > > 
> > > > On 1/21/26 7:39 AM, Varadarajan Narayanan wrote:
> > > > > Implement request_arg() sysreset_op for QCOM SoCs that use
> > > > > PSCI to reset to EDL (Emergency Download) mode.
> > > > > 
> > > > > Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
> > > > > Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > Signed-off-by: Varadarajan Narayanan
> > > > > <varadarajan.narayanan@oss.qualcomm.com>
> > > > > ---
> > > > > v4: * Check if ARM_PSCI_1_1_FN64_SYSTEM_RESET2 is supported before
> > > > >         issuing it
> > > > > 
> > > > > v3: * Move argument handling to a separate function and pass the
> > > > >         arguments to the actual handler to process
> > > > >       * Drop Qcom specific SYSRESET_EDL from the common enum
> > > > > 
> > > > > v2: * Update commit message
> > > > >       * Elaborate Kconfig help text
> > > > >       * Use '-edl' instead of 'edl' for consistency with other
> > > > > arguments of reset
> > > > >         command
> > > > >       * Remove 'weak' for qcom_psci_sysreset_get_status() and make it
> > > > > static
> > > > >       * Mention 'SYSRESET_EDL' is Qcom specific in the enum's comments
> > > > > ---
> > > > >    drivers/firmware/psci.c               |  4 +++
> > > > >    drivers/sysreset/Kconfig              |  6 ++++
> > > > >    drivers/sysreset/Makefile             |  1 +
> > > > >    drivers/sysreset/sysreset_qcom-psci.c | 45 +++++++++++++++++++++++++++
> > > > >    4 files changed, 56 insertions(+)
> > > > >    create mode 100644 drivers/sysreset/sysreset_qcom-psci.c
> > > > > 
> > > > > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> > > > > index 2e3223e1c32..b6838a244d2 100644
> > > > > --- a/drivers/firmware/psci.c
> > > > > +++ b/drivers/firmware/psci.c
> > > > > @@ -186,6 +186,10 @@ static int psci_bind(struct udevice *dev)
> > > > >                         NULL);
> > > > >            if (ret)
> > > > >                pr_debug("PSCI System Reset was not bound.\n");
> > > > > +        if (IS_ENABLED(CONFIG_SYSRESET_QCOM_PSCI) &&
> > > > > +            device_bind_driver(dev, "qcom_psci-sysreset",
> > > > > +                       "qcom_psci-sysreset", NULL))
> > > > > +            pr_debug("QCOM PSCI System Reset was not bound.\n");
> > > > >        }
> > > > >        /* From PSCI v1.0 onward we can discover services through
> > > > > ARM_SMCCC_FEATURE */
> > > > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
> > > > > index 6fb0ca81dc6..905ad2a7769 100644
> > > > > --- a/drivers/sysreset/Kconfig
> > > > > +++ b/drivers/sysreset/Kconfig
> > > > > @@ -301,6 +301,12 @@ config SYSRESET_RAA215300
> > > > >        help
> > > > >          Add support for the system reboot via the Renesas RAA215300 PMIC.
> > > > > +config SYSRESET_QCOM_PSCI
> > > > > +    bool "Support reset to EDL for Qualcomm SoCs via PSCI"
> > > > > +    help
> > > > > +      Add support for the reset to EDL (Emergency Download) on Qualcomm
> > > > > +      SoCs via PSCI.
> > > > > +
> > > > >    config SYSRESET_QCOM_PSHOLD
> > > > >        bool "Support sysreset for Qualcomm SoCs via PSHOLD"
> > > > >        help
> > > > > diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
> > > > > index f5c78b25896..8bb1eabd48e 100644
> > > > > --- a/drivers/sysreset/Makefile
> > > > > +++ b/drivers/sysreset/Makefile
> > > > > @@ -30,5 +30,6 @@ obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
> > > > >    obj-$(CONFIG_$(PHASE_)SYSRESET_AT91) += sysreset_at91.o
> > > > >    obj-$(CONFIG_$(PHASE_)SYSRESET_X86) += sysreset_x86.o
> > > > >    obj-$(CONFIG_SYSRESET_RAA215300) += sysreset_raa215300.o
> > > > > +obj-$(CONFIG_SYSRESET_QCOM_PSCI) += sysreset_qcom-psci.o
> > > > >    obj-$(CONFIG_SYSRESET_QCOM_PSHOLD) += sysreset_qcom-pshold.o
> > > > >    obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
> > > > > diff --git a/drivers/sysreset/sysreset_qcom-psci.c
> > > > > b/drivers/sysreset/ sysreset_qcom-psci.c
> > > > > new file mode 100644
> > > > > index 00000000000..3627bbf5c82
> > > > > --- /dev/null
> > > > > +++ b/drivers/sysreset/sysreset_qcom-psci.c
> > > > > @@ -0,0 +1,45 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > +/*
> > > > > + * Copyright (C) 2017 Masahiro Yamada <yamada.masahiro@socionext.com>
> > > > > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > > > > + */
> > > > > +
> > > > > +#include <dm.h>
> > > > > +#include <sysreset.h>
> > > > > +#include <asm/system.h>
> > > > > +#include <linux/errno.h>
> > > > > +#include <linux/psci.h>
> > > > > +#include <asm/psci.h>
> > > > > +
> > > > > +static int qcom_psci_sysreset_get_status(struct udevice *dev, char
> > > > > *buf, int size)
> > > > > +{
> > > > > +    return -EOPNOTSUPP;
> > > > > +}
> > > > > +
> > > > > +static int qcom_psci_sysreset_request_arg(struct udevice *dev, int argc,
> > > > > +                      char * const argv[])
> > > > > +{
> > > > > +    if (!strncasecmp(argv[1], "-edl", 4)) {
> > > > > +        /* Supported in qcs9100, qcs8300, sc7280, qcs615 */
> > > > > +        if (psci_features(ARM_PSCI_1_1_FN64_SYSTEM_RESET2) ==
> > > > > +                            ARM_PSCI_RET_SUCCESS) {
> > > > > +            psci_system_reset2(0, 1);
> > > > > +            return -EINPROGRESS;
> > > > > +        }
> > > > > +        printf("PSCI SYSTEM_RESET2 not supported\n");
> > > > > +    }
> > > > > +
> > > > > +    return -EPROTONOSUPPORT;
> > > > 
> > > > I think this is a logic bug.
> > > > 
> > > > For reference, what calls this function:
> > > > 
> > > >     int sysreset_walk_arg(int argc, char * const argv[])
> > > >     {
> > > >             struct udevice *dev;
> > > >             int ret = -ENOSYS;
> > > > 
> > > >             while (ret != -EINPROGRESS && ret != -EPROTONOSUPPORT) {
> > > >                     for (uclass_first_device(UCLASS_SYSRESET, &dev);
> > > >                          dev;
> > > >                          uclass_next_device(&dev)) {
> > > >                             ret = sysreset_request_arg(dev, argc, argv);
> > > >                             if (ret == -EINPROGRESS || ret == -
> > > > EPROTONOSUPPORT)
> > > >                                     break;
> > > >                     }
> > > >             }
> > > > 
> > > >             return ret;
> > > >     }
> > > > 
> > > > The issue is that the first sysreset device implementing the request_arg
> > > > callback will consume the args and return EPROTONOSUPPORT which will
> > > > stop the loop.
> > > > 
> > > > Think about multiple sysreset devices, and let's say we have a new '-
> > > > dummy' argument to the reset CLI command, then it'll depend on the
> > > > registration order of the sysreset driver whether the dummy argument
> > > > will be handled by the qcom driver which will return -
> > > > EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.
> > > > 
> > > > I think we should have a fourth possible return code which is "I don't
> > > > know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel
> > > > for interrupts that aren't for the device this IRQ handler was triggered
> > > > for. Or maybe we should really be using -EPROTONOSUPPORT for that
> > > > meaning and not exit the loop if that's the return code?
> > > > 
> > > > Or maybe I misread or misunderstood the code?
> > 
> > Following up here.
> > 
> 
> Do we end up reverting just before the release then?

Please send it out, cc everyone, and see if that gets some response?

-- 
Tom

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

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Varadarajan Narayanan]

Quentin Schulz/Tom Rini,

[ . . . ]

> > > > > The issue is that the first sysreset device implementing the request_arg
> > > > > callback will consume the args and return EPROTONOSUPPORT which will
> > > > > stop the loop.
> > > > >
> > > > > Think about multiple sysreset devices, and let's say we have a new '-
> > > > > dummy' argument to the reset CLI command, then it'll depend on the
> > > > > registration order of the sysreset driver whether the dummy argument
> > > > > will be handled by the qcom driver which will return -
> > > > > EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.
> > > > >
> > > > > I think we should have a fourth possible return code which is "I don't
> > > > > know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel
> > > > > for interrupts that aren't for the device this IRQ handler was triggered
> > > > > for. Or maybe we should really be using -EPROTONOSUPPORT for that
> > > > > meaning and not exit the loop if that's the return code?
> > > > >
> > > > > Or maybe I misread or misunderstood the code?
> > >
> > > Following up here.
> > >
> >
> > Do we end up reverting just before the release then?
>
> Please send it out, cc everyone, and see if that gets some response?

Sorry about the delay. Will post a change shortly.

Thanks
Varada

Re: [PATCH v6 3/5] sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

[Varadarajan Narayanan]

On Fri, Jul 03, 2026 at 10:51:37AM +0530, Varadarajan Narayanan wrote:
> Quentin Schulz/Tom Rini,
>
> [ . . . ]
>
> > > > > > The issue is that the first sysreset device implementing the request_arg
> > > > > > callback will consume the args and return EPROTONOSUPPORT which will
> > > > > > stop the loop.
> > > > > >
> > > > > > Think about multiple sysreset devices, and let's say we have a new '-
> > > > > > dummy' argument to the reset CLI command, then it'll depend on the
> > > > > > registration order of the sysreset driver whether the dummy argument
> > > > > > will be handled by the qcom driver which will return -
> > > > > > EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset driver.
> > > > > >
> > > > > > I think we should have a fourth possible return code which is "I don't
> > > > > > know how to handle this argument", e.g. à-la IRQ_NONE in Linux kernel
> > > > > > for interrupts that aren't for the device this IRQ handler was triggered
> > > > > > for. Or maybe we should really be using -EPROTONOSUPPORT for that
> > > > > > meaning and not exit the loop if that's the return code?
> > > > > >
> > > > > > Or maybe I misread or misunderstood the code?
> > > >
> > > > Following up here.
> > > >
> > >
> > > Do we end up reverting just before the release then?
> >
> > Please send it out, cc everyone, and see if that gets some response?
>
> Sorry about the delay. Will post a change shortly.

Please review [1]

Thanks
Varada

1 - https://lore.kernel.org/u-boot/20260703-walk-arg-fix-v1-1-64beca00d7e2@oss.qualcomm.com/