.../testing/sysfs-class-reboot-mode-reboot_modes | 39 ++++++ Documentation/devicetree/bindings/arm/psci.yaml | 41 ++++++ .../bindings/power/reset/reboot-mode.yaml | 12 +- arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 7 ++ arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 ++ arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 7 ++ arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +- drivers/firmware/psci/Kconfig | 1 + drivers/firmware/psci/psci.c | 53 +++++++- drivers/power/reset/reboot-mode.c | 140 +++++++++++++++++---- include/linux/reboot-mode.h | 5 +- 12 files changed, 280 insertions(+), 36 deletions(-)
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. As the
vendor-specific reset needs two arguments reset_type and cookie
to be passes to the firmware, enhance the reboot-mode framework
to support two arguments (magic and cookie), for each reboot-mode
command, where cookie will be optional.
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 DT 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_with_cookie function which will save the
magic(reset_type) and cookie 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
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 <quic_eberman@quicinc.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@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: sa8775p-ride: Add PSCI SYSTEM_RESET2 types
Shivendra Pratap (6):
power: reset: reboot-mode: Add device tree node-based registration
dt-bindings: power: reset: Document reboot-mode cookie
power: reset: reboot-mode: Add optional cookie argument
firmware: psci: Implement vendor-specific reset-types as reboot-mode
Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes
power: reset: reboot-mode: Expose sysfs for registered arguments
.../testing/sysfs-class-reboot-mode-reboot_modes | 39 ++++++
Documentation/devicetree/bindings/arm/psci.yaml | 41 ++++++
.../bindings/power/reset/reboot-mode.yaml | 12 +-
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 7 ++
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 ++
arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 7 ++
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
drivers/firmware/psci/Kconfig | 1 +
drivers/firmware/psci/psci.c | 53 +++++++-
drivers/power/reset/reboot-mode.c | 140 +++++++++++++++++----
include/linux/reboot-mode.h | 5 +-
12 files changed, 280 insertions(+), 36 deletions(-)
---
base-commit: 58ba80c4740212c29a1cf9b48f588e60a7612209
change-id: 20250709-arm-psci-system_reset2-vendor-reboots-46c80044afcf
Best regards,
--
Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
On 7/10/25 02:15, Shivendra Pratap wrote:
> 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. As the
> vendor-specific reset needs two arguments reset_type and cookie
> to be passes to the firmware, enhance the reboot-mode framework
> to support two arguments (magic and cookie), for each reboot-mode
> command, where cookie will be optional.
>
> 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 DT 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_with_cookie function which will save the
> magic(reset_type) and cookie 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
>
> 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 <quic_eberman@quicinc.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Humm, something changed compared to the last version that I tested from
Elliot which worked ok. With this patch applied and the following Device
Tree snippet:
psci {
method = "smc";
compatible = "arm,psci-0.2", "arm,psci";
cpu_on = <0xc4000003>;
cpu_suspend = <0xc4000001>;
cpu_off = <0x84000002>;
reset-types {
mode-powercycle = <0x01>;
};
};
I get the following invoking "reboot powercycle":
# reboot powercycle
[ 21.403188] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000 is not a phandle reference
[ 21.412032] Mem abort info:extended_property):
/rdb/waketimer@841a840:interrupts-extended: cell 0 is not a phandle
reference
[ 21.414840] ESR = 0x0000000086000004operty):
/rdb/waketimer@841a840:interrupts-extended: cell 2 is not a phandle
reference
[ 21.418601] EC = 0x21: IABT (current EL), IL = 32 bitsparent: cell
0 is not a phandle reference
[ 21.423927] SET = 0, FnV = 0: /rdb/xhci_v2@8d00000:phys: cell 0 is
not a phandle reference
[ 21.426988] EA = 0, S1PTW = 0 /rdb/sata@8b0a000/sata-port@0:phys:
cell 0 is not a phandle reference
[ 21.430138] FSC = 0x04: level 0 translation fault:phys: cell 0 is
not a phandle reference
[ 21.435054] user pgtable: 4k pages, 48-bit VAs, pgdp=000000010112c000
a phandle reference
[ 21.441508] [0000000000000000] pgd=0000000000000000,
p4d=0000000000000000handle reference
[ 21.448318] Internal error: Oops: 0000000086000004 [#1] SMPcell 0 is
not a phandle reference
[ 21.453990] Modules linked in: bdc
udc_core/thermal-zones/cpu-thermal:thermal-sensors: cell 0 is not a
phandle reference
[ 21.458188] CPU: 0 UID: 0 PID: 1566 Comm: reboot Not tainted
6.16.0-rc5-next-20250710-gdd78270edd5a #2 NONE 4)
[ 21.468032] Hardware name: BCX972160DV (DT)ases property name must
include only lowercase and '-'
[ 21.472221] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)only lowercase and '-'
[ 21.479193] pc : 0x0s_paths): /aliases:pcie0: aliases property is not
a valid node (/pcie@8b10000)
[ 21.481388] lr : reboot_mode_notify+0x64/0x80es property name must
include only lowercase and '-'
[ 21.485760] sp : ffff80008344bbe0iases: aliases property name must
include only lowercase and '-'
[ 21.489079] x29: ffff80008344bbe0 x28: ffff0000c3bb3d00 x27:
ffff800080ab58e8ly lowercase and '-'
[ 21.496228] x26: 0000000000000000 x25: ffff0000c3bb3d00 x24:
ffff800082cf9bc8ly lowercase and '-'
[ 21.503376] x23: ffff80008344bcb8 x22: 0000000000000001 x21:
ffff0000c31b87b0
[ 21.510524] x20: 00000000fffffffc x19: ffff0000c31b8780 x18:
0000000000000000
[ 21.517673] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
[ 21.524821] x14: 0000000000000000 x13: 0000000000000000 x12:
0000000000000000
[ 21.531969] x11: 0000000000000000 x10: 00007fffc02bb958 x9 :
0000000000000010
[ 21.539118] x8 : 0101010101010101 x7 : 0000000000000000 x6 :
000080c38080ffff
[ 21.546266] x5 : ffff0000c3000000 x4 : 0000808000800000 x3 :
0000000000000000
[ 21.553415] x2 : 0000000000000000 x1 : 0000000000000001 x0 :
ffff0000c31b8780
[ 21.560565] Call trace:
[ 21.563014] 0x0 (P)
[ 21.565205] notifier_call_chain+0x70/0x120
[ 21.569401] blocking_notifier_call_chain+0x4c/0x78
[ 21.574288] kernel_restart+0x30/0xc8
[ 21.577957] __do_sys_reboot+0x1c8/0x268
[ 21.581886] __arm64_sys_reboot+0x28/0x38
[ 21.585902] invoke_syscall+0x4c/0x118
[ 21.589660] el0_svc_common.constprop.0+0x44/0xe8
[ 21.594373] do_el0_svc+0x20/0x30
[ 21.597694] el0_svc+0x18/0x58
[ 21.600758] el0t_64_sync_handler+0x98/0xe0
[ 21.604947] el0t_64_sync+0x154/0x158
[ 21.608625] Code: ???????? ???????? ???????? ???????? (????????)
[ 21.614730] ---[ end trace 0000000000000000 ]---
Segmentation fault
#
--
Florian
On 7/11/2025 1:50 AM, Florian Fainelli wrote:
> On 7/10/25 02:15, Shivendra Pratap wrote:
>> 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. As the
>> vendor-specific reset needs two arguments reset_type and cookie
>> to be passes to the firmware, enhance the reboot-mode framework
>> to support two arguments (magic and cookie), for each reboot-mode
>> command, where cookie will be optional.
>>
>> 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 DT 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_with_cookie function which will save the
>> magic(reset_type) and cookie 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
>>
>> 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 <quic_eberman@quicinc.com>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>
> Humm, something changed compared to the last version that I tested from Elliot which worked ok. With this patch applied and the following Device Tree snippet:
>
> psci {
> method = "smc";
> compatible = "arm,psci-0.2", "arm,psci";
> cpu_on = <0xc4000003>;
> cpu_suspend = <0xc4000001>;
> cpu_off = <0x84000002>;
>
> reset-types {
> mode-powercycle = <0x01>;
Yes, Now passing the cookie value is mandatory, when defining your "reset-types".
So your device tree entry should be:
mode-powercycle = <0x01 0>;
Please try by passing changing the dt entry as above.
The dt-binding document is updated and does talks about the mandatory cookie
to be passed in reset-type.
> };
> };
>
> I get the following invoking "reboot powercycle":
>
> # reboot powercycle
> [ 21.403188] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 is not a phandle reference
> [ 21.412032] Mem abort info:extended_property): /rdb/waketimer@841a840:interrupts-extended: cell 0 is not a phandle reference
> [ 21.414840] ESR = 0x0000000086000004operty): /rdb/waketimer@841a840:interrupts-extended: cell 2 is not a phandle reference
> [ 21.418601] EC = 0x21: IABT (current EL), IL = 32 bitsparent: cell 0 is not a phandle reference
> [ 21.423927] SET = 0, FnV = 0: /rdb/xhci_v2@8d00000:phys: cell 0 is not a phandle reference
> [ 21.426988] EA = 0, S1PTW = 0 /rdb/sata@8b0a000/sata-port@0:phys: cell 0 is not a phandle reference
> [ 21.430138] FSC = 0x04: level 0 translation fault:phys: cell 0 is not a phandle reference
> [ 21.435054] user pgtable: 4k pages, 48-bit VAs, pgdp=000000010112c000 a phandle reference
> [ 21.441508] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000handle reference
> [ 21.448318] Internal error: Oops: 0000000086000004 [#1] SMPcell 0 is not a phandle reference
> [ 21.453990] Modules linked in: bdc udc_core/thermal-zones/cpu-thermal:thermal-sensors: cell 0 is not a phandle reference
> [ 21.458188] CPU: 0 UID: 0 PID: 1566 Comm: reboot Not tainted 6.16.0-rc5-next-20250710-gdd78270edd5a #2 NONE 4)
> [ 21.468032] Hardware name: BCX972160DV (DT)ases property name must include only lowercase and '-'
> [ 21.472221] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)only lowercase and '-'
> [ 21.479193] pc : 0x0s_paths): /aliases:pcie0: aliases property is not a valid node (/pcie@8b10000)
> [ 21.481388] lr : reboot_mode_notify+0x64/0x80es property name must include only lowercase and '-'
> [ 21.485760] sp : ffff80008344bbe0iases: aliases property name must include only lowercase and '-'
> [ 21.489079] x29: ffff80008344bbe0 x28: ffff0000c3bb3d00 x27: ffff800080ab58e8ly lowercase and '-'
> [ 21.496228] x26: 0000000000000000 x25: ffff0000c3bb3d00 x24: ffff800082cf9bc8ly lowercase and '-'
> [ 21.503376] x23: ffff80008344bcb8 x22: 0000000000000001 x21: ffff0000c31b87b0
> [ 21.510524] x20: 00000000fffffffc x19: ffff0000c31b8780 x18: 0000000000000000
> [ 21.517673] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [ 21.524821] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [ 21.531969] x11: 0000000000000000 x10: 00007fffc02bb958 x9 : 0000000000000010
> [ 21.539118] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000080c38080ffff
> [ 21.546266] x5 : ffff0000c3000000 x4 : 0000808000800000 x3 : 0000000000000000
> [ 21.553415] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff0000c31b8780
> [ 21.560565] Call trace:
> [ 21.563014] 0x0 (P)
> [ 21.565205] notifier_call_chain+0x70/0x120
> [ 21.569401] blocking_notifier_call_chain+0x4c/0x78
> [ 21.574288] kernel_restart+0x30/0xc8
> [ 21.577957] __do_sys_reboot+0x1c8/0x268
> [ 21.581886] __arm64_sys_reboot+0x28/0x38
> [ 21.585902] invoke_syscall+0x4c/0x118
> [ 21.589660] el0_svc_common.constprop.0+0x44/0xe8
> [ 21.594373] do_el0_svc+0x20/0x30
> [ 21.597694] el0_svc+0x18/0x58
> [ 21.600758] el0t_64_sync_handler+0x98/0xe0
> [ 21.604947] el0t_64_sync+0x154/0x158
> [ 21.608625] Code: ???????? ???????? ???????? ???????? (????????)
> [ 21.614730] ---[ end trace 0000000000000000 ]---
> Segmentation fault
> #
>
> --
> Florian
© 2016 - 2025 Red Hat, Inc.