The PSCI SYSTEM_RESET2 call allows vendor firmware to define
additional reset types which could be mapped to the reboot
argument.
User-space should be able to reboot a device into different
operational boot-states supported by underlying bootloader and
firmware. Generally, some HW registers need to be written, based
on which the bootloader and firmware decide the next boot state
of device, after the reset. For example, a requirement on
Qualcomm platforms may state that reboot with "bootloader"
command, should reboot the device into bootloader flashing mode
and reboot with “edl” command, should reboot the device into an
Emergency flashing mode. Setting up such reboots on Qualcomm
devices can be inconsistent across SoC platforms and may require
setting different HW registers, where some of these registers may
not be accessible to HLOS. These knobs evolve over product
generations and require more drivers. PSCI defines a
vendor-specific reset in SYSTEM_RESET2 spec, which enables the
firmware to take care of underlying setting for any such
supported vendor-specific reboot. Qualcomm firmwares are
beginning to support and expose PSCI SYSTEM_RESET2
vendor-specific reset types to simplify driver requirements from
Linux. With such support added in the firmware, we now need a
Linux interface which can make use of the firmware calls for PSCI
vendor-specific resets. This will align such reboot requirement
across platforms and vendors.
The current psci driver supports two types of resets –
SYSTEM_RESET2 Arch warm-reset and SYSTEM_RESET cold-reset. The
patchset introduces the PSCI SYSTEM_RESET2 vendor-specific reset
into the reset path of the psci driver and aligns it to work with
reboot system call - LINUX_REBOOT_CMD_RESTART2, when used along
with a supported string-based command in “*arg”.
The patchset uses reboot-mode based commands, to define the
supported vendor reset-types commands in psci device tree node
and registers these commands with the reboot-mode framework.
The PSCI vendor-specific reset takes two arguments, being,
reset_type and cookie as defined by the spec. To accommodate this
requirement, enhance the reboot-mode framework to support two
32-bit arguments by switching to 64-bit magic values.
Along this line, the patchset also extends the reboot-mode
framework to add a non-device-based registration function, which
will allow drivers to register using device tree node, while
keeping backward compatibility for existing users of reboot-mode.
This will enable psci driver to register for reboot-mode and
implement a write function, which will save the magic and then
use it in psci reset path to make a vendor-specific reset call
into the firmware. In addition, the patchset will expose a sysfs
entry interface within reboot-mode which can be used by userspace
to view the supported reboot-mode commands.
The list of vendor-specific reset commands remains open due to
divergent requirements across vendors, but this can be
streamlined and standardized through dedicated device tree
bindings.
Currently three drivers register with reboot-mode framework -
syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
list of commands currently added across various vendor DTs:
mode-loader
mode-normal
mode-bootloader
mode-charge
mode-fastboot
mode-reboot-ab-update
mode-recovery
mode-rescue
mode-shutdown-thermal
mode-shutdown-thermal-battery
On gs101 we also pass kernel-generated modes from kernel_restart()
or panic(), specifically DM verity's 'dm-verity device corrupted':
mode-dm-verity-device-corrupted = <0x50>;
- thanks Andre' for providing this.
Detailed list of commands being used by syscon-reboot-mode:
arm64/boot/dts/exynos/exynosautov9.dtsi:
mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
arm64/boot/dts/exynos/google/gs101.dtsi:
mode-bootloader = <0xfc>;
mode-charge = <0x0a>;
mode-fastboot = <0xfa>;
mode-reboot-ab-update = <0x52>;
mode-recovery = <0xff>;
mode-rescue = <0xf9>;
mode-shutdown-thermal = <0x51>;
mode-shutdown-thermal-battery = <0x51>;
arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/hisilicon/hi6220-hikey.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/rockchip/px30.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-fastboot = <BOOT_FASTBOOT>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
arm64/boot/dts/rockchip/rk3308.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
mode-fastboot = <BOOT_FASTBOOT>;
arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
mode-normal = <BOOT_NORMAL>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-recovery = <BOOT_RECOVERY>;
mode-bootloader = <BOOT_FASTBOOT>;
Detailed list of commands being used by nvmem-reboot-mode:
arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
mode-recovery = <0x01>;
mode-bootloader = <0x02>;
Previous discussions around SYSTEM_RESET2:
- https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
- https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
Signed-off-by: Elliot Berman <redacted>
Signed-off-by: Shivendra Pratap <redacted>
Changes in v14:
- mode-dm-verity-device-corrupted documented in cover letter -by André
ABI Documentation:
- Updated KernelVersion in ABI documentation to reflect base commit
version. – by André
- Revised ABI documentation to clarify space-separated format for
supported reboot-mode commands. – by André
power: reset: reboot-mode: Expose sysfs patch
- Modified `show_modes` to output a space-separated list of supported
reboot modes – by André
- Added error handling in `create_reboot_mode_device()` to ensure
proper cleanup on failure.
firmware: psci:
- Locate psci/reboot-mode node using psci compatible. - by Krzysztof,
Dmitry, Sudeep.
- Added error handling for additional code for compatible.
- Converted hex values to lowercase for consistency. – by André
- Introduced panic notifier to disable valid vendor-reset flag in
panic path. – by André
- Added check for `psci_system_reset2` before registering vendor reset
commands.
- Updated Commit text.
dts: sa8775p:
- DT file name changed from sa8775p to lemans and commit text updated
accordingly. – for dt renaming in base commit (sa8775p to lemans).
- Link to v13: https://lore.kernel.org/r/20250727-arm-psci-system_reset2-vendor-reboots-v13-0-6b8d23315898@oss.qualcomm.com
Changes in v13:
- Split patch1 into two (Synchronize list traversal and DT node-based
registration) - by Dmitry.
- Move mutex lock inside get_reboot_mode_magic - by Dmitry.
- Reorder the patches – pull patch8 for exposing reboot-mode sysfs before
psci patch - to align the change in reboot-mode sysfs patch.
- Update patch- reboot-mode: Expose sysfs for registered reboot_modes
- Introduce a driver_name in reboot_mode_register. This will be used
in sysfs creation - by Arnd.
- Update documentation and commit text for above.
- Fix release function to properly call delete attr file.
- Fix sparse warning for devres_find.
- Add error handling for devres_find.
- Split ABI documentation as a separate patch and update ABI documentation
for usage of driver-name in sysfs - by Arnd
- Update patch - psci: Implement vendor-specific resets as reboot-mode
- Fix Kconfig for CONFIG related warning.
- Add driver_name as "psci" in register call to reboot-mode - by Arnd
- Link to v12: https://lore.kernel.org/r/20250721-arm-psci-system_reset2-vendor-reboots-v12-0-87bac3ec422e@oss.qualcomm.com
Changes in v12:
- Added lock for list traversals in reboot-mode - by Dmitry.
- Added proper handling for BE and LE cases in reboot-mode - by Dmitry.
- Removed type casting for u64 to u32 conversions. Added limit checks
and used bitwise operations for same - by Andrew.
- Link to v11: https://lore.kernel.org/r/20250717-arm-psci-system_reset2-vendor-reboots-v11-0-df3e2b2183c3@oss.qualcomm.com
Changes in v11:
- Remove reference of cookie in reboot-mode – Arnd/Rob
- Introduce 64-bit magic in reboot-mode to accommodate two 32-bit
arguments – Arnd
- Change reset-type to reboot-mode in psci device tree binding – Arnd
- binding no more mandates two arguments as in v10.
- dt changes done to support this binding.
- Remove obvious comments in psci reset path – Konrad
- Merge sysfs and ABI doc into single patch.
- Fix compilation issue on X86 configs.
- Fix warnings for pr_fmt.
- Link to v10: https://lore.kernel.org/all/569f154d-c714-1714-b898-83a42a38771c@oss.qualcomm.com/
Changes in V10:
- Change in reset-type binding to make cookie as a mandatory
argument.
- Change reboot-mode binding to support additional argument
"cookie".
From Lorenzo:
- Use reboot-mode framework for implementing vendor-resets.
- Modify reboot-mode framework to support two arguments
(magic and cookie).
- Expose sysfs for supported reboot-modes commands.
- List out all existing reboot-mode commands and their users.
- Added this to cover letter.
From Dmitry:
- Modify reboot-mode to support non-device based registration.
- Modify reboot-mode to create a class and device to expose
sysfs interface.
- Link to v9: https://lore.kernel.org/all/20250303-arm-psci-system_reset2-vendor-reboots-v9-0-b2cf4a20feda@oss.qualcomm.com/
Changes in v9:
- Don't fallback to architecturally defined resets from Lorenzo.
- Link to v8: https://lore.kernel.org/r/20241107-arm-psci-system_reset2-vendor-reboots-v8-0-e8715fa65cb5@quicinc.com
Changes in v8:
- Code style nits from Stephen
- Add rb3gen2
- Link to v7: https://lore.kernel.org/r/20241028-arm-psci-system_reset2-vendor-reboots-v7-0-a4c40b0ebc54@quicinc.com
Changes in v7:
- Code style nits from Stephen
- Dropped unnecessary hunk from the sa8775p-ride patch
- Link to v6: https://lore.kernel.org/r/20241018-arm-psci-system_reset2-vendor-reboots-v6-0-50cbe88b0a24@quicinc.com
Changes in v6:
- Rebase to v6.11 and fix trivial conflicts in qcm6490-idp
- Add sa8775p-ride support (same as qcm6490-idp)
- Link to v5: https://lore.kernel.org/r/20240617-arm-psci-system_reset2-vendor-reboots-v5-0-086950f650c8@quicinc.com
Changes in v5:
- Drop the nested "items" in prep for future dtschema tools
- Link to v4: https://lore.kernel.org/r/20240611-arm-psci-system_reset2-vendor-reboots-v4-0-98f55aa74ae8@quicinc.com
Changes in v4:
- Change mode- properties from uint32-matrix to uint32-array
- Restructure the reset-types node so only the restriction is in the
if/then schemas and not the entire definition
- Link to v3: https://lore.kernel.org/r/20240515-arm-psci-system_reset2-vendor-reboots-v3-0-16dd4f9c0ab4@quicinc.com
Changes in v3:
- Limit outer number of items to 1 for mode-* properties
- Move the reboot-mode for psci under a subnode "reset-types"
- Fix the DT node in qcm6490-idp so it doesn't overwrite the one from
sc7820.dtsi
- Link to v2: https://lore.kernel.org/r/20240414-arm-psci-system_reset2-vendor-reboots-v2-0-da9a055a648f@quicinc.com
Changes in v2:
- Fixes to schema as suggested by Rob and Krzysztof
- Add qcm6490 idp as first Qualcomm device to support
- Link to v1: https://lore.kernel.org/r/20231117-arm-psci-system_reset2-vendor-reboots-v1-0-03c4612153e2@quicinc.com
Changes in v1:
- Reference reboot-mode bindings as suggeted by Rob.
- Link to RFC: https://lore.kernel.org/r/20231030-arm-psci-system_reset2-vendor-reboots-v1-0-dcdd63352ad1@quicinc.com
---
Elliot Berman (4):
dt-bindings: arm: Document reboot mode magic
arm64: dts: qcom: qcm6490-idp: Add PSCI SYSTEM_RESET2 types
arm64: dts: qcom: qcs6490-rb3gen2: Add PSCI SYSTEM_RESET2 types
arm64: dts: qcom: lemans-ride: Add PSCI SYSTEM_RESET2 types
Shivendra Pratap (6):
power: reset: reboot-mode: Synchronize list traversal
power: reset: reboot-mode: Add device tree node-based registration
power: reset: reboot-mode: Add support for 64 bit magic
Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes
power: reset: reboot-mode: Expose sysfs for registered reboot_modes
firmware: psci: Implement vendor-specific resets as reboot-mode
.../testing/sysfs-class-reboot-mode-reboot_modes | 39 +++++
Documentation/devicetree/bindings/arm/psci.yaml | 43 +++++
arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi | 7 +
arch/arm64/boot/dts/qcom/lemans.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 7 +
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 +
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
drivers/firmware/psci/Kconfig | 2 +
drivers/firmware/psci/psci.c | 88 +++++++++-
drivers/power/reset/nvmem-reboot-mode.c | 13 +-
drivers/power/reset/qcom-pon.c | 11 +-
drivers/power/reset/reboot-mode.c | 179 +++++++++++++++++----
drivers/power/reset/syscon-reboot-mode.c | 11 +-
include/linux/reboot-mode.h | 11 +-
14 files changed, 378 insertions(+), 44 deletions(-)
---
base-commit: 931e46dcbc7e6035a90e9c4a27a84b660e083f0a
change-id: 20250709-arm-psci-system_reset2-vendor-reboots-46c80044afcf
Best regards,
--
Shivendra Pratap [off-list ref]
List traversals must be synchronized to prevent race conditions
and data corruption. The reboot-mode list is not protected by a
lock currently, which can lead to concurrent access and race.
Introduce a mutex lock to guard all operations on the reboot-mode
list and ensure thread-safe access. The change prevents unsafe
concurrent access on reboot-mode list.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/reboot-mode.c | 24 ++++++++++++++++++++----
include/linux/reboot-mode.h | 4 ++++
2 files changed, 24 insertions(+), 4 deletions(-)
@@ -29,9 +29,14 @@ static unsigned int get_reboot_mode_magic(struct reboot_mode_driver *reboot,if(!cmd)cmd=normal;-list_for_each_entry(info,&reboot->head,list)-if(!strcmp(info->mode,cmd))+mutex_lock(&reboot->rb_lock);+list_for_each_entry(info,&reboot->head,list){+if(!strcmp(info->mode,cmd)){+mutex_unlock(&reboot->rb_lock);returninfo->magic;+}+}+mutex_unlock(&reboot->rb_lock);/* try to match again, replacing characters impossible in DT */if(strscpy(cmd_,cmd,sizeof(cmd_))==-E2BIG)
@@ -41,9 +46,14 @@ static unsigned int get_reboot_mode_magic(struct reboot_mode_driver *reboot,strreplace(cmd_,',','-');strreplace(cmd_,'/','-');-list_for_each_entry(info,&reboot->head,list)-if(!strcmp(info->mode,cmd_))+mutex_lock(&reboot->rb_lock);+list_for_each_entry(info,&reboot->head,list){+if(!strcmp(info->mode,cmd_)){+mutex_unlock(&reboot->rb_lock);returninfo->magic;+}+}+mutex_unlock(&reboot->rb_lock);return0;}
@@ -77,7 +87,9 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)intret;INIT_LIST_HEAD(&reboot->head);+mutex_init(&reboot->rb_lock);+mutex_lock(&reboot->rb_lock);for_each_property_of_node(np,prop){if(strncmp(prop->name,PREFIX,len))continue;
@@ -113,12 +125,14 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)reboot->reboot_notifier.notifier_call=reboot_mode_notify;register_reboot_notifier(&reboot->reboot_notifier);+mutex_unlock(&reboot->rb_lock);return0;error:list_for_each_entry(info,&reboot->head,list)kfree_const(info->mode);+mutex_unlock(&reboot->rb_lock);returnret;}EXPORT_SYMBOL_GPL(reboot_mode_register);
@@ -133,8 +147,10 @@ int reboot_mode_unregister(struct reboot_mode_driver *reboot)unregister_reboot_notifier(&reboot->reboot_notifier);+mutex_lock(&reboot->rb_lock);list_for_each_entry(info,&reboot->head,list)kfree_const(info->mode);+mutex_unlock(&reboot->rb_lock);return0;}
From: Sebastian Reichel <hidden> Date: 2025-09-16 18:45:01
Hi,
On Fri, Aug 15, 2025 at 08:05:06PM +0530, Shivendra Pratap wrote:
List traversals must be synchronized to prevent race conditions
and data corruption. The reboot-mode list is not protected by a
lock currently, which can lead to concurrent access and race.
Introduce a mutex lock to guard all operations on the reboot-mode
list and ensure thread-safe access. The change prevents unsafe
concurrent access on reboot-mode list.
Signed-off-by: Shivendra Pratap <redacted>
---
This should use scoped_guard() and a Fixes: tag. Otherwise LGTM.
Greetings,
-- Sebastian
@@ -29,9 +29,14 @@ static unsigned int get_reboot_mode_magic(struct reboot_mode_driver *reboot,if(!cmd)cmd=normal;-list_for_each_entry(info,&reboot->head,list)-if(!strcmp(info->mode,cmd))+mutex_lock(&reboot->rb_lock);+list_for_each_entry(info,&reboot->head,list){+if(!strcmp(info->mode,cmd)){+mutex_unlock(&reboot->rb_lock);returninfo->magic;+}+}+mutex_unlock(&reboot->rb_lock);/* try to match again, replacing characters impossible in DT */if(strscpy(cmd_,cmd,sizeof(cmd_))==-E2BIG)
@@ -41,9 +46,14 @@ static unsigned int get_reboot_mode_magic(struct reboot_mode_driver *reboot,strreplace(cmd_,',','-');strreplace(cmd_,'/','-');-list_for_each_entry(info,&reboot->head,list)-if(!strcmp(info->mode,cmd_))+mutex_lock(&reboot->rb_lock);+list_for_each_entry(info,&reboot->head,list){+if(!strcmp(info->mode,cmd_)){+mutex_unlock(&reboot->rb_lock);returninfo->magic;+}+}+mutex_unlock(&reboot->rb_lock);return0;}
@@ -77,7 +87,9 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)intret;INIT_LIST_HEAD(&reboot->head);+mutex_init(&reboot->rb_lock);+mutex_lock(&reboot->rb_lock);for_each_property_of_node(np,prop){if(strncmp(prop->name,PREFIX,len))continue;
@@ -113,12 +125,14 @@ int reboot_mode_register(struct reboot_mode_driver *reboot)reboot->reboot_notifier.notifier_call=reboot_mode_notify;register_reboot_notifier(&reboot->reboot_notifier);+mutex_unlock(&reboot->rb_lock);return0;error:list_for_each_entry(info,&reboot->head,list)kfree_const(info->mode);+mutex_unlock(&reboot->rb_lock);returnret;}EXPORT_SYMBOL_GPL(reboot_mode_register);
@@ -133,8 +147,10 @@ int reboot_mode_unregister(struct reboot_mode_driver *reboot)unregister_reboot_notifier(&reboot->reboot_notifier);+mutex_lock(&reboot->rb_lock);list_for_each_entry(info,&reboot->head,list)kfree_const(info->mode);+mutex_unlock(&reboot->rb_lock);return0;}
Hi,
On Fri, Aug 15, 2025 at 08:05:06PM +0530, Shivendra Pratap wrote:
quoted
List traversals must be synchronized to prevent race conditions
and data corruption. The reboot-mode list is not protected by a
lock currently, which can lead to concurrent access and race.
Introduce a mutex lock to guard all operations on the reboot-mode
list and ensure thread-safe access. The change prevents unsafe
concurrent access on reboot-mode list.
Signed-off-by: Shivendra Pratap <redacted>
---
This should use scoped_guard() and a Fixes: tag. Otherwise LGTM.
ACK. Will update this patch based on scoped_guard() and add a Fixes tag.
thanks,
Shivendra
The reboot-mode driver does not have a strict requirement for
device-based registration. It primarily uses the device's of_node
to read mode-<cmd> properties and the device pointer for logging.
Remove the dependency on struct device and introduce support for
Device Tree (DT) node-based registration. This enables drivers
that are not associated with a struct device to leverage the
reboot-mode framework.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/reboot-mode.c | 37 ++++++++++++++++++++++++++-----------
include/linux/reboot-mode.h | 2 +-
2 files changed, 27 insertions(+), 12 deletions(-)
From: Sebastian Reichel <hidden> Date: 2025-09-16 18:49:07
Hi,
On Fri, Aug 15, 2025 at 08:05:07PM +0530, Shivendra Pratap wrote:
The reboot-mode driver does not have a strict requirement for
device-based registration. It primarily uses the device's of_node
to read mode-<cmd> properties and the device pointer for logging.
Remove the dependency on struct device and introduce support for
Device Tree (DT) node-based registration. This enables drivers
that are not associated with a struct device to leverage the
reboot-mode framework.
Signed-off-by: Shivendra Pratap <redacted>
---
Please use fwnode instead of device_node, so that the same thing
can be used with non DT setups, if that becomes necessary. Otherwise
LGTM.
Greetings,
-- Sebastian
Hi,
On Fri, Aug 15, 2025 at 08:05:07PM +0530, Shivendra Pratap wrote:
quoted
The reboot-mode driver does not have a strict requirement for
device-based registration. It primarily uses the device's of_node
to read mode-<cmd> properties and the device pointer for logging.
Remove the dependency on struct device and introduce support for
Device Tree (DT) node-based registration. This enables drivers
that are not associated with a struct device to leverage the
reboot-mode framework.
Signed-off-by: Shivendra Pratap <redacted>
---
Please use fwnode instead of device_node, so that the same thing
can be used with non DT setups, if that becomes necessary. Otherwise
LGTM.
To be more clear on this, have one question: the current unmodified
design of reboot-mode is dt based:
struct device_node *np = reboot->dev->of_node;
and then parses the node using for_each_property_of_node(np, prop).
We want to refactor reboot-mode to support non-DT setups by adding
support for fwnode-based approach (struct fwnode_handle *fwnode)?
Can you please explain a bit? Some more details would be helpful to
make the change.
thanks,
Shivendra
From: Sebastian Reichel <hidden> Date: 2025-09-17 22:32:57
Hi,
On Wed, Sep 17, 2025 at 09:59:44PM +0530, Shivendra Pratap wrote:
On 9/17/2025 12:18 AM, Sebastian Reichel wrote:
quoted
On Fri, Aug 15, 2025 at 08:05:07PM +0530, Shivendra Pratap wrote:
quoted
The reboot-mode driver does not have a strict requirement for
device-based registration. It primarily uses the device's of_node
to read mode-<cmd> properties and the device pointer for logging.
Remove the dependency on struct device and introduce support for
Device Tree (DT) node-based registration. This enables drivers
that are not associated with a struct device to leverage the
reboot-mode framework.
Signed-off-by: Shivendra Pratap <redacted>
---
Please use fwnode instead of device_node, so that the same thing
can be used with non DT setups, if that becomes necessary. Otherwise
LGTM.
To be more clear on this, have one question: the current unmodified
design of reboot-mode is dt based:
struct device_node *np = reboot->dev->of_node;
and then parses the node using for_each_property_of_node(np, prop).
We want to refactor reboot-mode to support non-DT setups by adding
support for fwnode-based approach (struct fwnode_handle *fwnode)?
Can you please explain a bit? Some more details would be helpful to
make the change.
It's fine to keep using of_node internally. But the external API
(include/linux/reboot-mode.h) should use fwnode. Just like the
current external API is not DT specific as it just gets a struct
device. This keeps the external API somewhat ready for non-DT users
and avoids having to change all API users again in the future.
Greetings,
-- Sebastian
Hi,
On Wed, Sep 17, 2025 at 09:59:44PM +0530, Shivendra Pratap wrote:
quoted
On 9/17/2025 12:18 AM, Sebastian Reichel wrote:
quoted
On Fri, Aug 15, 2025 at 08:05:07PM +0530, Shivendra Pratap wrote:
quoted
The reboot-mode driver does not have a strict requirement for
device-based registration. It primarily uses the device's of_node
to read mode-<cmd> properties and the device pointer for logging.
Remove the dependency on struct device and introduce support for
Device Tree (DT) node-based registration. This enables drivers
that are not associated with a struct device to leverage the
reboot-mode framework.
Signed-off-by: Shivendra Pratap <redacted>
---
Please use fwnode instead of device_node, so that the same thing
can be used with non DT setups, if that becomes necessary. Otherwise
LGTM.
To be more clear on this, have one question: the current unmodified
design of reboot-mode is dt based:
struct device_node *np = reboot->dev->of_node;
and then parses the node using for_each_property_of_node(np, prop).
We want to refactor reboot-mode to support non-DT setups by adding
support for fwnode-based approach (struct fwnode_handle *fwnode)?
Can you please explain a bit? Some more details would be helpful to
make the change.
It's fine to keep using of_node internally. But the external API
(include/linux/reboot-mode.h) should use fwnode. Just like the
current external API is not DT specific as it just gets a struct
device. This keeps the external API somewhat ready for non-DT users
and avoids having to change all API users again in the future.
sure. Will check and try to make this change.
thanks,
Shivendra
Current reboot-mode supports a single 32-bit argument for any
supported mode. Some reboot-mode based drivers may require
passing two independent 32-bit arguments during a reboot
sequence, for uses-cases, where a mode requires an additional
argument. Such drivers may not be able to use the reboot-mode
driver. For example, ARM PSCI vendor-specific resets, need two
arguments for its operation – reset_type and cookie, to complete
the reset operation. If a driver wants to implement this
firmware-based reset, it cannot use reboot-mode framework.
Introduce 64-bit magic values in reboot-mode driver to
accommodate dual 32-bit arguments when specified via device tree.
In cases, where no second argument is passed from device tree,
keep the upper 32-bit of magic un-changed(0) to maintain backward
compatibility.
Update the current drivers using reboot-mode for a 64-bit magic
value.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/nvmem-reboot-mode.c | 13 +++++++++----
drivers/power/reset/qcom-pon.c | 11 ++++++++---
drivers/power/reset/reboot-mode.c | 19 +++++++++++++------
drivers/power/reset/syscon-reboot-mode.c | 11 ++++++++---
include/linux/reboot-mode.h | 3 ++-
5 files changed, 40 insertions(+), 17 deletions(-)
Hi Shivendra,
On 15/08/2025 16:35, Shivendra Pratap wrote:
Current reboot-mode supports a single 32-bit argument for any
supported mode. Some reboot-mode based drivers may require
passing two independent 32-bit arguments during a reboot
sequence, for uses-cases, where a mode requires an additional
argument. Such drivers may not be able to use the reboot-mode
driver. For example, ARM PSCI vendor-specific resets, need two
arguments for its operation – reset_type and cookie, to complete
the reset operation. If a driver wants to implement this
firmware-based reset, it cannot use reboot-mode framework.
Introduce 64-bit magic values in reboot-mode driver to
accommodate dual 32-bit arguments when specified via device tree.
In cases, where no second argument is passed from device tree,
keep the upper 32-bit of magic un-changed(0) to maintain backward
compatibility.
How about adding a n_magic_args property to struct reboot_mode_driver?
Then in struct mode_info change magic to be a u32 array of a fixed
length (currently two in-keeping with the DT bindings).
Parsing the DT values then gets simpler (u32_array) and the magic value
can be passed into the ->write() cb as a pointer since all the
reboot_mode drivers already know how big the array is. Unpopulated DT
values would just be 0.
Kind regards,
quoted hunk
Update the current drivers using reboot-mode for a 64-bit magic
value.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/nvmem-reboot-mode.c | 13 +++++++++----
drivers/power/reset/qcom-pon.c | 11 ++++++++---
drivers/power/reset/reboot-mode.c | 19 +++++++++++++------
drivers/power/reset/syscon-reboot-mode.c | 11 ++++++++---
include/linux/reboot-mode.h | 3 ++-
5 files changed, 40 insertions(+), 17 deletions(-)
Hi Shivendra,
On 15/08/2025 16:35, Shivendra Pratap wrote:
quoted
Current reboot-mode supports a single 32-bit argument for any
supported mode. Some reboot-mode based drivers may require
passing two independent 32-bit arguments during a reboot
sequence, for uses-cases, where a mode requires an additional
argument. Such drivers may not be able to use the reboot-mode
driver. For example, ARM PSCI vendor-specific resets, need two
arguments for its operation – reset_type and cookie, to complete
the reset operation. If a driver wants to implement this
firmware-based reset, it cannot use reboot-mode framework.
Introduce 64-bit magic values in reboot-mode driver to
accommodate dual 32-bit arguments when specified via device tree.
In cases, where no second argument is passed from device tree,
keep the upper 32-bit of magic un-changed(0) to maintain backward
compatibility.
How about adding a n_magic_args property to struct reboot_mode_driver?
Then in struct mode_info change magic to be a u32 array of a fixed
length (currently two in-keeping with the DT bindings).
Parsing the DT values then gets simpler (u32_array) and the magic value
can be passed into the ->write() cb as a pointer since all the
reboot_mode drivers already know how big the array is. Unpopulated DT
values would just be 0.
sure. Will convert it to u32 magic[2] and ->write can now pass
"u32*" and can be de-referenced by the using driver.
Could not understand that how we want to use n_magic_args and who shall
set it? Do we statically define it to two for now? or should we skip
n_magic_args for now?
thanks,
Shivendra
Hi Shivendra,
On 15/08/2025 16:35, Shivendra Pratap wrote:
quoted
Current reboot-mode supports a single 32-bit argument for any
supported mode. Some reboot-mode based drivers may require
passing two independent 32-bit arguments during a reboot
sequence, for uses-cases, where a mode requires an additional
argument. Such drivers may not be able to use the reboot-mode
driver. For example, ARM PSCI vendor-specific resets, need two
arguments for its operation – reset_type and cookie, to complete
the reset operation. If a driver wants to implement this
firmware-based reset, it cannot use reboot-mode framework.
Introduce 64-bit magic values in reboot-mode driver to
accommodate dual 32-bit arguments when specified via device tree.
In cases, where no second argument is passed from device tree,
keep the upper 32-bit of magic un-changed(0) to maintain backward
compatibility.
How about adding a n_magic_args property to struct reboot_mode_driver?
Then in struct mode_info change magic to be a u32 array of a fixed
length (currently two in-keeping with the DT bindings).
Arnd/Rob,
As per previous discussion on patch v10, magic and cookie were implemented
as a 64 bit number (64 bit magic).
Need you thoughts that if we should change the magic to 32bit array, as being
suggested in the above comments.
thanks,
Shivendra
Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes,
a read-only sysfs attribute exposing the list of supported
reboot-mode arguments. This file is created by reboot-mode
framework and provides a user-readable interface to query
available reboot-mode arguments.
Signed-off-by: Shivendra Pratap <redacted>
---
.../testing/sysfs-class-reboot-mode-reboot_modes | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
@@ -0,0 +1,39 @@+What: /sys/class/reboot-mode/<driver>/reboot_modes+Date: August 2025+KernelVersion: 6.17.0-rc1+Contact: linux-pm@vger.kernel.org+ Description:+ This interface exposes the reboot-mode arguments+ registered with the reboot-mode framework. It is+ a read-only interface and provides a space+ separated list of reboot-mode arguments supported+ on the current platform.+ Example:+ recovery fastboot bootloader++ The exact sysfs path may vary depending on the+ name of the driver that registers the arguments.+ Example:+ /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes+ /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes+ /sys/class/reboot-mode/qcom-pon/reboot_modes++ The supported arguments can be used by userspace+ to invoke device reset using the reboot() system+ call, with the "argument" as string to "*arg"+ parameter along with LINUX_REBOOT_CMD_RESTART2.+ Example:+ reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,+ LINUX_REBOOT_CMD_RESTART2, "bootloader");++ A driver can expose the supported arguments by+ registering them with the reboot-mode framework+ using the property names that follow the+ mode-<argument> format.+ Example:+ mode-bootloader, mode-recovery.++ This attribute is useful for scripts or initramfs+ logic that need to programmatically determine+ which reboot-mode arguments are valid before+ triggering a reboot.
From: Sebastian Reichel <hidden> Date: 2025-09-16 18:52:42
Hi,
On Fri, Aug 15, 2025 at 08:05:09PM +0530, Shivendra Pratap wrote:
Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes,
a read-only sysfs attribute exposing the list of supported
reboot-mode arguments. This file is created by reboot-mode
framework and provides a user-readable interface to query
available reboot-mode arguments.
Signed-off-by: Shivendra Pratap <redacted>
---
Reviewed-by: Sebastian Reichel <redacted>
-- Sebastian
@@ -0,0 +1,39 @@+What: /sys/class/reboot-mode/<driver>/reboot_modes+Date: August 2025+KernelVersion: 6.17.0-rc1+Contact: linux-pm@vger.kernel.org+ Description:+ This interface exposes the reboot-mode arguments+ registered with the reboot-mode framework. It is+ a read-only interface and provides a space+ separated list of reboot-mode arguments supported+ on the current platform.+ Example:+ recovery fastboot bootloader++ The exact sysfs path may vary depending on the+ name of the driver that registers the arguments.+ Example:+ /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes+ /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes+ /sys/class/reboot-mode/qcom-pon/reboot_modes++ The supported arguments can be used by userspace+ to invoke device reset using the reboot() system+ call, with the "argument" as string to "*arg"+ parameter along with LINUX_REBOOT_CMD_RESTART2.+ Example:+ reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,+ LINUX_REBOOT_CMD_RESTART2, "bootloader");++ A driver can expose the supported arguments by+ registering them with the reboot-mode framework+ using the property names that follow the+ mode-<argument> format.+ Example:+ mode-bootloader, mode-recovery.++ This attribute is useful for scripts or initramfs+ logic that need to programmatically determine+ which reboot-mode arguments are valid before+ triggering a reboot.
Currently, there is no standardized mechanism for userspace to
discover which reboot-modes are supported on a given platform.
This limitation forces tools and scripts to rely on hardcoded
assumptions about the supported reboot-modes.
Create a class 'reboot-mode' and a device under it to expose a
sysfs interface to show the available reboot mode arguments to
userspace.
Provision the register function with an additional parameter to
get an explicit driver_name. Create the device using this
driver_name. For platform drivers, use the driver_name configured
in dev node.
This results in the creation of:
/sys/class/reboot-mode/<driver>/reboot_modes
This read-only sysfs file will exposes the list of supported
reboot modes arguments provided by the driver, enabling userspace
to query the list of arguments.
Align the clean up path to maintain backward compatibility for
existing reboot-mode based drivers.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/reboot-mode.c | 131 +++++++++++++++++++++++++++++++-------
include/linux/reboot-mode.h | 4 +-
2 files changed, 110 insertions(+), 25 deletions(-)
From: Sebastian Reichel <hidden> Date: 2025-09-16 19:03:24
Hi,
On Fri, Aug 15, 2025 at 08:05:10PM +0530, Shivendra Pratap wrote:
quoted hunk
Currently, there is no standardized mechanism for userspace to
discover which reboot-modes are supported on a given platform.
This limitation forces tools and scripts to rely on hardcoded
assumptions about the supported reboot-modes.
Create a class 'reboot-mode' and a device under it to expose a
sysfs interface to show the available reboot mode arguments to
userspace.
Provision the register function with an additional parameter to
get an explicit driver_name. Create the device using this
driver_name. For platform drivers, use the driver_name configured
in dev node.
This results in the creation of:
/sys/class/reboot-mode/<driver>/reboot_modes
This read-only sysfs file will exposes the list of supported
reboot modes arguments provided by the driver, enabling userspace
to query the list of arguments.
Align the clean up path to maintain backward compatibility for
existing reboot-mode based drivers.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/reboot-mode.c | 131 +++++++++++++++++++++++++++++++-------
include/linux/reboot-mode.h | 4 +-
2 files changed, 110 insertions(+), 25 deletions(-)
Hi,
On Fri, Aug 15, 2025 at 08:05:10PM +0530, Shivendra Pratap wrote:
quoted
Currently, there is no standardized mechanism for userspace to
discover which reboot-modes are supported on a given platform.
This limitation forces tools and scripts to rely on hardcoded
assumptions about the supported reboot-modes.
Create a class 'reboot-mode' and a device under it to expose a
sysfs interface to show the available reboot mode arguments to
userspace.
Provision the register function with an additional parameter to
get an explicit driver_name. Create the device using this
driver_name. For platform drivers, use the driver_name configured
in dev node.
This results in the creation of:
/sys/class/reboot-mode/<driver>/reboot_modes
This read-only sysfs file will exposes the list of supported
reboot modes arguments provided by the driver, enabling userspace
to query the list of arguments.
Align the clean up path to maintain backward compatibility for
existing reboot-mode based drivers.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/power/reset/reboot-mode.c | 131 +++++++++++++++++++++++++++++++-------
include/linux/reboot-mode.h | 4 +-
2 files changed, 110 insertions(+), 25 deletions(-)
@@ -98,6 +98,27 @@ properties:[1]Kernel documentation - ARM idle states bindingsDocumentation/devicetree/bindings/cpu/idle-states.yaml+reboot-mode:+type:object+$ref:/schemas/power/reset/reboot-mode.yaml#+unevaluatedProperties:false+properties:+# "mode-normal" is just SYSTEM_RESET+mode-normal:false+patternProperties:+"^mode-.*$":+minItems:1+maxItems:2+description:|+Describes a vendor-specific reset type. The string after "mode-"+maps a reboot mode to the parameters in the PSCI SYSTEM_RESET2 call.++Parameters are named mode-xxx = <type[, cookie]>, where xxx+is the name of the magic reboot mode, type is the lower 31 bits+of the reset_type, and, optionally, the cookie value. If the cookie+is not provided, it is defaulted to zero.+The 31st bit (vendor-resets) will be implicitly set by the driver.+patternProperties:"^power-domain-":$ref:/schemas/power/power-domain.yaml#
SoC vendors have different types of resets which are controlled
through various hardware registers. For instance, Qualcomm SoC
may have a requirement that reboot with “bootloader” command
should reboot the device to bootloader flashing mode and reboot
with “edl” should reboot the device into Emergency flashing mode.
Setting up such reboots on Qualcomm devices can be inconsistent
across SoC platforms and may require setting different HW
registers, where some of these registers may not be accessible to
HLOS. These knobs evolve over product generations and require
more drivers. PSCI spec defines, SYSTEM_RESET2, vendor-specific
reset which can help align this requirement. Add support for PSCI
SYSTEM_RESET2, vendor-specific resets and align the implementation
to allow user-space initiated reboots to trigger these resets.
Implement the PSCI vendor-specific resets by registering to the
reboot-mode framework. As psci init is done at early kernel init,
reboot-mode registration cannot be done at the time of psci init.
This is because reboot-mode creates a “reboot-mode” class for
exposing sysfs, which can fail at early kernel init. To overcome
this, introduce a late_initcall to register PSCI vendor-specific
resets as reboot modes. Implement a reboot-mode write function
that sets reset_type and cookie values during the reboot notifier
callback. Introduce a firmware-based call for SYSTEM_RESET2
vendor-specific reset in the psci_sys_reset path, using
reset_type and cookie if supported by secure firmware. Register a
panic notifier and clear vendor_reset valid status during panic.
This is needed for any kernel panic that occurs post
reboot_notifiers.
By using the above implementation, userspace will be able to issue
such resets using the reboot() system call with the "*arg"
parameter as a string based command. The commands can be defined
in PSCI device tree node under “reboot-mode” and are based on the
reboot-mode based commands.
Signed-off-by: Shivendra Pratap <redacted>
---
drivers/firmware/psci/Kconfig | 2 +
drivers/firmware/psci/psci.c | 88 ++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 89 insertions(+), 1 deletion(-)
From: Elliot Berman <redacted>
Add support for SYSTEM_RESET2 vendor-specific resets in
qcm6490-idp as reboot-modes. Describe the resets: "bootloader"
will cause device to reboot and stop in the bootloader's fastboot
mode. "edl" will cause device to reboot into "emergency download
mode", which permits loading images via the Firehose protocol.
Reviewed-by: Konrad Dybcio <redacted>
Signed-off-by: Elliot Berman <redacted>
Signed-off-by: Shivendra Pratap <redacted>
---
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 7 +++++++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
From: Elliot Berman <redacted>
Add support for SYSTEM_RESET2 vendor-specific resets in
qcs6490-rb3gen2 as reboot-modes. Describe the resets:
"bootloader" will cause device to reboot and stop in the
bootloader's fastboot mode. "edl" will cause device to reboot
into "emergency download mode", which permits loading images via
the Firehose protocol.
Reviewed-by: Konrad Dybcio <redacted>
Signed-off-by: Elliot Berman <redacted>
Signed-off-by: Shivendra Pratap <redacted>
---
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 +++++++
1 file changed, 7 insertions(+)
From: Elliot Berman <redacted>
Add support for SYSTEM_RESET2 vendor-specific resets in
lemans-ride as reboot-modes. Describe the resets:
"bootloader" will cause device to reboot and stop in the
bootloader's fastboot mode. "edl" will cause device to reboot
into "emergency download mode", which permits loading images via
the Firehose protocol.
Reviewed-by: Konrad Dybcio <redacted>
Signed-off-by: Elliot Berman <redacted>
Signed-off-by: Shivendra Pratap <redacted>
---
arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi | 7 +++++++
arch/arm64/boot/dts/qcom/lemans.dtsi | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
The PSCI SYSTEM_RESET2 call allows vendor firmware to define
additional reset types which could be mapped to the reboot
argument.
User-space should be able to reboot a device into different
operational boot-states supported by underlying bootloader and
firmware. Generally, some HW registers need to be written, based
on which the bootloader and firmware decide the next boot state
of device, after the reset. For example, a requirement on
Qualcomm platforms may state that reboot with "bootloader"
command, should reboot the device into bootloader flashing mode
and reboot with “edl” command, should reboot the device into an
Emergency flashing mode. Setting up such reboots on Qualcomm
devices can be inconsistent across SoC platforms and may require
setting different HW registers, where some of these registers may
not be accessible to HLOS. These knobs evolve over product
generations and require more drivers. PSCI defines a
vendor-specific reset in SYSTEM_RESET2 spec, which enables the
firmware to take care of underlying setting for any such
supported vendor-specific reboot. Qualcomm firmwares are
beginning to support and expose PSCI SYSTEM_RESET2
vendor-specific reset types to simplify driver requirements from
Linux. With such support added in the firmware, we now need a
Linux interface which can make use of the firmware calls for PSCI
vendor-specific resets. This will align such reboot requirement
across platforms and vendors.
The current psci driver supports two types of resets –
SYSTEM_RESET2 Arch warm-reset and SYSTEM_RESET cold-reset. The
patchset introduces the PSCI SYSTEM_RESET2 vendor-specific reset
into the reset path of the psci driver and aligns it to work with
reboot system call - LINUX_REBOOT_CMD_RESTART2, when used along
with a supported string-based command in “*arg”.
The patchset uses reboot-mode based commands, to define the
supported vendor reset-types commands in psci device tree node
and registers these commands with the reboot-mode framework.
The PSCI vendor-specific reset takes two arguments, being,
reset_type and cookie as defined by the spec. To accommodate this
requirement, enhance the reboot-mode framework to support two
32-bit arguments by switching to 64-bit magic values.
Along this line, the patchset also extends the reboot-mode
framework to add a non-device-based registration function, which
will allow drivers to register using device tree node, while
keeping backward compatibility for existing users of reboot-mode.
This will enable psci driver to register for reboot-mode and
implement a write function, which will save the magic and then
use it in psci reset path to make a vendor-specific reset call
into the firmware. In addition, the patchset will expose a sysfs
entry interface within reboot-mode which can be used by userspace
to view the supported reboot-mode commands.
The list of vendor-specific reset commands remains open due to
divergent requirements across vendors, but this can be
streamlined and standardized through dedicated device tree
bindings.
Currently three drivers register with reboot-mode framework -
syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
list of commands currently added across various vendor DTs:
mode-loader
mode-normal
mode-bootloader
mode-charge
mode-fastboot
mode-reboot-ab-update
mode-recovery
mode-rescue
mode-shutdown-thermal
mode-shutdown-thermal-battery
On gs101 we also pass kernel-generated modes from kernel_restart()
or panic(), specifically DM verity's 'dm-verity device corrupted':
mode-dm-verity-device-corrupted = <0x50>;
- thanks Andre' for providing this.
Detailed list of commands being used by syscon-reboot-mode:
arm64/boot/dts/exynos/exynosautov9.dtsi:
mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
arm64/boot/dts/exynos/google/gs101.dtsi:
mode-bootloader = <0xfc>;
mode-charge = <0x0a>;
mode-fastboot = <0xfa>;
mode-reboot-ab-update = <0x52>;
mode-recovery = <0xff>;
mode-rescue = <0xf9>;
mode-shutdown-thermal = <0x51>;
mode-shutdown-thermal-battery = <0x51>;
arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/hisilicon/hi6220-hikey.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/rockchip/px30.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-fastboot = <BOOT_FASTBOOT>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
arm64/boot/dts/rockchip/rk3308.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
mode-fastboot = <BOOT_FASTBOOT>;
arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
mode-normal = <BOOT_NORMAL>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-recovery = <BOOT_RECOVERY>;
mode-bootloader = <BOOT_FASTBOOT>;
Detailed list of commands being used by nvmem-reboot-mode:
arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
mode-recovery = <0x01>;
mode-bootloader = <0x02>;
Previous discussions around SYSTEM_RESET2:
- https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
- https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
Signed-off-by: Elliot Berman <redacted>
Signed-off-by: Shivendra Pratap <redacted>
On ARCH_BRCMSTB:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Thanks!
--
Florian
The PSCI SYSTEM_RESET2 call allows vendor firmware to define
additional reset types which could be mapped to the reboot
argument.
User-space should be able to reboot a device into different
operational boot-states supported by underlying bootloader and
firmware. Generally, some HW registers need to be written, based
on which the bootloader and firmware decide the next boot state
of device, after the reset. For example, a requirement on
Qualcomm platforms may state that reboot with "bootloader"
command, should reboot the device into bootloader flashing mode
and reboot with “edl” command, should reboot the device into an
Emergency flashing mode. Setting up such reboots on Qualcomm
devices can be inconsistent across SoC platforms and may require
setting different HW registers, where some of these registers may
not be accessible to HLOS. These knobs evolve over product
generations and require more drivers. PSCI defines a
vendor-specific reset in SYSTEM_RESET2 spec, which enables the
firmware to take care of underlying setting for any such
supported vendor-specific reboot. Qualcomm firmwares are
beginning to support and expose PSCI SYSTEM_RESET2
vendor-specific reset types to simplify driver requirements from
Linux. With such support added in the firmware, we now need a
Linux interface which can make use of the firmware calls for PSCI
vendor-specific resets. This will align such reboot requirement
across platforms and vendors.
The current psci driver supports two types of resets –
SYSTEM_RESET2 Arch warm-reset and SYSTEM_RESET cold-reset. The
patchset introduces the PSCI SYSTEM_RESET2 vendor-specific reset
into the reset path of the psci driver and aligns it to work with
reboot system call - LINUX_REBOOT_CMD_RESTART2, when used along
with a supported string-based command in “*arg”.
The patchset uses reboot-mode based commands, to define the
supported vendor reset-types commands in psci device tree node
and registers these commands with the reboot-mode framework.
The PSCI vendor-specific reset takes two arguments, being,
reset_type and cookie as defined by the spec. To accommodate this
requirement, enhance the reboot-mode framework to support two
32-bit arguments by switching to 64-bit magic values.
Along this line, the patchset also extends the reboot-mode
framework to add a non-device-based registration function, which
will allow drivers to register using device tree node, while
keeping backward compatibility for existing users of reboot-mode.
This will enable psci driver to register for reboot-mode and
implement a write function, which will save the magic and then
use it in psci reset path to make a vendor-specific reset call
into the firmware. In addition, the patchset will expose a sysfs
entry interface within reboot-mode which can be used by userspace
to view the supported reboot-mode commands.
The list of vendor-specific reset commands remains open due to
divergent requirements across vendors, but this can be
streamlined and standardized through dedicated device tree
bindings.
Currently three drivers register with reboot-mode framework -
syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
list of commands currently added across various vendor DTs:
mode-loader
mode-normal
mode-bootloader
mode-charge
mode-fastboot
mode-reboot-ab-update
mode-recovery
mode-rescue
mode-shutdown-thermal
mode-shutdown-thermal-battery
On gs101 we also pass kernel-generated modes from kernel_restart()
or panic(), specifically DM verity's 'dm-verity device corrupted':
mode-dm-verity-device-corrupted = <0x50>;
- thanks Andre' for providing this.
Detailed list of commands being used by syscon-reboot-mode:
arm64/boot/dts/exynos/exynosautov9.dtsi:
mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
arm64/boot/dts/exynos/google/gs101.dtsi:
mode-bootloader = <0xfc>;
mode-charge = <0x0a>;
mode-fastboot = <0xfa>;
mode-reboot-ab-update = <0x52>;
mode-recovery = <0xff>;
mode-rescue = <0xf9>;
mode-shutdown-thermal = <0x51>;
mode-shutdown-thermal-battery = <0x51>;
arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/hisilicon/hi6220-hikey.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/rockchip/px30.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-fastboot = <BOOT_FASTBOOT>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
arm64/boot/dts/rockchip/rk3308.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
mode-fastboot = <BOOT_FASTBOOT>;
arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
mode-normal = <BOOT_NORMAL>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-recovery = <BOOT_RECOVERY>;
mode-bootloader = <BOOT_FASTBOOT>;
Detailed list of commands being used by nvmem-reboot-mode:
arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
mode-recovery = <0x01>;
mode-bootloader = <0x02>;
Previous discussions around SYSTEM_RESET2:
-https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
-https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
Signed-off-by: Elliot Berman<redacted>
Signed-off-by: Shivendra Pratap<redacted>
With this series, 'edl' mode is working fine in QCOM's IPQ5424 SoC. So
Tested-by: Kathiravan Thirumoorthy
[off-list ref] # IPQ5424-RDP466
On 8/28/2025 1:35 PM, Kathiravan Thirumoorthy wrote:
On 8/15/2025 8:05 PM, Shivendra Pratap wrote:
quoted
The PSCI SYSTEM_RESET2 call allows vendor firmware to define
additional reset types which could be mapped to the reboot
argument.
User-space should be able to reboot a device into different
operational boot-states supported by underlying bootloader and
firmware. Generally, some HW registers need to be written, based
on which the bootloader and firmware decide the next boot state
of device, after the reset. For example, a requirement on
Qualcomm platforms may state that reboot with "bootloader"
command, should reboot the device into bootloader flashing mode
and reboot with “edl” command, should reboot the device into an
Emergency flashing mode. Setting up such reboots on Qualcomm
devices can be inconsistent across SoC platforms and may require
setting different HW registers, where some of these registers may
not be accessible to HLOS. These knobs evolve over product
generations and require more drivers. PSCI defines a
vendor-specific reset in SYSTEM_RESET2 spec, which enables the
firmware to take care of underlying setting for any such
supported vendor-specific reboot. Qualcomm firmwares are
beginning to support and expose PSCI SYSTEM_RESET2
vendor-specific reset types to simplify driver requirements from
Linux. With such support added in the firmware, we now need a
Linux interface which can make use of the firmware calls for PSCI
vendor-specific resets. This will align such reboot requirement
across platforms and vendors.
The current psci driver supports two types of resets –
SYSTEM_RESET2 Arch warm-reset and SYSTEM_RESET cold-reset. The
patchset introduces the PSCI SYSTEM_RESET2 vendor-specific reset
into the reset path of the psci driver and aligns it to work with
reboot system call - LINUX_REBOOT_CMD_RESTART2, when used along
with a supported string-based command in “*arg”.
The patchset uses reboot-mode based commands, to define the
supported vendor reset-types commands in psci device tree node
and registers these commands with the reboot-mode framework.
The PSCI vendor-specific reset takes two arguments, being,
reset_type and cookie as defined by the spec. To accommodate this
requirement, enhance the reboot-mode framework to support two
32-bit arguments by switching to 64-bit magic values.
Along this line, the patchset also extends the reboot-mode
framework to add a non-device-based registration function, which
will allow drivers to register using device tree node, while
keeping backward compatibility for existing users of reboot-mode.
This will enable psci driver to register for reboot-mode and
implement a write function, which will save the magic and then
use it in psci reset path to make a vendor-specific reset call
into the firmware. In addition, the patchset will expose a sysfs
entry interface within reboot-mode which can be used by userspace
to view the supported reboot-mode commands.
The list of vendor-specific reset commands remains open due to
divergent requirements across vendors, but this can be
streamlined and standardized through dedicated device tree
bindings.
Currently three drivers register with reboot-mode framework -
syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
list of commands currently added across various vendor DTs:
mode-loader
mode-normal
mode-bootloader
mode-charge
mode-fastboot
mode-reboot-ab-update
mode-recovery
mode-rescue
mode-shutdown-thermal
mode-shutdown-thermal-battery
On gs101 we also pass kernel-generated modes from kernel_restart()
or panic(), specifically DM verity's 'dm-verity device corrupted':
mode-dm-verity-device-corrupted = <0x50>;
- thanks Andre' for providing this.
Detailed list of commands being used by syscon-reboot-mode:
arm64/boot/dts/exynos/exynosautov9.dtsi:
mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
arm64/boot/dts/exynos/google/gs101.dtsi:
mode-bootloader = <0xfc>;
mode-charge = <0x0a>;
mode-fastboot = <0xfa>;
mode-reboot-ab-update = <0x52>;
mode-recovery = <0xff>;
mode-rescue = <0xf9>;
mode-shutdown-thermal = <0x51>;
mode-shutdown-thermal-battery = <0x51>;
arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/hisilicon/hi6220-hikey.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/rockchip/px30.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-fastboot = <BOOT_FASTBOOT>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
arm64/boot/dts/rockchip/rk3308.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
mode-fastboot = <BOOT_FASTBOOT>;
arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
mode-normal = <BOOT_NORMAL>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-recovery = <BOOT_RECOVERY>;
mode-bootloader = <BOOT_FASTBOOT>;
Detailed list of commands being used by nvmem-reboot-mode:
arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
mode-recovery = <0x01>;
mode-bootloader = <0x02>;
Previous discussions around SYSTEM_RESET2:
-https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
-https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
Signed-off-by: Elliot Berman<redacted>
Signed-off-by: Shivendra Pratap<redacted>
With this series, 'edl' mode is working fine in QCOM's IPQ5424 SoC. So
Tested-by: Kathiravan Thirumoorthy <redacted> # IPQ5424-RDP466
Thanks for giving time for testing this series for IPQ5424. So we have PSCI SYS reset2 support for
IPQ5424 firmware? and did we make any extra changes in DT for edl mode?
thanks,
Shivendra
On 8/28/2025 1:35 PM, Kathiravan Thirumoorthy wrote:
quoted
On 8/15/2025 8:05 PM, Shivendra Pratap wrote:
quoted
The PSCI SYSTEM_RESET2 call allows vendor firmware to define
additional reset types which could be mapped to the reboot
argument.
User-space should be able to reboot a device into different
operational boot-states supported by underlying bootloader and
firmware. Generally, some HW registers need to be written, based
on which the bootloader and firmware decide the next boot state
of device, after the reset. For example, a requirement on
Qualcomm platforms may state that reboot with "bootloader"
command, should reboot the device into bootloader flashing mode
and reboot with “edl” command, should reboot the device into an
Emergency flashing mode. Setting up such reboots on Qualcomm
devices can be inconsistent across SoC platforms and may require
setting different HW registers, where some of these registers may
not be accessible to HLOS. These knobs evolve over product
generations and require more drivers. PSCI defines a
vendor-specific reset in SYSTEM_RESET2 spec, which enables the
firmware to take care of underlying setting for any such
supported vendor-specific reboot. Qualcomm firmwares are
beginning to support and expose PSCI SYSTEM_RESET2
vendor-specific reset types to simplify driver requirements from
Linux. With such support added in the firmware, we now need a
Linux interface which can make use of the firmware calls for PSCI
vendor-specific resets. This will align such reboot requirement
across platforms and vendors.
The current psci driver supports two types of resets –
SYSTEM_RESET2 Arch warm-reset and SYSTEM_RESET cold-reset. The
patchset introduces the PSCI SYSTEM_RESET2 vendor-specific reset
into the reset path of the psci driver and aligns it to work with
reboot system call - LINUX_REBOOT_CMD_RESTART2, when used along
with a supported string-based command in “*arg”.
The patchset uses reboot-mode based commands, to define the
supported vendor reset-types commands in psci device tree node
and registers these commands with the reboot-mode framework.
The PSCI vendor-specific reset takes two arguments, being,
reset_type and cookie as defined by the spec. To accommodate this
requirement, enhance the reboot-mode framework to support two
32-bit arguments by switching to 64-bit magic values.
Along this line, the patchset also extends the reboot-mode
framework to add a non-device-based registration function, which
will allow drivers to register using device tree node, while
keeping backward compatibility for existing users of reboot-mode.
This will enable psci driver to register for reboot-mode and
implement a write function, which will save the magic and then
use it in psci reset path to make a vendor-specific reset call
into the firmware. In addition, the patchset will expose a sysfs
entry interface within reboot-mode which can be used by userspace
to view the supported reboot-mode commands.
The list of vendor-specific reset commands remains open due to
divergent requirements across vendors, but this can be
streamlined and standardized through dedicated device tree
bindings.
Currently three drivers register with reboot-mode framework -
syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
list of commands currently added across various vendor DTs:
mode-loader
mode-normal
mode-bootloader
mode-charge
mode-fastboot
mode-reboot-ab-update
mode-recovery
mode-rescue
mode-shutdown-thermal
mode-shutdown-thermal-battery
On gs101 we also pass kernel-generated modes from kernel_restart()
or panic(), specifically DM verity's 'dm-verity device corrupted':
mode-dm-verity-device-corrupted = <0x50>;
- thanks Andre' for providing this.
Detailed list of commands being used by syscon-reboot-mode:
arm64/boot/dts/exynos/exynosautov9.dtsi:
mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
arm64/boot/dts/exynos/google/gs101.dtsi:
mode-bootloader = <0xfc>;
mode-charge = <0x0a>;
mode-fastboot = <0xfa>;
mode-reboot-ab-update = <0x52>;
mode-recovery = <0xff>;
mode-rescue = <0xf9>;
mode-shutdown-thermal = <0x51>;
mode-shutdown-thermal-battery = <0x51>;
arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/hisilicon/hi6220-hikey.dts:
mode-normal = <0x77665501>;
mode-bootloader = <0x77665500>;
mode-recovery = <0x77665502>;
arm64/boot/dts/rockchip/px30.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-fastboot = <BOOT_FASTBOOT>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
arm64/boot/dts/rockchip/rk3308.dtsi:
mode-bootloader = <BOOT_BL_DOWNLOAD>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-normal = <BOOT_NORMAL>;
mode-recovery = <BOOT_RECOVERY>;
mode-fastboot = <BOOT_FASTBOOT>;
arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
mode-normal = <BOOT_NORMAL>;
mode-loader = <BOOT_BL_DOWNLOAD>;
mode-recovery = <BOOT_RECOVERY>;
mode-bootloader = <BOOT_FASTBOOT>;
Detailed list of commands being used by nvmem-reboot-mode:
arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
mode-recovery = <0x01>;
mode-bootloader = <0x02>;
Previous discussions around SYSTEM_RESET2:
-https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
-https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
Signed-off-by: Elliot Berman<redacted>
Signed-off-by: Shivendra Pratap<redacted>
With this series, 'edl' mode is working fine in QCOM's IPQ5424 SoC. So
Tested-by: Kathiravan Thirumoorthy <redacted> # IPQ5424-RDP466
Thanks for giving time for testing this series for IPQ5424. So we have PSCI SYS reset2 support for
IPQ5424 firmware?
Yeah, the latest IPQ5424 firmware (To be specific -
TZ.WIN_WC.1.0-00043-IPQ5424MAPAANAZT-1 onwards) supports PSCI SYS RESET2.
and did we make any extra changes in DT for edl mode?